AI cost of using anything is a good yard stick to measure things by. Red flags are a high degree of verbosity in tool outputs, complex failure modes, and slow running tools. Basically all that results in AIs having to look and dig through more output (tokens) and spend a lot of time polling tools for readiness (more tokens). The more complex a build for something is, the worse it gets. Especially if you also include things like running tests, linters, and all the rest. It adds up quickly when AI reasoning is causing a lot of trial and error to happen. It will eventually figure it out. But it might not be cheap.
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.
> One of my pet peeves with the web development community is that so many of the decisions we make are vibes-based. ... All of this breathless boasting is usually offered with zero evidence
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).
Besides a rewrite to another framework using AI, another option is to modernize the framework with AI instead. Personally, I started to like Mithril after having worked with it for a few years. Instead of rewriting it to a better maintained alternative (mithril doesn't have much active development going on since 2015), I used agents to add signals, proper state management, typing, ssr, computed properties, Bun tooling and more to it. Thanks to the existing test suite, changes landed quite reliably. Source: https://code.garage44.eu/jeroen/mithril
There are also new minimalist frontend spa frameworks built from the ground up to be clean and simple and fast and easy for ai. E.g. https://arrow-js.com/
That truly looks agentic. Few commits in spring 2021 then nothing until a flurry of commits in spring of 2023, then absolutely nothing until March 2026, then we get 160 commits, and fast-forward until today, not a single change since then. https://github.com/standardagents/arrow-js/graphs/contributo...
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.
> 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.
Yeah it's really enjoyable to be able to take old, stale dependencies, and simply make them into something great, typesafe, ESM, well tested etc, without having to change the whole codebase.
This benchmark is too simplified to be meaningful. The choice of a framework is rarely based on speed alone, it factors in other elements like the user's domain knowledge, long term maintainability and the framework's track record itself w.r.t security and development of features.
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.
It's also used on a dead simple app. These comparisons are almost always using apps no more complicated than to do apps, which is lightyears removed from actual commercial products
Yeah the author points out it's not Figma but ok how about doing something in between like a social media application with relatively complex UI flows? Astro is obviously gonna kill it on a site that's just presenting fairly static content, but how does it handle making a more performant and pleasant reddit-like site? And which one works best if you spin up a roadmap of 100+ features and have 6 or 7 "teams" of subagents working on it at once?
It scores well here because Astro is for “content-driven websites” and that’s what the benchmark app was. I’d be curious how different the results would be if the app was highly interactive, with nontrivial realtime/async stuff going on etc.
And then you just use your favorite js framework with Astro and it will still be good. I use Astro with react and heroui a lot. Since the latter does not need any js for many components anymore you still get zero js builds unless you actually need interactivity.
Agreed. Go with solidstart (who just released a big V2 upgrade a few months back) if you want an extremely elegant solution to async, error handling and heavily concurrent behaviors.
Very easy to setup and way more readable than the equivalent React code.
Can confirm Astro is very very pleasant to use, and the escape hatches for when you do need something a bit more heavy hitting feel very well designed.
But is zero client side JS necessarily better? I prefer the progressive enhancement philosophy of SvelteKit. When your internet connection and browser does support JS, it makes for a faster user experience.
The are some very real costs to JavaScript frameworks. These frameworks do not exist to empower developers. They exist to:
* 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.
> so that employers do not have to invest in training developers.
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.
>> Front end frameworks are usually pushed by developers, not management.
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.
From my own experience, I suspect you are conflating correlation and causation.
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.
But developers tell the company to use it because they need it on their resume for the next gig.
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.
> If it were I suppose we would be seeing way less react and more vanilla with jquery on forms and normal website stuff.
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.
> If it were I suppose we would be seeing way less react and more vanilla with jquery on forms and normal website stuff.
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..
A lot of times, most web app would be way better with purely server rendered pages. SPAs usually introduce a needless artificial separation. Too many times, I’ve seen an API that is tightly coupled with the web frontend instead of being agnostic and then starts being a maintenance nightmare because you have to coordinate across whole codebase because any Change Request updates the interface.
If you want an nice interactive interface SSR just won't do, it will inevitably leak. The separation between pure data and how that translates into UI through a wire interface is both natural and arguably desirable for many reasons. Typescript is a good language for UI. Java is a good language for backend. I disagree that evolving the API necessitates UI changes, or vice versa. You do need some amount of coordination of course, but if you can have developers do SSR, you can also have them do both SPA frontend and REST backend work - now more than ever.
Unless the interactivity would have span page reload, there’s no need for SPA. Figma, Spotify and Google Docs are food candidates for SPA as they have state that need to survive page navigation.
But in most web apps, interactive widgets are just little islands in the page. The higher concerns are routing, authorization,… which are already handled by the browser/server interaction.
I maintain a large reservations platform that I built as a SPA. Reservation systems are something that definitely needs to maintain state across pages, and where for instance the status of a customer's upcoming or cancelled reservations aren't simply walled off in a widget, but have effects across what actions are available to the customer. So it's surprising that so many of them are these terrible, slow and disjointed frankenstein SSR sites. (Think e.g. British Airways).
As with any SPA it should also be considered a problem if widgets updated themselves out of sync. My bank's reactive has this problem, and it's maddening. So my approach is to have all widgets and UI refresh upon central events from a single source of truth that's progressively updated as a data bundle from the server. Long poll the whole set of customer data, refresh it immediately after actions, and have those both trigger events that are recognized by all my vanilla widgets. What are we talking about? 15k over the wire every 30 seconds or on demand? Widgets that know how to adjust if something relevant to them changes? No big deal.
It's a different paradigm from either reactive or server side rendering, and the main advantage to me is the data consistency, as well as the development ergonomics of essentially having every UX element be just a view of the same data.
SSR on reservation systems looks incredibly cumbersome to me. Especially all those that still use crazy GET strings to hold state. "Pages" and user state are a front end concept.
This is exactly the approach I advocate for, always rerendering whole app on any data update. The components are very simple, basically just views parameterized by passed in props. The data fetch is in one place. Components notify top level on data change which necessitates a fetch/rerender
Unfortunately I get shouted down by those who think we must be maximally efficient even though in makes little difference in render time, and hate “prop drilling”
“Pages” is indeed a presentation concern, but state isn’t. Often in SSR, user state is stored server side and identified by a cookie. You only need this cookie on the presentation side and not have to store a copy of the whole state like you usually do in a SPA.
In most SPA, state is distributed with two copies floating around. Even if you do restrict the update flow, it’s still a lot of works to keep it consistent. That’s good enough when it’s partitioned and each side take care of its own state, but in most cases, the intersection is very large.
With SSR, the “page” is a dead copy. The only source of truth is the backend.
> In most SPA, state is distributed with two copies floating around.
In all client-server systems, state is distributed with "two copies floating around". The difference between SSR and REST+SPA is that in the SSR, your server code is creating the markup to make it presentable to an end-user, but it's still fundamentally a copy of the state that exists on the server, and it's not obvious why the transformation to markup rather than structured data (like JSON) is desirable on the server. If anything, with SSR you need to copy more state from the client to the server, where it doesn't really belong.
Many people phrase it like this, insisting that server-rendered HTML is simpler. To me, SPA's are the simpler approach. They remind me more of the .EXE's I used to ship.
As long as you stick close to first-party defaults, you can circumvent almost all of that. I've had far less trouble with build steps in SPAs that follow this philosophy, than with most native environments. It only becomes an issue if you need to layer tons of individual dependencies for things to work.
I also stay away from dynamic prerendering and/or hydrating. If an SPA can't be hosted statically, it should have a very good reason.
IMO building around Vue has really paid off over the last decade. They fixed the frequent Webpack config issues with Vite, they fixed the frequent Jest issues with Vitest, they improved build times a lot with Rolldown and oxc, they fixed all the annoying linter/formatter config stuff with oxfmt & oxlint, and Vue itself prevents tons of issues that plague React projects.
> These frameworks do not exist to empower developers
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.
Rich Hickey created the Clojure programming language to avoid complexity, and so it very deliberately does not employ OOP.
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
An important trait of good functional code is use of persistent data structures. JS code using React is anything but that with state hidden across numerous tiny functional closures.
The only language/framework that is truly functional in that sense is Elm.
I say this as someone who has done their fair share of Haskell, this just isn't a problem in practice, unless you're inexperienced or working with no experienced people.
I get this isn't everyone, and not everyone has the luxury to work in settings where this is a nonissue, but in those settings it sounds like the technology is being used as a restraint jacket for dysfunctional organisation.
When its been a problem, its always because the organisation was dysfunctional, "design" and "engineering" was what people did post humorously to justify spending time on their hobby horse.
Like 99% of components I've written project props on into other components and interpret them in purely. I often manage application state in external stores, which are decoupled from the view.
You‘re advocating for functional programming and then you go on to disregard a functional approach as the new OOP. Once again, your comment makes little sense.
If all you're doing is generating static HTML sure, I'm sure your toy library templating system or whatever pure declarative functions Rich Hickey gave you permission to write works perfectly fine.
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.
It’s not that extraordinary. HN loads even faster. The React approach just isn’t fast. I recommend visiting multiple sites and using Chrome’s performance tab.
Maybe in the much later stages of their lifecycle but probably most if not all JavaScript frameworks start to empower developers seeing as they are made by developers.
Would you mind elaborating? React[1][2], Angluar[3], and jQuery[4] all started as personal projects to abstract architecture for use by other people. These things started in an age of JavaScript years before TypeScript was imagined when writing large expansive architectures in JavaScript was a real risk. Full stack was not a thing yet and IE was still very real. However, most developers at the time were not writing large applications, at least not in this language. The primary concern for most developers was make things easy. I remember this was the intended selling point of AngularJS (first version) and it looked like garbage for Java developers.
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.
Why do you keep being arrogant and wrong? Developers use frameworks because their clients are not paying them to reinvent existing stuff, not because they‘re all horrible at their job (you, of course, are the best of all)
It absolutely is and comes with all kinds of bullshit posturing from people simultaneously explaining how awesome they are while qualifying what they can’t do without their framework. It is the kind of lies I see from my autistic kiddo where they know they have fucked up and try to paint a rosy picture in 6 or more conflicting stories.
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.
Lots of people can, but why should they if their clients are not paying for it? Even worse, if they switch developers, they now need to onboard them into bespoke solutions with little to no public documentation.
I would never hire you and people with that purist of a mindset.
In my last job I worked with someone who went on holy wars to troll people without evidence. I am not interested in working with anyone who seeks conventions over measures.
> 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.
This is insane goalpost moving. What defines an original application? Do I have to write the entire browser? Do I have to write the JavaScript engine? Which JavaScript version am I allowed to use? Can I use TypeScript and transpile?
Software engineers are called such because they use the tooling available to them to create something original. It would be idiotic to not take full advantage of available tooling to do that.
I think mostly your comment seems to agree with what I remember, except that even during the hayday of jQuery, "full stack development" definitely was a thing, as I myself entered my professional career as a "frontend + Zend Framework" developer essentially, and was hired as such after a short internship. Before we were called "full stack developers", I think the title was basically "webmaster", at least that's what seems to get closest to it, these were to people who knew the entire stack and maintained it, maybe this is what you're alluding to.
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.
Internally written software does suck? NIH syndrome is always referenced as a warning not as an aspirational thing, even smaller companies need to focus on their business model not JavaScript frameworks.
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.
I am not sure what you mean by limiting my ability. When you aren’t using a framework you have maximum freedom to determine all design decisions in the code.
It feels like you've invented some definition of a "framework" that no one else is using. Or why not go deeper and argue against libraries and APIs because they limit your design decisions.
No OP is correctly using the term "framework" as it's widely understood among those who develop them.
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:
React "is a library" in the sense that it has primitives you can procedurally use like normal javascript, but in practice it definitely is used as framework with all the usual dogmas.
Everyone always ends up fighting the framework. Work on a project long enough and it happens every time. It's understandable because the framework wasn't designed with your project in mind.
Their biggest plus, which some HN commenters baffingly either don't get or ignore, is that another company and volunteers pay for maintenance. If you roll your own - and you will, if you're not using one for a larger app! - you're now paying for library code and your money making application, thereby making less in total per hour spent.
You're committing the very sin that the original article fingers as the problem with the webdev culture.
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)
> The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"
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.
> You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper.
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.)
> The framework cost is always lower than rolling your own, and this isn't even the argument people are having
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, it is the painful experience of a decade of frontend software engineering and consulting, thank you very much. I‘m not talking about someones blog here, I‘m talking about commercial, complex applications.
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.
Exactly. When I realized my homegrown JS DOM management had grown into a version of Vue.js that I was the sole maintainer of, I switched to Vue.
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've worked at a dozen clients where, like in every software project, tech debt accumulated. Suddenly, when the DOM manipulation code or reactivity had bugs, I had to think about both sides of the coin - was the bespoke homegrown framework causing a weird interaction, or was is the component I worked on? One can hate React/Vue/Svelte or their models, but you can place trust in their maturity if you choose correctly
I have been writing my own large applications in JavaScript/TypeScript for 18 years and watching other JavaScript developers not figure out and blame everything else for their inability to program. I have never needed a framework or tried to recreate one.
I do tire of the failure to perform and the endless empty excuses.
I find it very hard to believe you and blaming developers for using trusted library code to not re-solve problems, thereby earning a living, is a pretty harsh statement.
How are you convincing your clients that they should pay a senior to re-engineer solves problems?
That’s easy. When you can deliver a smaller product in less time you are saving the client money. Sometimes reinventing the wheel is as simple as copy/paste.
A single dev can churn out a basic React app in like a single workday pre-AI, the important parts are not at all hard to understand and you get reactivity out of the box which is a lifesaver later on as your app grows in complexity.
I'm not understanding why you have the idea that it's a huge drag on productivity and hand rolling the same patterns everyone ends up needing will somehow be more efficient.
A day is a very long time when the architecture is supposedly already well known.
Part of the foolishness here is that you are convinced your approach is faster but you have no idea what my approach is. You certainly aren’t measuring anything so even if you were aware of my approach you are still just randomly guessing at the result.
So you admit your workflow does not reflect in any way or form the needs and processes of even a small to medium org, let alone half a dozen teams or more? That's not a great point of few for someone with opinions that strong on purity.
So, my home grown architecture is stupendously simple enough that I could train another developer, depending upon the developer, on it in 30-60 minutes.
Your comment completely reaffirms my original comment way at the top in that these frameworks largely exists so that employers can avoid any kind of investment in their developers.
> So, my home grown architecture is stupendously simple enough that I could train another developer, depending upon the developer, on it in 30-60 minutes.
Then it is not complex enough to support the needs of large projects.
You admitted it yourself. You work with a small group of people in small projects, but you got huge opinions.
Building a bespoke framework, for nothing of value except because you want to, isn‘t investing in developers, it‘s creating a huge cost factor for no gain.
How can you say that if you don’t know what my approach is? My current project is moderately large at nearly 100 files of TS code of which some are thousands of lines. It does not employ any framework and does not create its own framework.
"I don't use frameworks, y'all can't program" - I mean, good for you, but I want to pay my bills and my clients sure aren't paying me to reinvent the wheel for the 20th time?
But you are claiming the opposite in your replies to me. You are telling me that I am taking the wrong approach without knowing what approach I am taking. How could that be the best tool for the job?
The cool thing about owning your own decisions and not being utterly terrified of architecture is that refactoring is low risk and low effort when you have enough test automation in place.
The more I read of you the more I'm sure you're just putting on a facade. The effort needed for refactoring has nothing to do with "owning your decisions" or "being terrified", and your clients are certainly not paying you for it either.
Your numerous comments unintentionally reinforce my top comment. One of the primary use cases for these frameworks is to avoid training and investing in developers.
Sometimes you just write enough code for the problems at hand and not go for a generic solution. And then the result is a few hundreds lines of code, instead of 10gb node-modules folder.
React is like 150 KB, I feel like people ranting about "React" monstrosities don't actually understand the distinction between React the framework and other unrelated junk React doesn't require or depend on at all.
Even when writing large applications. It’s not like you’re using every method in a library or even the most important part. This issue is more prevalent in the rust and js ecosystem where instead of writing a few dozens line, the dev brings a whole library for that (almost everyone that uses chalk). Then they start to believe that one can’t write large software with simple code.
If you're using React, you're using 80% of what the library exports. It's actually pretty tiny.
> This issue is more prevalent in the rust and js ecosystem where instead of writing a few dozens line, the dev brings a whole library for that (almost everyone that uses chalk)
Here's some news: If you build your pretty native binary for your target operating system or the browser, you're using tens of millions of line of code.
Again, I definitely agree with all of that! I'm just trying to say that there's no reason to be such an absolutist. I try my best to use as few dependencies as possible in every project, but I would never pretend like frameworks are categorically useless.
Like most things in life, the best answer for each situation is layered in nuance. There's a reason that it's such a meme for senior engineers to answer most questions with, "it depends."
I mean this is quite literally what happened at my current firm. We forged our own path for good reasons, it all sucks, and the firm pays millions of dollars a year in dev salaries to maintain it.
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.
I've seen this exact scenario bankrupt firms and cost people smarter (but more arrogant!) than me their jobs. No handyman will ever shit on other people for buying and using tools instead of forging their own hammer. But somehow there's this facade of people on HN with this weird attitude.
There is a difference between something being usually a way in your experience and something always being X categorically. You are mixing most and all in an argument.
When these conversations come up they always degrade to two worthless arguments:
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.
Nah, the argument is worthless because apparently HN hasn't built anything more complicated than a contact form, therefore telling claude to use HTMX is always the answer.
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)
Why would you say that? What evidence leads to this conclusion?
I suspect your point is that Angular or React must exist as the primary work product for a team to operate, but why? Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do? To me this sounds like you have absolutely no idea how to program or that you have no faith that anybody can program original solutions... except for the people who invent large frameworks.
When these retorts come up they always degrade to two worthless arguments:
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.
There is no ad hominem, and yes, obviously anybody who does not accept your operating restrictions is clearly arrogant.
Ad hominem literally translates as "to the man". It is a direct attack on the person in conversation instead of the subject of conversation, which does not apply on nameless third parties.
> Ad hominem literally translates as "to the man". It is a direct attack on the person in conversation instead of the subject of conversation, which does not apply on nameless third parties.
They clearly feel personally attacked by your statement. Almost as if there is some truth to it.
> another company and volunteers pay for maintenance
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.
Maybe in some cases. In my experience maintenance often comes with exploratory work, the kind of where one needs to invest time, not to think about how your own side should work but in dissecting how a dependency or a target platform works in order to identify specific quirks that come and go with the passage of versions. I have seen significant acceleration in these kinds of workloads. This doesn't mean it makes maintenance free like some claim. It just makes it about 70% less of a burden
As a developer, React, Vue, Svelte, and the like absolutely do empower me to not have to deal with all the pain-in-the-ass bullshit of the jQuery and Gulp days.
IMO, the largest benefit of most JS frameworks is a great story for statee synchronization.
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.
People seem to have these conspiracy theories when in reality, frameworks do exist to make developers' (in aggregate at a company and in general) lives better. I'm not gonna write DOM manipulation code from scratch when React (or Solid, or Vue, or...) handles everything for me.
In my experience the large frameworks tend to make things easier for developers by bundling things into partially isolated components. They also tend to make the code much larger and more complex. For me working with the DOM is just a matter of assigning references to variables and making use of events (functions).
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.
I think HTMX has a wall where it makes sense to pivot to something else. In your case I’d imagine using something like Svelte would get you the same speed benefit over React but without the extra work required to get the agent to cooperate.
I tried to vibe code with HTMX and experience was miserable. I must admit i did it half a year ago using gemini flash, but compared to vibe coding with React at the same time with the same agent it had so much trouble with things that i expected to be trivial that i had to scrap the idea of trying HTMX.
I judge languages by how they look. JavaScript is a wall of const/async/await these days, which is ugly. Functionality aside (the APIs have gotten pretty decent), the language has gotten uglier. It used to be nice and nuanced even with boilerplate. Closures and prototype inheritance is neat. Walls of const are not. Does every enclosed function need a million consts for every expression?
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.
Yes, I keep saying this. Async await is like loading spinners - a fix for a problem that shouldn't exist in the first place.
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.
That JS supports await isn't nearly as much a problem as the fact that it defensively defers execution any time it encounters one.
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
> it defensively defers execution any time it encounters one
That's a (bad) JS design choice, for example C# doesn't do this. Actually I'm pretty sure even in JS, async/await gets transpiled to state machines, so I think this is easily fixable by shipping a new transpiler implementation that only defers when necessary.
I get your point, but I don't think we should go back to oldschool yield-based iterators to hack around a broken implementation.
I would like to see official support for `Symbol.streamIterator` and for the `for await?(item of iter)` syntax which would transpile to code like you see here (or all the way down to regenerator state machines if needed).
IMO the largest true value of the frameworks (and languages to some extent) is how they help long-running projects with many people coming and going. The most valuable trait was not what framework allowed, but what framework disallowed, preventing foot guns. E.g. Java got popular because it forced everyone to code similarly, at least more similar than other languages at that time.
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.
Doesn't the same argument and reasoning apply to agents? What exactly about agents makes the conventions and standardization of frameworks less useful?
Javascript is notorious for not having a standardized way to do things. It doesn’t have a strong opinion on anything really. So I buy the argument that frameworks displace or even increase ways to do things. React patterns, SPA, nextjs, its all just too much.
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.
Python is worse about this proliferation, despite the advice of its built-in koan (see: `import this`).
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.
I'm dating myself a bit here, but I'm reminded of Douglas Crockford's book, JavaScript: The Good Parts. The idea being that under all of the cruft and foot-guns, JavaScript actually had all the elements of a good language. You just had to be disciplined about using only a subset of the language.
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.
The combination of ES5 (and successors), Typescript, and community consensus resulted in everybody using “the good parts” without even having to think about it. Frameworks, in proportion, didn’t have to do much
I do agree, it’s just likely really hard in practice to keep agents disciplined. The most popular frameworks are quite substantial. For example my experience with agentic react development was both amazing - in that the sheer volume of drop-in interfaces allows you to create stunning interfaces previously reserved for startup darling design teams - and nerve wracking because the way agents integrate everything is just layers upon layers of hooks. hooks provide intentional loosely coupled plugin interfaces, but it’s not sane at all to take these to the extreme with literally 8 layers of state. im convinced it’s unsustainable and ridiculous. These AI apps are basically un-designed internally. Can’t understand how they’re maintained.
The element of a good language is that it doesn’t have the foot guns. If I shit on your birthday cake, you don’t eat it because a reknowned baker wrote that, “underneath the feces, it had all the elements of a good cake”.
We are kind of spoiled today. It's easy to forget how insane it is that you can write a program in Go or Rust and build a binary for all major operating systems with a single command. It's so nice
This is what I was thinking while doing some work on my projects. I've been a full stack focused developer way before the AI age and at that time DX was something that was a priority for me.
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.
> 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.
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".
I just used Astro yesterday for a static website I am deploying to cloudflare pages. I must say I was really impressed by the whole experience! From claude being super fast and diligent to the site structure being “decent” for the tokens and effort spent on it.
Divide the amount of revenue from the big AI companies by the total number of developers worldwide and you'll see that most are still mostly hand-coding despite what the megaphones on the internet say.
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.
Seriously, we’re in a bubble here and everything thinks everything is touched by ai now. That’s not true at all, people need to look outside of HN and Twitter. Lots of devs are refusing to use them. Quite a number of companies are happily chugging away by hand.
I highly doubt that most code by hand. I work for a big, boring public sector organization that is pretty broke, and even we've had Copilot licenses for a long time. We just use the cheapest models to keep the bill in check.
It's a mixed bag. The company I work for (nearly $6 billion anual revenue, southern EU) only started giving out the lowest tier of Github Copilot licenses this summer, and only widely at the business units they're desperate to see grow (I got lucky there due to wearing multiple hats). Everyone else keeps coding manually, although the nerdiest of us catch up with Codex/Claude/whatever on our own time, same as it ever was.
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.
I agree in principle, but I don't feel in a position to bargain: I'm a junior dev earning below my region's average salary (for all industries, not just tech), far below other engineers my age because reasons, and my education is now becoming obsolete for industry. I'll let others take the high ground, I just want to stay employable and not lock myself out of a decent salary.
$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.
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.
At least in my organization we simply use the cheapest models. It's possible for a developer to do most of their coding with something like GPT6-Luna for less than 100$ a month with current prices.
I don't know anyone dev spending even 500$ a month on AI, but nearly everyone does use it to write code. And I work a broke public sector organization, not some fancy startup or big tech.
> 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 :)
Just use plain HTML for God's sake. HN demonstrates very well that you can do plenty without some Javascript monstrosity. At the very least, make your your websites degrades gracefully when JS is turned off.
I really have no idea where comments like yours come from. I‘m baffled each time I read it. You must be really, really far removed from any commercial browser development process.
I really have no idea where comments like yours come from. I‘m baffled each time I read it. You must be really, really far removed from any commercial browser development process.
"do plenty" or just use React for everything and have a single thing where you don't need to worry about the limitations or having to remake the same stuff the framework provides?
> At the very least, make your your websites degrades gracefully when JS is turned off.
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.
> Frontends are rewritten because some framework or another is “better for agents.” (Did anyone think to ask the agents?) The resulting code is “faster,” the agents make “fewer mistakes,” etc.
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.
Weirdly, this underscores my personal non-AI experience of Nuxt, which is that it is almost easier than you'd like it to be.
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.
It's astonishing to me that even after a decade of SPA frameworks, most authors don't understand how a browser engine like Chrome works. There's enormous cost of manipulating the DOM from JS, as HTML elements get bound to JS objects lazily.
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:
String manipulation for HTML is a great way to introduce security vulnerabilities.
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.
I don't disagree or really have a dog in the fight for three out of your four points, but it's unfortunate that WASM gets such a bad rap. The blobs are large because popular compilers force the semantics of popular languages into the Turing tar pit. WASM binaries are pretty compact by design:
const binary = Uint8Array.fromBase64(
"AGFzbQEAAAABBgFgAX8BfwMCAQAHBgECeDIAAAoJAQcAIABBAmwL"
);
const module = new WebAssembly.Module(binary);
const instance = new WebAssembly.Instance(module, {});
console.log(instance.exports.x2(3));
This is a trivial and useless example at 39 bytes, but a real example could be more compact than comparable minified JavaScript.
actually minified js is super compact. representing things as string immediately gives you the advantage of basic variable length encoding, whereas most binary formats will give you 32 to 64 bit integers with weird paddings for most structure fields. Afaik WASM also uses SSA forms which are super big compared to more compact representations such as RPN
I don't think that wasm is inherently uncompressible.
I think it's more that tools like emscripten include the entire C++ standard library because most existing libraries expect them to just be available for free. But hopefully that would change as more web focused libraries are created.
Reality is majority of websites don’t need highly performant dom ops. Most sites also don’t even need all the JavaScript they have to begin with but that’s another story.
I don't understand how does manipulating html as string exactly makes anything better? wouldn't that cause for the whole page to just re-render with every small change?
There are server side frameworks that use web sockets so you can refresh small parts of a page and not the entire page. This involves smaller round trips from client browser to web server. In my opinion, for data intensive applications it makes more sense rather than REST APIs returning JSON payloads, parsing JSON into objects client side, and then update the DOM.
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.
that still doesn't answer the question, are you suggesting to maintain 1 giant string that represents the whole page whereby document.innerHTML is called everytime the string changes, or are you suggesting something else?
There is JS in the browser and will update a small part of the page by requesting HTML snippets from the server, not JSON payloads. Look at the Turbo+Stimulus framework. Its shipped as a library in Rails but it can be standalone - I built a small local webapp with it and the backend was Golang.
Frontend has exploded in complexity. Separating concerns whereby the frontend does not care about the backend leads to better quality.
Just rendering a simple e-mail client on page 5 of a search result is simple enough to understand that streaming html for that state would require rocket science of string manipulation.
Besides that, you still did not answer how is updating the entire innerHTML for small changes better than just updating affected nodes?
You'd be right, but you're not really manipulating the HTML in any random way, HTML templating ensures you are making valid DOM edits.
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.
> An actual high performance framework should manipulate HTML as a string directly
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.
The modern state is different too because the DOM can optimize <template> tag contents as well or better than string parsing, with the current big caveat being understanding the big performance difference between `document.addChildren(myTemplate.contents.cloneNode())` versus `document.importNode(myTemplate.contents)`.
One size never fits all on the web. Although those references to elements can be costly they’re also valuable. If all you used was HTML string manipulation then event handling would be an utter nightmare. You’d have to make every event handler a global variable so you can specify it in onchange=“” attributes and the like.
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.
this doesn't even benchmark anything really wrt user experience, so what does that have to do with the article?
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.
> There's enormous cost of manipulating the DOM from JS, as HTML elements get bound to JS objects lazily.
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.
> An actual high performance framework should manipulate HTML as a string directly
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
> what most people actually would need is Chrome's experimental declarative partial updates
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.
They don't care. The big selling point besides being able to run on every platform is that users understand there is no reasonable expectation of quality when it comes to the web. If a desktop application freezes up and crashes, users will gnash their teeth and curse your name while they are pressing ctrl-alt-del and trying to get their system going again. A massive pile of react slop? Just shrug and refresh the page.
> If a desktop application freezes up and crashes, users will gnash their teeth and curse your name while they are pressing ctrl-alt-del and trying to get their system going again.
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.
This just scratches the surface of the cost-benefit analysis of JS frameworks. Frameworks were built mostly to simplify state mangement as we moved to complex apps from web forms, as they simplify partial loading/state updates.
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.
I disagree. Even if you don't put too much weight into this test's results, if you stick with vanilla JS your agents (or human devs) are going to write `element.addEventListener` and `document.querySelectorAll` countless times, and each one is going to drift a bit of time.
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.
As perTFA, the pure HTML/JS page did worse. In some theoretical sense you are correct if you assume an infinitely intelligent model. Given a smart enough system then writing in a mixture of HTML/JS and the JS is mostly a wrapper for WASM/Rust is the best. Any cognitive system has limitations and at a certain point developing intelligent abstractions and tools for thinking will give it better results. We can debate whether React or Svelte is better as a tool for thinking about the DOM and State, but they are both much better than pure HTML for any sufficiently complicated website. As the article shows it doesn't even need to be that complicated of a website to get a benefit for using a framework.
The whole reason for switching from server-side to SPAs and frameworks was increasing responsiveness for users, better transitions, and allowing optimistic updating.
All of these thing still matter no matter what you are coding with.
The vanilla advantage is also there in a pure client-side pwa. Arguably it’s even bigger, because the bundle size ends up way smaller and the agent needs to hold less in context.
Plus all the other vanilla advantages: fewer dependencies, lower maintenance, less retraining, etc…
I'm reading that agents can now mash up video games that were written in assembly. At that point I have to wonder if the abstractions are adding anything.
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...
I mean maybe I'm too grumpy, but never in my life did I think I'd have to fight against a strong contingent of people who really don't see the value of abstraction. Taking crazy pills must feel like this.
They also were unnecessary even before AI, the biggest advantage of React over HTMX-style apps was that you could recruit someone more easily but the SPA complexity wasn't worth it and it scaled terribly.
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.
We just write different stuff. For content driven websites you can skip js frameworks altogether. For web apps it would not be a good idea.
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.
In typical HN style, you are both pretentious and wrong. Javascript frameworks save you the complexity of an agent holding the entire library code in their context. For example, an agent can work with 2-4 react components for a current ticket without needing to know each line of internal React code.
This experiment could be reframed as: which framework's abstractions are best suited to building "the Pokémon app."
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.
I enjoyed reading this article. I think it's an important article. Even though people might disagree about certain definitions like "maintainability," I liked what the author did by sticking to objective measurements which do correlate somewhat with the things we care about: Ability to implement the product fast, with few tokens and with as few lines of code as possible in the final product. These are well chosen metrics IMO.
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).
This is true but its assessment did match my personal experience as a developer who has built quite a few apps with React + Node.js + Postgres combo. The project I had written with my framework was only about 1400 lines of code (mostly declarative HTML) and my experience is that applications of that complexity would normally approach or exceed 10k lines if well written with React/Node/Postgres. So its assessment even seemed conservative based on my own estimate.
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.
The point of using a framework is to reduce mental load at expense of customizability. The moment you need to change something in the framework - this mental model falls apart.
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.
A significant part of the cost is that newer framework APIs are not known to the current agents. So they need to discover them and learn them on the fly. Eventually future models will have them trained into their weights and efficiency should increase. In the grand scheme of things, the cost might be negligible if it makes up for it in performance or quality.
I've built large FE systems with millions of lines of code pushing tens of billions of dolllars in revenue (I was lead FE dev on that one).
The idea that failing to do a small project (that should be clearly represented in the training data) means failing even harder at bigger projects doesn't suddenly gain merit because I have a lot of experience and have worked on big projects.
When I was running a small dev agency with a sprinkling of web projects, Angular was useful because it every project looked more or less the same. The rigidity (and verbosity) it imposed was an advantage in this setting, as it helped with the cognitive load when switching between projects. Apart from that, I wasn’t a fan either.
Angular is an absolute joy to work with as a framework, improving year after years, not scared of shifting heavily when a new favorable paradigm comes in. You never had data to prove that angular sucks because all the benchmarks don't say so.
Solid work, but it would be really cool if we can also test Pokemon motions and how the game responds in real-time. Is an agent able to think about reactions, directional movements and attack patterns of each Pokemon is where the real intelligence test lies.
Traditional languages may have their limitations, but [C++, Rust, JavaScript, TypeScript etc] can still do pretty well.
I don't want to sound overly harsh here, but this is the kind of nonsense that shows why "vibes" are so much more trustworthy than "benchmarks" for assessments of what tools to use. The author has self-awareness about how flawed this benchmark is, but he still presents it as "evidence".
Not disagreeing, just adding on, "experience" can involve a sixth sense / gut feelings. But when making a recommendation, an engineer should nonetheless be able to articulate their view with sound reasoning.
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.
Now that IE is dead and most of the cross-platform implementation differences have been fixed, you are generally better off with vanilla JS instead of jQuery.
my experience is that one-shotting a simple front end works great. Then you want to add features and move things around and each turn starts getting slower and the single page with JS and CSS and HTML starts to turn into a 3000 line monster and your context window starts to creak under the strain of even simple changes, because the LLM has to keep more and more of the application in its head just to make relatively small changes without breaking something else. Either you should have started with some kind of framework with hygienic rules on how to separate concerns or at minimum a good set of coding standards that force the LLM to start building clean components from scratch. The benefit isn't necessarily cleaner code for its own sake, it's that the LLM can work on one part of the application without having to understand the whole thing every time. That being said, once you have a 3000 line prototype it's not that complex to simply ask the LLM to refactor it into a set of orthogonal components. As long as it was building unit tests using playwright or something this can turn your slop into framework code cleanly. The interesting question is whether you saved anything by putting off that structure in the first place.
I run into this problem turning claude artifacts into things I might want to maintain longer term.
And a little research turns out that anthropic itself makes available a *react* based artifact builder so you don't end up with SLOP from the get go. You could probably modify the template to work with your framework of choice.
This was very interesting and I was fortunate to have my bias validated further for HTMX ;)
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.
interesting article. i think there is still benefit to well maintained ones like react, it will be well tested and maintained by specific people with expertise to it
AI is quite good at vanilla as well. Do you actually need a framework? If most of your pages are static with a tiny sprinkle of interactivity, React might be overpowered. TS + HTML + CSS is all most sites need (that's my hot take).
I mean it just seems like even in the agentic era, you should know when to use the right tool for the right job. The site shown seems perfect for htmx style websites, so idk why you would use an SPA. Still very cool experiment, appreciate the data and human writing!
Interesting... Training data is really the same as experience in human developers. I favour frameworks I have experience in, the thing is most AI models have similar weights of "experience" and hence certain frameworks are accelerating in popularity.
> I should first note two caveats about my benchmark:
> 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?
> But in the agentic era, when developers are no longer typing code by hand and are thus less constrained by DX, I still see vibes ruling the day (and not just in the sense of “vibe-coding”). Frontends are rewritten because some framework or another is “better for agents.” (Did anyone think to ask the agents?) The resulting code is “faster,” the agents make “fewer mistakes,” etc. Once again, these claims are often made without evidence. Whenever I read one of these accounts, I think to myself, “Where are the benchmarks?”
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.
Anecdotally, sveltekit 2 was super quick to use for me. I tried building a somewhat interactive app with htmx and found the user experience was often incorrect on the Claude 4 family models. I switched to sveltekit 2 and it produced what wanted almost immediately. Features were added instantly. Even today with React and Opus 5.5 it couldn't match the development performance of version 2.
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.
If you are working on a typical web app, you either use a canned framework or write your own. Models are trained on existing frameworks, so they don't have to hold it all in their context to reason about it; it's baked into the weights. Same goes for the humans reviewing the code. I don't see the benefit of writing your own framework for most companies.
Unfortunately the author is not only correct about front end development vibes, but due to this state of affairs, I ceased to recognize browser based UIs as being software development at all. Too much browser tech is broken to call it software. As for agents, good for them!
How's about no JS framework and just use the browser APIs? If you want token efficiency, that's the way to go. If you want web app efficiency, that's the way to go too. JS frameworks were always for the horde that does not do the homework, and the horde that wants to talk about it all day long rather than whatever the fuck is the purpose outside of this damn computer.
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.
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).
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.
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.
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.
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.
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.
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.
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..
But in most web apps, interactive widgets are just little islands in the page. The higher concerns are routing, authorization,… which are already handled by the browser/server interaction.
As with any SPA it should also be considered a problem if widgets updated themselves out of sync. My bank's reactive has this problem, and it's maddening. So my approach is to have all widgets and UI refresh upon central events from a single source of truth that's progressively updated as a data bundle from the server. Long poll the whole set of customer data, refresh it immediately after actions, and have those both trigger events that are recognized by all my vanilla widgets. What are we talking about? 15k over the wire every 30 seconds or on demand? Widgets that know how to adjust if something relevant to them changes? No big deal.
It's a different paradigm from either reactive or server side rendering, and the main advantage to me is the data consistency, as well as the development ergonomics of essentially having every UX element be just a view of the same data.
SSR on reservation systems looks incredibly cumbersome to me. Especially all those that still use crazy GET strings to hold state. "Pages" and user state are a front end concept.
Unfortunately I get shouted down by those who think we must be maximally efficient even though in makes little difference in render time, and hate “prop drilling”
In most SPA, state is distributed with two copies floating around. Even if you do restrict the update flow, it’s still a lot of works to keep it consistent. That’s good enough when it’s partitioned and each side take care of its own state, but in most cases, the intersection is very large.
With SSR, the “page” is a dead copy. The only source of truth is the backend.
In all client-server systems, state is distributed with "two copies floating around". The difference between SSR and REST+SPA is that in the SSR, your server code is creating the markup to make it presentable to an end-user, but it's still fundamentally a copy of the state that exists on the server, and it's not obvious why the transformation to markup rather than structured data (like JSON) is desirable on the server. If anything, with SSR you need to copy more state from the client to the server, where it doesn't really belong.
Many people phrase it like this, insisting that server-rendered HTML is simpler. To me, SPA's are the simpler approach. They remind me more of the .EXE's I used to ship.
I also stay away from dynamic prerendering and/or hydrating. If an SPA can't be hosted statically, it should have a very good reason.
IMO building around Vue has really paid off over the last decade. They fixed the frequent Webpack config issues with Vite, they fixed the frequent Jest issues with Vitest, they improved build times a lot with Rolldown and oxc, they fixed all the annoying linter/formatter config stuff with oxfmt & oxlint, and Vue itself prevents tons of issues that plague React projects.
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
https://www.infoq.com/presentations/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.
I get this isn't everyone, and not everyone has the luxury to work in settings where this is a nonissue, but in those settings it sounds like the technology is being used as a restraint jacket for dysfunctional organisation.
When its been a problem, its always because the organisation was dysfunctional, "design" and "engineering" was what people did post humorously to justify spending time on their hobby horse.
Like 99% of components I've written project props on into other components and interpret them in purely. I often manage application state in external stores, which are decoupled from the view.
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.
I would never hire you and people with that purist of a mindset.
This is insane goalpost moving. What defines an original application? Do I have to write the entire browser? Do I have to write the JavaScript engine? Which JavaScript version am I allowed to use? Can I use TypeScript and transpile?
Software engineers are called such because they use the tooling available to them to create something original. It would be idiotic to not take full advantage of available tooling to do that.
> 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 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.
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_...
https://martinfowler.com/bliki/InversionOfControl.html
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.
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.)
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.
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.
I find it very hard to believe you and blaming developers for using trusted library code to not re-solve problems, thereby earning a living, is a pretty harsh statement.
How are you convincing your clients that they should pay a senior to re-engineer solves problems?
I'm not understanding why you have the idea that it's a huge drag on productivity and hand rolling the same patterns everyone ends up needing will somehow be more efficient.
Part of the foolishness here is that you are convinced your approach is faster but you have no idea what my approach is. You certainly aren’t measuring anything so even if you were aware of my approach you are still just randomly guessing at the result.
So, you just made a bespoke framework with the most inefficient version control system possible.
It helps when you write software other people want to use and provide good enough documentation.
Your comment completely reaffirms my original comment way at the top in that these frameworks largely exists so that employers can avoid any kind of investment in their developers.
Then it is not complex enough to support the needs of large projects.
You admitted it yourself. You work with a small group of people in small projects, but you got huge opinions.
Building a bespoke framework, for nothing of value except because you want to, isn‘t investing in developers, it‘s creating a huge cost factor for no gain.
If that's true, that's just pointlessly wasteful of your time and effort.
"I don't use frameworks, y'all can't program" - I mean, good for you, but I want to pay my bills and my clients sure aren't paying me to reinvent the wheel for the 20th time?
We have different wheels for different use cases. You can't use the same wheel for all of them.
It's not your fault, since most companies don't want to invest resources on properly maintaining their code.
It's not your fault, since assuming the best about people on the internet is not actively rewarded by social media these days.
> This issue is more prevalent in the rust and js ecosystem where instead of writing a few dozens line, the dev brings a whole library for that (almost everyone that uses chalk)
Here's some news: If you build your pretty native binary for your target operating system or the browser, you're using tens of millions of line of code.
Like most things in life, the best answer for each situation is layered in nuance. There's a reason that it's such a meme for senior engineers to answer most questions with, "it depends."
For reference, my last job at an industry giant had a frontend-facing monorepo of a million lines or two.
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)
I suspect your point is that Angular or React must exist as the primary work product for a team to operate, but why? Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do? To me this sounds like you have absolutely no idea how to program or that you have no faith that anybody can program original solutions... except for the people who invent large frameworks.
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.
Ad hominem literally translates as "to the man". It is a direct attack on the person in conversation instead of the subject of conversation, which does not apply on nameless third parties.
They clearly feel personally attacked by your statement. Almost as if there is some truth to it.
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.
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.
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
That's a (bad) JS design choice, for example C# doesn't do this. Actually I'm pretty sure even in JS, async/await gets transpiled to state machines, so I think this is easily fixable by shipping a new transpiler implementation that only defers when necessary.
I get your point, but I don't think we should go back to oldschool yield-based iterators to hack around a broken implementation.
I would like to see official support for `Symbol.streamIterator` and for the `for await?(item of iter)` syntax which would transpile to code like you see here (or all the way down to regenerator state machines if needed).
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 think it, also, had a lot to do with the promise that most machines could run Java if they had the runtime installed
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".
If anyone interested here is the source code all done by Opus 5.5 https://github.com/ramigb/esdara
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.
Microsoft is doing fine.
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.
I don't know anyone dev spending even 500$ a month on AI, but nearly everyone does use it to write code. And I work a broke public sector organization, not some fancy startup or big tech.
> 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 :)
Mainly because it has the smallest footprint and arguably the best performance of the powerful JavaScript frameworks.
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.
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.
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.
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.
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.
Just rendering a simple e-mail client on page 5 of a search result is simple enough to understand that streaming html for that state would require rocket science of string manipulation.
Besides that, you still did not answer how is updating the entire innerHTML for small changes better than just updating affected nodes?
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.
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.
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.
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.
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.
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.
Server side page generation with a sprinkle of js will give you the same results with GBS less of packages and comple time
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.
All of these thing still matter no matter what you are coding with.
Plus all the other vanilla advantages: fewer dependencies, lower maintenance, less retraining, etc…
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...
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.
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.
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.
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.
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.
I've built large FE systems with millions of lines of code pushing tens of billions of dolllars in revenue (I was lead FE dev on that one).
The idea that failing to do a small project (that should be clearly represented in the training data) means failing even harder at bigger projects doesn't suddenly gain merit because I have a lot of experience and have worked on big projects.
Your first sentence is telling me you were in more of a bike shedding projects than skyscraper one.
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.
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.
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...
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.
> 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?
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.
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.