You can mitigate some of that with web workers, but it's a shame that multiple websites can't share a python runtime the same way they can on a shared linux box. You have to download a separate one for every website that uses it. But, if you follow that train of thought to the end, you wind up with the browser itself bundling those runtimes, just like it did with Flash back in the day.
I'm not sure any of this would be an improvement over what we have now.
the only good reason to build these runtimes is to enable existing applications to be recompiled into wasm for use inside the browser - it doesnt make sense to greenfield an application that uses non-web UI libraries, only to then bundle the entire UI runtime with it.
Pretty cool, definitely going to go on my "interesting gift ideas" list. It's surprising how this website devoted to selling something hides the basics of what's special about the product on the FAQ page though. I guess people hear about this through word of mouth?
It did cause a small uproar, but not as big of one as I expected. Musk admitted that posts with links that people clicked on would get de-prioritized by the algorithm.
I think he meant examples where "Managing and updating the DOM is stupid simple." The consensus here seems to be that updating the DOM is a difficult problem. It would be nice to have counter-examples.
I am sure it is hard if you have never written an application without React, jQuery, whatever before. That doesn't make it hard though. It just means its something, only at present, uncomfortable.
Here is how I do it. This is all the front end code for a large personal project.
My observation is that no matter how complicated and large the application gets anything that ultimately runs in the browser scales in size disproportionately slower in the browser code than elsewhere. This remains true no matter how much of the instruction set you intentionally try to put into the browser. That said, why even bother with this framework bullshit in the first place if the code it abstracts is never the primary problem in any given application? The larger the application gets the less significant the browser portion of that code becomes as a percentage of total application size.
Are we at the point yet where companies are looking for programmers specifically to fix their vibe coded codebases? A codebase restoration expert?
Or will they do what most companies do when they sink millions of dollars into a codebase that doesn't work: dump the codebase, dump the team, hire a new one, and build from scratch?
reply