> 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?
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".
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.
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
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.
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.
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.
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.
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.
> 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.
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.
"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?
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.
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.
> 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.
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.
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.
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.
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
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.
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).
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.
$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 :)
> 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.
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.
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.
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 want this to be true too but youâre essentially proving the point by demonstrating you have to write the wasm by hand if you want it to be compact.
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.
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.
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.
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.
> 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.
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 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.
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.
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.
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 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.
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.
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!
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?
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.
> 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.
> 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).
I always use Vue.js and I'm sad it is not included here.
Mainly because it has the smallest footprint and arguably the best performance of the powerful JavaScript frameworks.
It is, maybe it would be more accurate to say that this is a meta-framework benchmark. The one youâre looking for is Nuxt
Nuxt is included.
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.
Lol. Very fair.
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.
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.
Yes, Mithril enhanced with signals feels very efficient und saves tokens.
Big Mithril fan here - going to check this out!
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?
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".
Astro comes out on top with the best time, #2 lowest spend and zero client side JS. I know what I'm using for my next project.
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.
I actually find that agents are not especially performant with the âuse Astro plus whateverâ approach.
They seem to struggle to reason about the boundary between the two.
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.
Even for highly interactive projects, Astro is still my favorite build system. Just toss the SPA component into the single Astro file and you're done.
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.
> I know what I'm using for my next project.
Django?
next project? pun of the year?
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.
The frameworks are almost always listed in the job requirements.
Why wouldn't they be?? That says nothing about who's pushing it. Companies ask for it because developers use it. That's what makes hiring easier.
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.
Individual contributors are almost never writing job postings or performing hiring.
I didn't say they did. I said companies writing those job descriptions does not establish causality. You've got it reversed.
> 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.
>thereâs no need for SPA
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.
The complexity is in the host of tools, libraries, and processes to build and deploy the SPA.
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
https://www.infoq.com/presentations/Simple-Made-Easy/
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.
React Components are actually a far cry from OOP
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.
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.
I have no idea what you are talking about.
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.
Extraordinary claims require extraordinary evidence. Letâs see it.
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.
[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.
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)
>The current common use case for these frameworks is that most developers cannot write original software
It most certainly is not.
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.
> 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.
The impact of framework/tech-stack mostly reveals itself, once the project is big. For small/medium projects you might not notice.
> 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.
> It's the inverted invented here syndrome ;)
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:
https://en.wikipedia.org/wiki/Software_framework#Comparison_...
https://martinfowler.com/bliki/InversionOfControl.html
It's obviously a grey zone, but React is generally considered a library more than a framework, and it definitely seems to be among OP's vexations.
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.
I think you put way too faith in a human capacity to plan in such a "long-term".
That's where most complo theories fail...
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.
> If you roll your own - and you will,
This is something that people who cannot live without frameworks often repeat, but its a fiction of their own creation.
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 take a more nuanced view.
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.
How large were these applications?
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.
Youâre not understand it because austin is trolling.
So, you do copy and paste.
So, you just made a bespoke framework with the most inefficient version control system possible.
Then⊠what is a framework?
So for my question about large projects you shift into small projects. Got it. Nice goalpost moving.
How many colleagues have worked with your codebase?
In my oldest project, which I have not worked on since 2019, I received a bunch of pull requests from other developers.
It helps when you write software other people want to use and provide good enough documentation.
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.
Uh huh. So you don't have any repeated code between those large applications? Nothing was copy and pasted? You've never re-used a single thing?
If that's true, that's just pointlessly wasteful of your time and effort.
Thanks.
"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?
So you spend time fitting the cartwheel you had handy to their 18-wheel truck?
We have different wheels for different use cases. You can't use the same wheel for all of them.
No. I choose the tool that is best for the project. I donât reinvent tools because I donât get paid. Miraculously, Iâm fully booked out.
It's sad that you were never given a chance to clean up your technical debt, as it seems to have marred your perspective.
It's not your fault, since most companies don't want to invest resources on properly maintaining their code.
Those are some weird, incorrect assumptions that you have!
It's not your fault, since assuming the best about people on the internet is not actively rewarded by social media these days.
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.
How does me disagreeing with you affirm that statement? It does not. âInvestingâ means youâre expecting more in return: What would that be?
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.
Yeah! That's definitely the case sometimes-- just not when writing "large applications" like the GP.
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.
HN has decided React is why some ad-infested SPA they hate to use downloads 15 MB over the wire and can't accept that it's like 150 KB.
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."
"Large applications" like hundreds of lines of code? Uh huh.
For reference, my last job at an industry giant had a frontend-facing monorepo of a million lines or two.
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.
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.
> 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.
> If you roll your own - and you will
That's the best case. Usually it was just thousands of lines of jquery spaghetti.
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)
The guy above makes this point across the thread and I'm pretty certain he has never worked in a team on a complex app.
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.
Who made this jquery spaghetti? If you couldn't properly organize stateless functions, you were doing something wrong.
Where's "stateless" coming from? The underlying purpose of frameworks like React is to manage mutations to the fundamentally stateful DOM.
A car purpose is to take you from a to b, so lets put the gasoline in the cup holders.
This comment makes no sense
> 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.
An illusion, I suspect. All software needs maintenance, and someone driving it, even if they are prompting an agent.
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
How is this an illusion? Thousands of people work on React, Svelte, Vue, Chrome, Linux, etc. Most aren't paid
I was referring to the (potential) illusion of home grown agentic solutions being lower cost/effort over the long term.
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.
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.
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.
When I write my large vanilla applications I keep state in only one place. It reduces complexity and increases execution speed.
So for all your pompous purist opinions, youâre committing the evil sin of global state?
Meanwhile, LLMs have massively buffed internally developed software.
I guess the conclusion is Angular was the worst choice pre AI and continues to be post AI
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.
Jeez, does knowing JavaScript: The Good Parts make one dated now? guess i'm old too :(
In a couple of years the publication of that book will be closer to the invention of the web than the today.
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â.
> Java got popular because it forced everyone to code similarly
I think it, also, had a lot to do with the promise that most machines could run Java if they had the runtime installed
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
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.
If anyone interested here is the source code all done by Opus 5.5 https://github.com/ramigb/esdara
HTMX is interesting.
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.
I am still 95% sure async/await was a mistake.
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.
just because a keyword makes shitty devs shoot themselves in the foot, you shouldn't remove the keyword
I'm still sour why goto doesn't exist in javascript
It's limited to looping but there is a shockingly similar concept in the label statement that few seem to know about (for good reason): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I mean everyone should know labels if you have to break inside a nested loops. At least I hope so cause then that code has some bad bugs in it.
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
The solution is stream iterators. They are sync when they can be and async when they must be: https://docs.bablr.org/architecture/spacetime
> 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.
Yeah it's fixable. Everything I've built is built on top of a Symbol.streamIterator protocol that omits the unnecessary deferrals. The code looks like this: https://github.com/bablr-lang/node-fs/blob/6dabc6916082eb09c...
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).
> in the agentic era, when developers are no longer typing code by hand
I hope I'll be the last person on Earth writing code by hand.
Plenty of people will be coding by hand for years to come. They just wont be employed for doing so.
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.
They will slowly get eaten by more dynamic competition.
Since when do more dynamic companies win?
Microsoft is doing fine.
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.
> 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.
Technologists uncritically doing the bidding of Silicon Valley billionaires. Same as it ever was. https://news.ycombinator.com/item?id=50274456
basically every single point here is wrong and most are easily refuted by looking at anthropic's s1
Anthropic's S1?
$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.
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.
Thank the gods, nobody's forcing me to be employed.
Neocities ride hard on the old-internet hand-crafted HTML aesthetic. Maybe we could start a similar club?
This is buried at the end.
> 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 :)
> 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.
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.
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.
Nope. I have more than 15 years in the industry. Sorry.
"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?
and what % of users have JS turned off? 0.00001%?
HN uses JavaScript though, not just plain HTML.
And it certainly doesn't do "plenty."
HN is perfectly usable without JavaScript enabled.
The only feature that appears to require JavaScript is search.
Which doesn't even make sense. You don't need JS to trigger a form with a GET method, nor do you need JS to render the serve response to that GET.
> 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.
At least one (or maybe two depending how you define things) of the examples does that. Because you mean "client side javascript".
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:
https://developer.chrome.com/docs/web-platform/declarative-p...
Which basically stream HTML fragments from the web.
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:
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 want this to be true too but youâre essentially proving the point by demonstrating you have to write the wasm by hand if you want it to be compact.
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.
A small set of changes to AssemblyScript could do this, but most people would still grab for Emscripten with a shadow stack and asyncify hacks.
no, you can write c/c++ or rust
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.
Read more here: https://turbo.hotwired.dev/handbook/introduction
Elixir has a similar mechanism with Phoenix LiveView.
I am backend, not frontend but doesnât this basically mean that the data will never be indexed by a search engine?
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.
You can
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.
> 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.
When was the last time a website crashed on you?
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.
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.
Java script frameworks are just extra boiler plate that isn't needed in the age of ai-coding.
Server side page generation with a sprinkle of js will give you the same results with GBS less of packages and comple time
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...
[flagged]
LOL
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.
Your mistake is trying to fight people. You don't have to do that. You can just let them suffer from the consequences of their own decisions.
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.
All web pages should be WASM binaries now.
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.
I'm currently working at an enterprise SPA and it also doesn't work well.
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.
Interesting, Iâm just sad svelte didnt behave better because of the LLM reading migration guide on every answer
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).
AI is notoriously bad at estimating length of tasks. Like humans.
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.
Glad to see Astro doing well here. It's by far my favorite way to build sites of all kinds, both content rich MPAs, and react heavy web apps.
Interesting article. Kind of seems like you'd want a more complex task, there's not much differentiation here.
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.
If you want to see how to write a maintainable application without a huge framework here's an example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...
It uses two 500-line libraries, one for using JSX syntax, and the other for MVC.
Interesting that the lines of code are basically the same across all frameworks, including vanilla JS.
I'd really like something more out of field in this comparison. I'm using Elm a lot, and find Claude absolutely amazing at it.
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".
It's a fair reason to question the efficacy of benchmarks but that doesn't necessarily follow on to a defence of the efficacy of "vibes."
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.
Angular sucks, I always knew it, and now we have some data that itâs broken even for agents. Iâm not surprised
> The PokĂ©mon app is small and doesnât represent a large, complex real-world application.
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.
If AI sucks at simple Angular applications, why would you expect it to fare better with complex applications?
What is the biggest app that you have built?
What does that have to do with what I said?
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.
On the Internet I see all the time people who are building equivalents of bike sheds criticizing people who are building skyscrapers.
Your first sentence is telling me you were in more of a bike shedding projects than skyscraper one.
Well if you aim to make complex real-world applications you also should not use Angular. Hate towards Angular comes with experience.
[dead]
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.
I literally haven't seen a single benchmark ever that didn't put angular at the bottom. Used that crap for 8 long sad years. Good riddance.
I suspect that results would be different if the app was a bunch of boring forms with complex validation rules, which is often encountered in jobslop.
Not necessarily that Angular would win that, but I imagine that it would at least significantly shuffle the order.
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.
Nice to see Nuxt holding its own. Astro or Nuxt are my gotos for client work and personal projects.
where is jquery? :(
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.
On 64% of websites.
Shhh we donât talk about it
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.
https://github.com/anthropics/skills/blob/main/skills/web-ar...
htmx for the win, as always
not a surprise - frameworks or libraries that were easier for humans e.g htmx, hono (expressjs like) are also easier for agents.
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!
No Vue, huh
> 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?
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.
It is fairly obvious that it is all going to be some kind of React/JSX with tailwind.
It's definitely all tail wind
> 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.
Nuxt continues to be under-rated, considering how much you get from it.
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!
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
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.