mpeg

That’s not correct, the accent is simply there to know how to pronounce the word, and while in some specific cases (diacritic accent) it is there to avoid confusion in words that are pronounced the same with different meaning, the presence or lack of accent does not as a rule change the meaning of a word.

In this case, catala and català mean the same thing, one is simply misspelled as all words with the strong syllable being last will always have an accent mark if they end in a vowel.

A nice start would probably be for Claude Code to stop trying to use npm when it detects a bun lockfile and vice versa...

I think it might be because the performance fingerprints need to be bucketed. If they're too specific you'll never get the same fingerprint twice.

It's also an absolutely basic fork. They haven't even bothered with a custom theme, or custom UI, it's just vscode with an agents window slapped on top.

Weirdly, out of all the vscode forks the best UI is probably bytedance's TRAE

Well, it just found a bug in one shot that Gemini 2.5 and GPT5 failed to find in relatively long sessions. Claude 4.5 had found it but not one shot.

Very subjective benchmark, but it feels like the new SOTA for hard tasks (at least for the next 5 minutes until someone else releases a new model)

Allegedly it's already available in stealth mode if you choose the "canvas" tool and 2.5. I don't know how true that is, but it is indeed pumping out some really impressive one shot code

Edit: Now that I have access to Gemini 3 preview, I've compared the results of the same one shot prompts on the gemini app's 2.5 canvas vs 3 AI studio and they're very similar. I think the rumor of a stealth launch might be true.

This is cool, and it's a really impressive feat especially for someone with relatively little experience due to your age.

A few notes:

- it's easy to be faster than other routers when you're doing less, for example it seems wildcards are not supported yet, and there's no tests but I suspect there would be a lot of bugs in the way routes are handled. I wouldn't focus that much on speed

- your code organisation is ok for a personal project, but it could use a bit of structure. things are all over the place, I would try to separate pieces of functionality that can be developed (and, importantly, tested) in isolation. For example, your router could be its own module, that way it would also be easier to get started in writing unit tests. (once you've got some example code you can just offload a lot of the test writing to an LLM, then clean them up manually as it will do stupid things)

- your benchmarks are quite low in general, I don't know how good the node.js tool you're using for it is but I would give them a go with something like oha. also, it's very odd that hono beats elysia in your tests, in my own testing elysia is much faster than hono, but it suffers from the same tradeoffs as any trie based router (more set up time)

- instead of zod, you should use the @standard-schema/spec package, so that it can work with any validation library (including zod) – they have some nice type utilities too that simplify inferring types from schemas

If anything, digitalisation will make it easier.

Currently if you hand your id, the cashier could theoretically take a photo of it but it's an extra (and awkward) step, and then someone would have to figure out how to extract the data and make it usable.

marko5 which is the stable version does partial hydration by default (like Astro, but with automatic boundaries)

marko6 which is currently in public beta is resumable by default, and does some similar things to the also public beta qwik2

You should give this a read, it explains why they chose to put everything within the markup

https://markojs.com/docs/explanation/separation-of-concerns

Reminds me of Populous!

Very cool

“Check out my website yeah, trashbat dot cock, registered in the Cook Islands”

Nathan Barley is a great watch. It also has one of my favourite terms for a mobile phone “hand held twit machine” (pre smartphones)

I quickly looked into the webkit code and there's probably absolutely no performance benefit, the same logic should be running behind the scenes

I've literally never had a marketing person tell me whether I should use a <button> or <div>. Let's not pretend things like using the wrong semantic elements is anyone else's fault but lazy or inexperienced developers.

These days it's a moot point anyway, because everyone is using things like tailwind which provide a full reset for things like default buttons, so there really is no excuse.

The funny thing is the insertRow/insertCell API just call into DOM manipulation functions like appendChild internally, they just provide some syntactic sugar around things like managing the rows/cells array. It's all the same

https://github.com/WebKit/WebKit/blob/28fa568972a4d34d867948...

I've given you a list of options that you can use to cache your simple logo.jpg url: use a bundler that automatically appends a hash (it can be as a querystring if you want, you can do logo.jpg?h=xxxxx, you can use etags so that the client checks with the server if they have the latest version of a resource, you can also use the last-modified headers to instruct the client to send an if-modified-since

I'll give you an extra one I learnt about recently: you can use a custom compression dictionary, although this is only available in chrome right now, which means even when a file needs to be redownloaded the network size is tiny as it's compressed with a custom dictionary that matches a previous version of the file

I'm not entirely sure what your point is. You don't want the complexity of a server cache but you want "clean urls" – having a hash in a filename does not necessarily make it worse, in fact it's closer to a pure url since one of the principles of hypermedia is that each url should point to a unique resource

Urls like /v2/yourfile.js are probably closer to that philosophy. Or /[hash]/yourfile.js.

It really doesn't matter if a personal blog decides to serve only http as a niche protest. But you really don't want to go back to the times when most sites were http; we had:

- Massive government spying programs, people forget that Chat Control used to be the standard, everything you ever browsed, posted or said online could be monitored

- Tracking that you could not disable, where your ISP would work with publishers appending http headers to every request that uniquely identified you.

- Not only little guys, as you say, were using http, it was government sites, news sites, a huge part of the internet was unencrypted and vulnerable to mitm. As you say, yes, it's not the only attack vector but it was one of the easiest to exploit, where any random wifi access point you're connected to could steal your credentials.

That's precisely the point of HTTPS, your harmless recipe site can start spreading malware without your knowledge if you make it HTTP, as the content can be changed by anyone it passes through.

The article is a bit disappointing in that it focuses too much on bundle size. Bundle size is important for sure, especially in rural areas with poor mobile signal, but time-to-interactive is imho more important, and that's where resumable frameworks like qwik and marko6 shine

Solid is great for raw rendering speed, but it hydrates just like react (unless you use an islands framework on top like astro which has its own limitations), while qwik and marko are resumable out of the box

This is a solved problem. All modern javascript bundlers append a hash to the filename, so even if cached indefinitely the js that hits the browser will update when it has changed as the url will change.

There are also other solutions if you need to preserve the url that are cleaner than appending a query string, like etags

The app in the article is a relatively simple demo app. These are the build times and sizes from a real relatively large react SPA I help maintain

  dist/assets/app.css   98.33 kB │ gzip:  17.69 kB
  dist/assets/app.js    1,050.14 kB │ gzip: 244.88 kB
   built in 15.41s

At these sizes, an islands/resumable based approach can trim a ton of loading time on mobile

All of them can, but you get most benefit of a full-stack javascript framework if you are indeed running server js. But you can build statically in any of them (assuming you are not using any server-only features) and deploy as plain html/js.

That's really interesting with the assertion function, I've not seen that done much, thanks!

Yep, I sent one in another comment https://github.com/elysiajs/elysia/blob/94abb3c95e53e2a77078...

This is not the easiest to follow code, but it's very similar to what you'd find in any fluent web router, the idea is that you have say an App class, which has a Routes generic, then on every route you add you compose the return types by returning this as App<Routes & NewRoute>, the thing is in the most simple cases you can probably do this cast directly and it will be fine, but as you add more features (things like extensibility with plugins, ability to merge to other app routes, etc..) you might eventually run into limitations of the type system that require a escape hatch like "as unknown" or "as any"

It's not the only case in which you might use it, but I think Elysia is a great example as it does some really interesting things with the type system to provide great DX

I fully agree with you on that, it is a shitty system :)

The code I linked for example results in a web router that is fully type safe.

It's not like using js at all, not that I think there's anything wrong with it, if that's your jam.

Yes of course the types could change in the future, and the forced cast might cause issues. I wish there was a better way, but this is an acceptable tradeoff.

Bear in mind, most changes that could cause issues will still be caught by the type checker in whatever object you're casting to. Obviously it should not be overused where not needed, but it's almost always used in fluent apis because there's no better way (that I know of, at least)

If you disagree, you're welcome to prove me wrong!

To give you an example from a popular open source ts-heavy project:

https://github.com/elysiajs/elysia/blob/94abb3c95e53e2a77078...

The `return this as any` there, which effectively casts it to the same type this had, but with the added get route is perfectly safe, it works, and will never be a problem by itself.

No, it's not.

I have shoes that I know always beep on the airport scanners, so if I choose to wear them I know it might take longer or I might have to embarrassingly take them off and put them on the tray. Or I can not wear them.

Yes, in an ideal world we should all travel without all the security theatre, but that's not the world we live in, I can't change the way airports work, but I can wear clothes that make it faster, I can put my liquids in a clear bag, I can have bags that make it easy to take out electronics, etc. Those things I can control.

But people can't change their skin color, name, or passport (well, not easily), and those are also all things you can get held up in airports for.