The AI cost of JavaScript frameworks
nolanlawson.com
nolanlawson.com
AI aside, this is something that bothered me a lot when I was forced to migrate from pure native mobile (swift) to React Native.
People would take the promotional talk of some SDK as truth without ever measuring and then being confused on why the whole app was slow (it CANNOT be XYZ, because XYZ developer says the are super fast!!)
Luckily my team was able to accept when I provided hard data (said framework was locking the JS thread for 200ms, sometimes a full second, for some operations, which rendered the all the UI laggy as hell).
This has largely been my experience navigating the JS framework world from basically the beginning of React. It's wild how poorly some of the earliest presentations about React have aged, as that framework has gone through endless major API/design refactors.
Not to mention that benchmarks are a very flawed way to assess technology for builds with complex and open-ended requirements. If you're operating in a constrained environment and you have a clear bottleneck that a particular tool can solve, then benchmarks can be really helpful. But starting on a new product from 0 that needs flexibility to pivot does not necessarily benefit from picking the fastest tool in the shed.
Flutter good, React Native bad. (mobile)
Maybe it's just me, but if I were to start depending on other's UI frameworks again, then stability would be the first thing I'd look for, and with that I'd probably want to stay as far away from anything "agent" as I can.
Edit: I just realized that that "framework" is the same ArrowJS that used to be a "library" and the selling point was how small it was, and how it wasn't a framework (https://web.archive.org/web/20230609020338/https://www.arrow...), incredibly funny they pivoted into making it a fully fledged framework after all.
Hahaha, speedrunning the "remember how React used to be a library (not a framework) before it became overloaded with pointless bloat? my new sleek, simple library (not a framework) does the bare minimum, and will never do anything more" trail blazed by hundreds of would-be React killers over the years... but with AI this time.
I also have two open issues that have no response.
But it still is by far the cleanest of the micro spa frameworks I've seen.
Ah, you're the author of it? :P Cherry on top
I forked, put AI on it to not only fix the issue I was facing with the new Angular (zoneless) but add full testing to it and make it resilient. Massive benefit to my apps and trust.
https://github.com/Kareadita/ngx-virtual-scroller for anyone that's interested.
In this regard alone, it will make a lot of sense to spend extra $2 and 2 mins to trade off for a long-term maintainable codebase and code you can reason about than just something made quickly just to get it deployed fast.
In my personal use case, that would be Svelte 5 for me and I'm sure it will be something else for everyone.
They seem to struggle to reason about the boundary between the two.
I intentionally avoid hydration (which I've always found to be flaky) and hydration-based frameworks like SolidStart, so possibly that helps. Or maybe that's just my own bias!
Very easy to setup and way more readable than the equivalent React code.
Django?
* so that employers do not have to invest in training developers.
* to ease candidate selection at hiring, which greases the wheels of hiring/firing
In the big corporate world, especially at non-software companies, there is a culture that strongly believes internally written software sucks. This is Invented Here syndrome, and it reflects that internal developers cannot write software and employers will not invest in maintenance.
The larger costs there are human costs, the inability to efficiently solve any problem outside the constraints imposed by the framework.
This does not make sense to me. What do you classify as employer here? Front end frameworks are usually pushed by developers, not management. If it were I suppose we would be seeing way less react and more vanilla with jquery on forms and normal website stuff.
The push to create a SPA with react and other bollocks is purely pressure from implementers. There is not a day that I don't see devs that are more interested in making "beautiful code" and architecture despite the actual requirements they were trying to solve for. Ai is changing that, I hope for the better, but only time will tell.
The last ten years I spent as a front-end "full stack" dev and every time there was some new shiny JS framework, all the devs would get out their tiki torches and pitchforks, go to management and tell them they should really really move to this new framework because blah blah blah.
In less than five years our department did this:
backbone -> angular -> react -> ember -> next -> vue -> svelte -> and finally back to angular/react which is what a majority of what we build with now.
Doing this insanity also created a way for mangers to make sure their year-end reviews looked good and polished. Every time an app that was built on a framework a few years old, suddenly a manager would declare it "dead" and needed to be re-built in record time (because the new framework allows devs to build Rome in a few days time). We would bust ass, usually hitting the deadline with something put together with duct tape and code no dev would willingly sign off on. Manager gets their raise and bonus at the expense of a host of devs running for the door.
Rinse, repeat. But 100% of the framework changes were always pushed the hardest by the devs.
The reason we moved away from this and into functional/reactive programming with things like React is that it eventually creates a mess too big to untangle. We made this experience with human developers and I made exactly the same experience with LLMs, trying to go "vanilla". It works for a while but the defect rate rises quickly und the LLM spends a large amount of time navigating the mess it created. I ended up with React again because it lets you express a lot of stuff as pure transforms, which are easy to reason about for human and LLM alike, and the LLM knows it very well out of the gate.
And by "React" I don't mean "react router" and all the other unstable crap in the ecosystem. React itself is stable and that is extremely important for LLMs, otherwise it will constantly conflate what the API actually looks like now. Breaking API changes are poison, worse than going with an in-house library that the LLM doesn't know how to use, because at least then it will look it up straight away, rather than messing it up (because it _thought_ it knew how it is supposed to work) and _then_ looking it up..
I have seen countless "founding engineer" job ads with every little detail of the desired stack/architecture spelled out: Java/Spring/MySQL/Linux/Log4J, C#/RabbitMQ/MSSQL/SSIS/Windows, etc. Non-technical founders/recruiters/etc don't want to "leave things to chance", and will happily overly specify the constraints, mostly informed by popularity ("Nobody Gets Fired For Buying IBM"), rather than leave the solution space unconstrained for some "generalist" to choose. I mean, how do you even know someone is competent if you can't grill them on a concrete set of buzzwords?! The horrors! So of course the recruiters gotta make up constraints to find someone "qualified".
Heck, I've personally seen this pattern at every step of company growth, from 5 employees to hundreds. I've watched as my employer's recruiters would explicitly seek tons of things we weren't yet using. Why? Because when performance isn't as desired, the first thought is not "hey, maybe our approach to managing people and projects is dysfunctional", but rather "maybe we just haven't found the silver bullet yet; let's go shopping". In my experience over 20 years, that represents 99% of the cases where new crap gets introduced: Scrum, Jira, SQL Server Integration Services (SSIS), front/back end frameworks, consultants ("our developers must be idiots, so let's get outside experts"), etc.
I think it is true that there are cases where developers will push for things like particular front end frameworks, but that's almost always the exceptionally rare case where there's any resistance to push against: few companies aren't already using the stack du jour, so most developers (especially greenhorns) will have bought into that stack ('cause "gotta pay the bills"), so a new developer brought into a nonconforming engineering org will quite likely want to use the tools they know and thus push for it. The real culprits, though, are usually the non-engineers: founders/recruiters/etc who create a financial imperative to adopt whatever is trending, which results in developers who spread that popular mediocrity elsewhere.
This is backwards. The pressure from the business/product side is to create more and more interactive applications. Jquery hit its limits supporting that reasonably, sometime around the early 2010s.
I've seen sssoooo many startups use tech stacks that are completely unsuitable for their use case, but the developers are keen to use that stack because it's the latest hotness and it looks good on their resume.
I don't think we should discount the overhead that goes into making a component system with state management, and how much that simplifies application design as it allows you just to focus on data flow. The leap from a render function with a declarative dom DSL to something with state management in terms of complexity is nontrivial, and the amount of code you can you clean up with going from one to the other is also massive.
I get everyones definition of a framework slightly differs, mine is mostly when there's some level of inversion of control that you need to buy into through an app, and I think component system fits that description. Even so it may be a less contested kind of a framework.
Component systems are the new OOP. They are numerically complex. People think they are all the rave and I don't know why, but then people also think OOP is generally all the rave and I don't think they know why.
You don't need component systems, but if you choose to go down that path just realize everything is far more work because there is tremendous amounts of duplication both explicitly in your logic and under the hood where you are not looking. Most people who believe they need this are locked into an enormous framework and deliberately avoid looking under the hood, because its a giant scary beast they believe they cannot live without.
If you want simple you will do everything in your power to avoid component systems, because simple does not mean easy. Rich explains it better in what might be the best computer science talk ever given: Simple Made Easy
React is actually more functional than anything else.
Of course if you actually try to be pure functional many developers will scream at you “prop drilling! Code smell!” But to me that it is a much lesser evil than useContext() and what is essentially global variables
The only language/framework that is truly functional in that sense is Elm.
But I'm talking about interactive UIs which need state, as the environment its running in (the browser) is inherently stateful, and there are efficiency gains from doing so.
This isn't just an OOP thing, even in Elm & Purescript there are similar libraries for stateful UI. In you're doing anything like that in Closure or Clojurescript or whatever, I guarantee you its built on similar data structures and its foundation has many equilivant constructs.
My large SPA achieves full page load with state restoration in under 150ms. You don’t need React or components to achieve simplified state management.
[1] https://blog.risingstack.com/the-history-of-react-js-on-a-ti...
[2] https://medium.com/@sjarancio/reactjs-a-brief-history-3c1e96...
[3] https://medium.com/the-startup-lab-blog/the-history-of-angul...
[4] https://medium.com/@andrewchall92/how-jquery-was-born-a-brie...
Now if you have written your own applications nearly 60-80% of it executes outside the browser even when the only interface and use case is in the browser. The current common use case for these frameworks is that most developers cannot write original software and when they try they either fail, with plenty of face-saving excuses, or just create something that looks identical to their favorite framework. This is the primary problem these frameworks currently exist to solve for.
It most certainly is not.
It’s really simple. You can write an original application in your own code or you just can’t. I don’t care about all the excuses, because it just isn’t that challenging. It’s not for everyone.
But this is... true? Non-core software gets the shaft in resources / development, especially at non-software companies. And for most companies the underlying web architecture are not a core business. For Facebook, Amazon, Google it is, that is why they are often the ones making frameworks.
Fact is frontend development is very complicated and the platform doesn't provide enough support for large projects.
That said, almost every JS framework degrades to... a browser, do whatever you want, I find it hard to believe any have actually limited your ability to accomplish something unless it was truly beyond the ability of a web browser.
Also, the framework worship is always a bit bizarre to me because the front end of even the largest of single page applications is relatively tiny compared to the supporting back end. If a developer is writing the entire application then why invest so much effort into over engineering such a small slice of the total code? It isn't productive unless it is the maximal extent of a given developer's capabilities.
Libraries are code that you call to perform specific tasks. You control the program's structure and execution flow. You're in charge and you call the library when needed.
Frameworks invert the relationship and call into your code and hence dictate the overall structure and execution flow of your application. It's in charge and it calls various customization points that you provide to it at predefined points.
These definitions largely date back to the late 1980s with the introduction of object oriented frameworks (see Designing Reusable Classes from 1988). Further references include:
https://en.wikipedia.org/wiki/Software_framework#Comparison_...
> a culture that strongly believes internally written software sucks. This is Invented Here syndrome
It's the inverted invented here syndrome ;)
But it is oh, so true. Entirely, unsurprisingly -- an internal software stack has captive audience, and never compete with anyone else.
They can good, but exception to the rule.
No, I think they had it right. Your "inverted invented here syndrome" would be the original NIH syndrome, in which people prefer building their own version of everything.
That's where most complo theories fail...
The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"—or, put more charitably, a hunch plus some inductive reasoning. It's not a tested hypothesis.
The crux of your argument* is essentially "a + b > a for some non-zero b", where b represents what you are "paying for your library code". The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method ("Just Do It") when it comes to dealing with things yourself (i.e. the framework cost—which, like b, is never zero).
* as stated at least; it's possible and probable that you really don't mean to say that c simply doesn't exist but that b > c (either by intuition or experience or both) but that's still just a claim—which is the entire basis for the author's criticism: not whether frameworks are or aren't actually more cost-effective, but the greater meta-level concern described here in this comment, in the original piece, and other comments by the author and people like Alex Russell elsewhere describing how resistant the culture is towards the notion of attempting to prove or falsify these kinds of claims (if you can even manage to get people to agree to formulate them in such a way that they can actually be subjected to the scientific method)
Is it? Because in my experience, this is flat out wrong and it's very easy to verify, and it is a tested hypothesis.
> The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method
You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper. Why would that ever be true? React doesn't do DOM manipulation for funsies, if you foregoe a framework you'll be implementing reactivity, interactivity and performant code yourself. The browser is very barebones in that regard. The framework cost is always lower than rolling your own, and this isn't even the argument people are having. Non-Framework evangelists are arguing performance, never cost.
A framework doesn't come into existence out of thin air. If you choose one, you're working with a community of thousands of developers. I don't have to build my own reactive table, I can use TanStack table. I don't have to build my own playground, I can use stackblitz or storybook to showcase stuff to a client. I don't have to build my own cancellable asynchronous list, I can use a trusted library for that, too. My client doesn't care if I roll my own. They care about effect per hour spent.
First, not using a framework doesn’t mean you have to roll your own (otherwise you’re still using a framework?). Second, this is the claim the parent wants you to substantiate, that not using a framework is always more expensive than using one.
No, I'm not. Nowhere in my comment have I made that claim, nor is there any claim that could even be mistaken for trying to argue one way or the other. It's like you lack the ability see words on a page and understand what's actually being discussed in the remarks you're responding to. (This also explains why, when challenged on succumbing to the industry tendency to make all-vibes arguments instead of evidence—directly in the comments of the article that calls this out—your direct response to that is to restate your claims and arguments and avoid providing any evidence. It's always just hunches and attempts at inductive reasoning, all the time.)
This is something that people who cannot live without frameworks often repeat, but its a fiction of their own creation.
If you plan to sell a digital product or SaaS on the internet and your use case is more complex than a blog or a portfolio site, your „vanilla js purity“ will outgrow the project, fast, and it will become a mess. I‘ve never not seen it end this way.
I've seen the situation where underqualified, overambitious programmers build an internal platform that becomes a monster. There isn't the time to mature it, there isn't a standard or docs to point to, it becomes a drain on the company, at worst someone's vanity project.
I've also seen the situation where a team absolutely refuses to build anything themselves out of anxiety, spending enormous amounts of money on an external solution that acts as a rent extractor.
The problem with buy-not-build, is if you do it for too long, you forget how to do the latter. This is great right up until you find a problem you can't buy your way out of.
Sometimes building something half good, is fast enough and educational enough to get you to the next step.
There’s still value in building something from the ground up; you understand the framework that much better. But so long as your needs largely overlap with the community, the benefits of working with the community are real.
I do tire of the failure to perform and the endless empty excuses.
My coworkers are very smart -- smarter than me -- so I'm low confidence anyone else could have done significantly better or avoided the pitfalls we fell into.
That's the best case. Usually it was just thousands of lines of jquery spaghetti.
1. I tried to write vanilla JavaScript once and failed miserably so therefore humanity is completely incapable of accomplishing such
2. I cannot organize instructions to save my life so therefore the result for all developers must always be spaghetti
The unspoken third option is that the people making these claims can’t write software and need to blame something else, however irrationally, because they lack the maturity to find a way forward.
I'm just reflecting what I've seen in the field. Webapps evolve over time and sometimes that has meant just ladling on more kludgy javascript event handling. If there is a homegrown state manager, that's usually better than the alternative. (although the frameworks are mostly just fine)
1. Ad hominem attacks on the original commenter
2. The arrogance and limited viewpoint that ignores the very fact that this can be observed by non-original writers of code, and that this scenario is so common that it coined an original term and spawned an entire industry of clean-uppers.
That is and has been a very good argument. One thing I do notice though is that, with the emergence of agentic automatic maintenance workflows, that same maintenance surface seems to start shrinking right now.
Imagine an e-commerce website that has a cart with some products. The site has a cart button showing the current total, a pop-up cart interface, as well as an assortment of 10 or 20 different components which let you add or remove products (E.G. the Christmas promotion page may be using a different, christmas-themed "Add to cart" button).
You need to keep all of these in sync. If you open the cart pop-up and remove the product you've just added on the Christmas promotion page, the button on that page must change color (and ARIA state / label) back to show that the product is not in the cart any more.
With traditional, imperative JS, you have ~20 places where this state is kept: The card array is the source of truth, the CSS classes, labels and aria properties of all these buttons must stay in sync with that array, but there's nothing that forces them to do so.
Sure, there are some software engineering patterns (I'm looking at event-driven design here in particular) which make this kind of bugs less likely, but they're still not really a guarantee of the code being correct by construction.
React and its ilk make it much, much harder to introduce that kind of bug, requiring you to basically go out of your way to do so.
Because AI agents love slop and "just one more edge case just to fix that one bug" thinking instead of addressing the underlying root cause of the bug class, this kind of thing is more important now than it ever was before. Agents are great only if you set them up for success, and the way to do that is to make bugs impossible to write.
> For me working with the DOM is just a matter of assigning references to variables and making use of events (functions).
I loved this tech-coded business speak gibberish. "For me, managing business operations is just a matter of aligning strategic variables with organizational synergies and making use of scalable frameworks (processes)."
I have most of my apps in it without much trouble.
One of my recent ones had a very complicated form and state management.
AI really struggled with HTMX in that use case.
Like the form might work but the page would take 30s to load. Or some state would randomly drop or a toggle wouldn't work after changing a dependency.
If I rewrote that in react it would have one shot it without a doubt. Some things are just better models for different problems.
For the record I eventually got enough tests in place to keep the agent honest and the HTMX version is now a lot faster anything I could have got out of react but yeah, it was an adventure.
Most of my sites start as a copy of an existing site as if it's a framework and then I clear out the product and just use the shell to build from. The result is that the agent is pretty good at replicating existing patterns and if I ever hit something similar I can just tell it to look up prior art in other projects.
The initial learning curve was definitely there, and I still hit edge cases as mentioned above. I just don't have to resolve the "how do I handle auth + middlewre + htmx targeting for a form in an admin screen (for a random example).
Also, it’s a language where everything happens somewhere else. Not here and now, somewhere else on some other event. That sucks for the small stuff.
Async JavaScript using callbacks had a learning curve, but once you learned how to contain it and treat callback indentation as an opportunity to refactor it felt similar to coding in lisp.
The problem was the learning curve, and the fact you had to rewire your brain a bit compared to coding in something procedural.
I'm still sour why goto doesn't exist in javascript
As much as possible should be happening locally, synchronously on the computer, in-process, or at least without yielding your thread context (and even then there are things like page faults which async/await wont save you from, they are 'invisible' to a regular developer).
While you might dismiss this idea, page faults used to be THE leading cause of delays back when hard drives were the norm.
This hurts most badly for iterators.
Files are usually read from disks in chunks of 64K bytes. If you present the data as an async byte iterator you'll get 65,534 defensive deferrals, and one actual wait.
If you have ten layers of transformation it will be 655,350 defensive deferrals and 10 real waits.
These defensive deferrals aren't so expensive in terms of CPU time, but they ARE very expensive in terms of wall clock time. All other work must be halted so the event loop code can run. Eventually synthetic deferrals dominate the wall clock cost of running the program. This isn't hypothetical either. Here's someone trying to build steam parsing on Node and finding that it's too slow to be useful: https://github.com/nodejs/node/issues/31979
The solution is stream iterators. They are sync when they can be and async when they must be: https://docs.bablr.org/architecture/spacetime
If anyone interested here is the source code all done by Opus 5.5 https://github.com/ramigb/esdara
After a decade of React, I'm not going to go go learn htmx or any other marginally better same-shaped tool for a new project, especially when it'd degrade my ability to review and debug another actor's work product. The cost of switching frameworks is now dramatically higher and the payoffs way lower.
Fundamentally, framework perf is about not incurring too heavy a cost for the abstractions, and then to improve dev efficiency. This matters most in the "explore"/prototype phase, when poor perf would be a good problem to have to care about.
In my projects, the real question has kinda moved down to "should I yeet 1/2 the app to wasm yet?" and similar higher-order questions.
I'd be curious how it does if you allow it some helpers or "micro frameworks" that are WAY short of a normal framework. Say vanilla js paired with nanostores as an example.
and what % of users have JS turned off? 0.00001%?
The only feature that appears to require JavaScript is search.
I have noped out of so many sites that are - or should only be - serving simple content when I see the "please enable JavaScript" notice or site just plain breaks. It's so disappointing and irritating.
I hope I'll be the last person on Earth writing code by hand.
The overwhelming majority AI spend is being done by startups funded by venture capital.
Meanwhile, big companies have massively cut/capped AI spending at the exact time these companies need to triple prices to get any margins at all.
Perhaps dead internet theory applies more than normal to programming forums.
Meanwhile, a friend at a consulting company of similar scale tells me they don't hire anyone who shows a lack of experience with "agentic engineering" during the interview. They're turning all their projects into software factories from issue ticket to deployment. He's much more resourceful and experienced than me so I trust he isn't automating himself out of his own job, but I'm much more gloomy about this transition.
Technologists uncritically doing the bidding of Silicon Valley billionaires. Same as it ever was. https://news.ycombinator.com/item?id=50274456
$16B revenue in first half means $32B for the whole year at that ARR. Divided into 47.2M devs gives us $677/yr per dev assuming that ZERO non-devs ever pay for Anthropic. Add in all the OpenAI and Chinese spend and spread them among developers only and the average is still only around $1k/yr/dev.
Top 1% of AI users spend $9,567.53/mo or $114810.36/yr while median spends $15.70 or $188.40/yr. 80% of the top 1% of AI users are backed by venture capital.
https://ramp.com/data/ai-index#adoption#overall
Anthropic + OpenAI seem to have in the area of 70-100M users.
Only problem is that 1e6*114,810.36 ~= $114.8B which exceeds stated income of OpenAI, Anthropic, and all the Chinese firms combined.
When you crunch those top 1% guys, you get a number more like just 250-500k or so accounting for almost all current AI spend which leaves 46.5-47M devs using very little AI. You can adjust these numbers by massive margins (around an order of magnitude) and still see that the math doesn't work out like you seem to think.
When all that venture capital/private equity gets crunched, those companies won't be able to afford to keep blowing a hundred thousand per dev. When they back off, AI sales will drop further lowering available venture capital risking a massive downward spiral.
But for agents it doesn't matter, so why frameworks at all?
PS: authors comparison is not relevant, as it's simple mostly-static app with very little cross-dependencies, localizations, component re-usage.
Point is frameworks or not, Agents make a mess in javascript, so maybe it’s actually an improvement to establish the standard lib as the foundation and steer Agents from there. Adding frameworks expliodes the surface are of options.
Sure with JavaScript's library a-la-carte fashion there's a proliferation of idioms far beyond eg Ruby's hegemonic "convention over configuration", but nevertheless React is still more of a lingua franca than Flask/FastAPI/SQLAlchemy ever was or will be. The most popular Python libraries do a thing and otherwise proscribe nothing.
JavaScript idioms pare down the universe of possibilities in a way that some programmers find claustrophobic, and Python is the wild west!
I know it's popular to characterize JavaScript as the wild west, but in that case it's a proliferation of abstractions, whereas with python, it's a proliferation of implementations, ie primitive obsession.
But I'm really putting far too fine a point on these differences. In the grand scheme of things, they are nigh indistinguishable scripting languages.
Isn't that essentially what we get with frameworks? I'm still unconvinced that frameworks are a problem with agents. If anything, pointing an agent at a single framework reduces its API surface, compared with the standard lib and every permutation of possible solutions that comes with it.
I would go so far as to argue that all of the reasons that frameworks are useful for human-led projects are equally, if not more applicable to those executed by agents.
I think it, also, had a lot to do with the promise that most machines could run Java if they had the runtime installed
> My goal here is not to write the end-all-be-all benchmark for “I’m a vibe-coder, which framework should I choose?” The point of this post is to demonstrate that it’s possible in the era of AI coding to still make decisions based on evidence rather than vibes.
But it’s obvious that the article will be understood as a useful benchmark, so author probably should have addressed that point earlier and more thoroughly.
Taking the authors pov for a moment, they just showed you how to put all your criticisms to work in making a newer better benchmark :)
The formula has changed significantly with LLMs. Managing state is still an architectural concern but not necessarily a human concern, as LLMs can sort out how to make things work. Which framework/approach is best is now an intersection of use case, performance/scale and LLM capabilities.
React wins by default for now because it has so much prior art in models and because devs know how to read and architect with it. In the future we may be generating WebAssembly code for performance with some bespoke state management that is fully rewritten after each change - what matters in the future wil not be legibility but accuracy, malleability and performance.
Yes, of course they asked.
The agents responded with how this framework is X, not Y. How creating it was a sharp commentary on other frameworks. A couple honest caveats, and a succinct bottom line that adequately kissed the user's ass.
An actual high performance framework should manipulate HTML as a string directly, or through HTML templates (another feature that has existed in most browsers for a decade).
If you're not building a complex application on top of the web stack (interestingly these increasingly use WASM and their own GUI frameworks, so another moot point), but building an interactive consumption website (scrollable lists of static contents), I'd say instead of fronted frameworks, what most people actually would need is Chrome's experimental declarative partial updates:
https://developer.chrome.com/docs/web-platform/declarative-p...
Which basically stream HTML fragments from the web.
WASM is a non-starter for most web applications due to initial binary download.
Advising to use some experimental feature in one browser does not seem like a great idea.
JavaScript frameworks are not perfect but they exist for good reasons. People that brush them away usually lack the experience and understanding on the topic.
const binary = Uint8Array.fromBase64(
"AGFzbQEAAAABBgFgAX8BfwMCAQAHBgECeDIAAAoJAQcAIABBAmwL"
);
const module = new WebAssembly.Module(binary);
const instance = new WebAssembly.Instance(module, {});
console.log(instance.exports.x2(3));
It seems like you're extrapolating from things you know to something you don't know at all, and you're spreading misinformation. WASM was designed to be compact.
I think a lot of JS developers fail to recognize the variations of client systems power or people's usage patterns like how many tabs are open, how much GB of memory is their browser using, is the client machine paging out to disk, stuff like that. Not everyone is running a MacBook Pro so heavy client side JS apps tend to be "slow" to end users, at least perception.
Read more here: https://turbo.hotwired.dev/handbook/introduction
Elixir has a similar mechanism with Phoenix LiveView.
And the cost comes from the fact the browser builds its internal lightweight representation of the DOM when parsing and rendering. You can access this optimized happy path when you are manipulating the HTML through innerHTML or with the <template> DOM tag.
Whenever you access the DOM via JS, a proxy object is created by the VM for each node, and manipulation happens through that. This is a fairly substantial memory and bookkeeping cost, which you don't pay with static HTML.
You can
I also found this 6ish years ago, when I wanted to build a table of some 100k rows from locally cached data. It was an order of magnitude faster to serialize and set innerHTML directly, rather than doing anything related to HTMLElement. The rendering time went from around 30-60 seconds with the naive createElement solution to 2-5 seconds with innerHTML.
Would be cool to see a framework doing that under the hood. Then again, I haven't needed that kind of HTML rendering performance since, so maybe the problem isn't big enough for anyone to care. Haven't tested if the performance numbers even hold up anymore.
I’m the first to complain about the bloat of modern frameworks but stepping all the way back to HTML strings would be a total mess for anything relying on heavy interactivity.
id love to see your evidence for why we should be using strings and for the cost of using "js objects". afaik the top performing js frameworks on the benchmarks aren't just stuffing a string in <body>.innerHTML
No, nobody needs any more "experimental" Chrome bullshit.
The use case you mention, scrollable lists of static contents, works perfectly fine with DOM manipulation and virtualization, if you have a lot of content. Sure, maybe you can speed it up a bit with string manipulation (good luck not introducing XSS) but if you have so much content that this is a noticable factor, you probably want virtualization anyway.
the author measured near perfect scores on lighthouse across the board, which, i mean no surprise there?
then it has takes about payloads and ttfb, which is nearly meaningless without implementation details and one being an expert in each framework, imo.
are you just ranting about javascript in browsers because its accepted and articles like this become a place to welcome such without anyone caring about the topic?
> HTML templates (another feature that has existed in most browsers for a decade).
not really? browsers weren't even at the level of baseline a decade ago. microsoft edge on chromium is six years old.
Nowadays: Electron slop that will also eat a bunch of their RAM.
Personally I think that’s due to the failure of native development properly taking off: you know, actually being good and easy instead of a long line of dead or half dead attempts; alongside platform vendors hating each other and each having a vastly different GUI framework instead of some inter-OS WG to come up with at least good common standards.
Imagine if you could ship your desktop app in a natively running virtual machine, that is as perfect as it gets from sandboxing code and running a lightning fast JIT compiler instead of virtualization. It delivers a common user experience, digital accessibility, endless customization while being secure, it's free for developers and users, constantly updated and it delivers an absurdly powerful, while also perfectly printable markup and styling engine.
That's what a browser is. Your apps are native.
And yet, 95% of these "framework comparisons" and "anti-framework evangelists" build their opinions on examples that do little (if any!) dom manipulation after the initial rendering. Which is just not the reality of commercial products.
I'd prefer not to have used Nuxt for front-ends that don't need it, because it's chunky and a greater migration burden, but once a couple of patterns are in place, it's actually rather fun to use. A bit too much fun.
Also it's modestly large up front, which is the downside.
I suspect what is going on here, the same as with Laravel — which LLMs seem to really enjoy writing — is that the documentation is good, clear and ironically human-focussed, more oriented towards understandable recipes and reference, and the middleware setup is not absolutely arcane; at a glance of a Nuxt page's code you can kind of see mostly what it is going to do.
The results might differ if you were building Facebook, or Instagram, or X, or a static web page for the local coffee shop ...
There will always be trade-offs, but tailoring your abstractions to the project is usually a better decision than not doing so.
Communication has lately proven itself to be as important as ever. If your team has to approve and maintain the result, then using abstractions the team already knows could be the difference between approving the PR today and mythical-man-monthing yourselves as release-blocking capacity -- yet-to-be-onboarded -- for a project that only the AI understands.
Server side page generation with a sprinkle of js will give you the same results with GBS less of packages and comple time
All of these thing still matter no matter what you are coding with.
Having some sort of reusable framework is important for maintainability, always has been. Sure, you can have an agent "write a small JS framework that covers common functionality", but then you need to know what should fit into that framework. Having a framework pre-defined saves a lot of decision making and helps avoid drift.
In my opinion, this has always been true and it hasn't changed with AI-coding.
Plus all the other vanilla advantages: fewer dependencies, lower maintenance, less retraining, etc…
Now that you don't write the code, I don't see why I would pick React style libraries unless the codebase is already there.
It's all about how much interactivity you need. A lot of business web apps are full featured commercial software packed in SPA form. You will need a lot of stuff client side and without framework it will be a mess. Unless you write framework yourself but the you are reinventing a wheel.
I think unless you have a very low number of features or employees (and are sure from the start to keep it this way) I don't see it working.
In my 3 previous companies I had similar issues so I think it's widespread.
Of course, there is the question of "the human can still understand what is going on", but it's not clear the new frameworks are optimizing for that...
Fewer lines of code (per piece of functionality) does, in fact, correlate strongly with maintainability. The downside of this metric to watch out for (as Goodhart's Law would have it) is to ensure that the framework isn't compromising (current or future) flexibility in an unacceptable way. I imagine if this kind of benchmark becomes popular, people would start coming up with low code frameworks which are extremely rigid and inflexible. Because rigidity is a good way to cut lines of code. There needs to be a way to ascertain the flexibility limits of the framework too.
Would be good to have a similar benchmark for a more complex application; one with authentication, access control (with individual ownership of records and group ownership).
Also would be good to compare the security of different frameworks in this way. See which frameworks leave security gaps. Would be good to set up a benchmark where an AI agent is made to impersonate different users (with different roles) and test access to all possible data types and views in an exhaustive way.
A while ago, I showed Claude a relatively complex application I had built with my framework https://saasufy.com/ and asked it to estimate how many lines of code and how long would be required to build the same application with a stack like React + Node.js + Postgres and it estimated that it would require 4 to 5 times the amount of code and amount of time so I'm keen to actually test it out with a benchmark like this.
I was not surprised that HTMX lead in a lot of the benchmarks. I suspect it would do even better with a more complex application. IMO, its design is closer in spirit to where the industry needs to go. There are a lot of maintainability and security gains to be had by standardizing frontend and backend interactions; though I believe there are other way to do this which can yield even more gains (though obviously with some tradeoffs depending on the use case).
I once also worked on a simpler application (feature-wise) for someone else which was approaching 100k lines but it was poorly architected with a lot of bad abstractions and over-engineered. In this case I could claim that my framework is cutting almost 99% of the code but that's comparing to the worst possible situation. Still, even that's not necessarily an unfair comparison because, in practice, a lot of real projects do end up bloated to such extent after a decade or so, likely even more so now with AI. Any framework which can prevent that bloat code from being generated is genuinely delivering long term benefits.
Cost of iteration in time and tokens is really important if you like moving quickly without having to boil the oceans for simple changes. That was always true but AI kind of magnifies it because it's doing a lot of heavy lifting. Most of the time you wait for AI tools, you are actually waiting for tool calls to happen.
At this point just optimizing for all that could save you a lot of time and tokens. Which is really nice for your wallet and maintaining some flow state. I've stopped obsessing about my own biases in tools, frameworks, and programming languages. That made a lot of sense when I was the primary user of that stuff. But I'm not anymore. I might glance at the code to see if it's roughly doing what I expect. But there's too much of it for a detailed reviews and nit picking on my side. If I feel strongly about something, I'll ask for a change. But if it works, I'm often leaning to going with the choices the tool makes for me.
This is a bit of a leap of faith and a lot of people are not ready to make it. But I've found I can be productive with stuff I've never even used before now and that the cost of switching to whatever is fairly low. It does help to have good tools and tests to keep quality levels acceptable. The difference between vibe coding and responsible engineering is basically what you ask for and check for on that front. Having lots of experience doing things the old way definitely helps. But you should not constrain yourself to just stuff you know when solving new problems.
Why not make the change yourself instead of burning more tokens and hoping the change as requested is actually made? Harnesses and models that make human code level collaboration difficult are not useful IMO.
It's akin to using a calculator where you can't access the numeric keypad.
Again the law is laid down. Developers no longer X. They Y.
Feign dismissal over vibes all you want. Same old inevitability posting.
Enlightenment will be achieved when agents set up the benchmarks for what JS frameworks are good for agents. Other agents will interpret the results. Modern, peer-reviewed science.
Also, when I first started out building with AI I made sure it would use frameworks and programming languages I know. Now I don’t care at all and let it choose the best technology. I don’t read a single line of code it generates and only work in the harnesses, never in an editor anymore.
I’m only building apps for myself and I’m not a professional developer.
But now, its just about AX (Agent experience lol) how easy can you make it for the agentic system/model to achieve better outcomes. Its as easy as letting the agent choose it's way of doing things - let it choose its own project framework be it Astro, using bun, using handlebars even.
Nowadays people have shifted from writing code anyways - claude code or codex or any agent can do it, all we do is plan and review.
I would be very surprised if the tool that agents use most effectively is also the one they recommend. There's no clear reason why they'd be the same, until articles like this, neither they nor we know which is most efficient. They're recommending based on their model of normal best practice and patterns (what does everybody else do for a project like this) not "I have analyzed handlebar syntax and I think I will iterate more quickly with this".
That said, both are "fast enough" and if you're on an enterprise plan, the cost difference is neglible. I waste way more more tokens due to poor or imprecise requirements than I do on development.
I find that HTML first web frameworks make way more sense, works out the gate, allows for caching of key parts easily and forces me to think in simpler terms when it comes to implementations. The end result is usually an easier to use app for my end users. The amount of complexity you can add to a UI should be limited but a lot of folks just go crazy with SPA.
Obvious solutions are to vendor your dependencies (compile the framework from owned source) or to drop to the lower level of abstraction.
LLMs should have no problem using browser/node APIs directly since they're very well used, well documented, and not changing as much as higher level software does.
> The Pokémon app is small and doesn’t represent a large, complex real-world application.
That's a pretty big self-inflicted caveat. How do you know the results will translate to complex-real world applications?
Why not try adding a bunch of complex features to the app (Auth, battles, marketplace, social interactions, etc.) to see how an actual production frontend would hold up?
Mainly because it has the smallest footprint and arguably the best performance of the powerful JavaScript frameworks.
It uses two 500-line libraries, one for using JSX syntax, and the other for MVC.
If you aim to make small apps that don’t represent complex real-world applications you should not use Angular.
But blanket statements like yours are what I hate the most in software industry.
Not necessarily that Angular would win that, but I imagine that it would at least significantly shuffle the order.
Traditional languages may have their limitations, but [C++, Rust, JavaScript, TypeScript etc] can still do pretty well.
I run into this problem turning claude artifacts into things I might want to maintain longer term.
https://github.com/anthropics/skills/blob/main/skills/web-ar...
Given a brief brainstorming session, there will be many reasons why this particular experiment isn't directly applicable as evidence for some other project with different requirements. An instinct to over-generalize benchmark results might not be a vibes-based judgement, but it could be a reasoning error.
Oh btw, there is nothing, and I really mean it, nothing in the Node world faster than that
I would like to also point out from a small sample of vibe coder friends who are ignorant to tech stacks and just let their agent decide, the default stack is always Next.js, Vercel, and Supabase.
Why are agents when given control to decide, almost always choose Next.js? SEO/AEO?
Aside from a more complex web app for the future benchmark, I have suggestions of what else I'd like to see included:
- Lines of code / surface area of the framework - easier for an agent to find the "right" API when there are fewer - Security surface: number of dependencies per framework - help keep the vibe coders secure - "Number of non-blank source file lines", show both numbers with and without comments included.
it chose plain solid wo a frameworks since i wanted the backend in rust anyway.
the rationale was streaming ai responses is better in it, since react re-diffs the dom every time a token is streamed, while solid just updates the exact node text changed.
tbh nowadays ive stopped caring about frameworks. wtver is comfier for the agent to write in, with enough back pressure from tests, ci and lifting so that agent fuckups dont reach me is good enough for me
this is what i was building https://github.com/clauseo-ai/boxbox2