I remember celebrating when it died but looking back it wasn’t so bad. At least from a dev perspective, working with a batteries-included sdk from a single vendor is a lot nicer than this node_modules cancer.
I’ve said it before and I’ll say it again, it’s a matter of time before Windows runs on the Linux kernel. It’ll just be this big monoculture like Chromium with browsers. There really isn’t any reason to duplicate all this effort in maintaining an OS. Might as well have the whole world pitch in on one strong project.
I wanted to make something like this, but using Bluetooth LE. Then I looked at the Bluetooth spec and implementations realized why Bluetooth applications are so unreliable (other than Apple device to Apple device). It’s really hard. Plus every OS has their own incompatible API, with some parts missing or inaccessible for some reason.
The practical solution to “share files in physical proximity” ends up being just use Apple everything.
AI in those days was completely academic, so they used the in vogue academic language. It was a tribal thing—the same way HN gets excited when they see Rust. AI in the 1980s was centered around MIT, where everyone knew Lisp (actually Scheme) from the famous SICP course.
Correct. The best use case for Web Components is to ship a bloat-free, reusable widget that doesn't care whether a consumer uses it with React, Vue, vanilla JS, Angular, etc.
If you're using a framework like lit-html as the author recommends, it will replace the string every update. Most people will prefer that way since it's more ergonomic and similar to React. You could do imperative DOM updates, but that'd be like going back in time to jQuery.
The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like <my-component my-attribute="[1,2,3]"/>). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't scale.
W3C standardized Web Components before React existed and took off, unfortunately. I expect the next standard to just be React itself (or a barebones version that the library can build on top of), patent licenses permitting. I'm pretty sure as a C++ precompile, it would be unstoppable and end the debate for good.
This is neat but for convenience not performance. The bottleneck is in the kernel more than anything else. Probably it has the same latency as nginx, modulo safety checks.
I would also recommend uWebSockets for an easy-to-embed web server.