> 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 have the same feelings about React, so much so that I've never given it a second chance. Vue handles my use cases when it does, and when it doesn't it hasn't been because I needed _more_ in any way that React offers.
> 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
This has largely been my experience navigating the JS framework world from basically the beginning of React. It's wild how poorly some of the earliest presentations about React have aged, as that framework has gone through endless major API/design refactors.
Not to mention that benchmarks are a very flawed way to assess technology for builds with complex and open-ended requirements. If you're operating in a constrained environment and you have a clear bottleneck that a particular tool can solve, then benchmarks can be really helpful. But starting on a new product from 0 that needs flexibility to pivot does not necessarily benefit from picking the fastest tool in the shed.
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.
I did this recently with a dependency that has stalled out. For the past 3-4 years, the ngx-infinite-scroller has been in maintenance mode of just updating the Angular version. Then the maintainer (which is a fork of a fork of the original) disappeared.
I forked, put AI on it to not only fix the issue I was facing with the new Angular (zoneless) but add full testing to it and make it resilient. Massive benefit to my apps and trust.
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 is beautiful. I believe people consider it complete mostly, that's why there have not been updates.
I have been doing the same and adding a bunch of features on top. Will check yours. Let's make super-mithril !
This benchmark is too simplified to be meaningful. The choice of a framework is rarely based on speed alone, it factors in other elements like the user's domain knowledge, long term maintainability and the framework's track record itself w.r.t security and development of features.
In this regard alone, it will make a lot of sense to spend extra $2 and 2 mins to trade off for a long-term maintainable codebase and code you can reason about than just something made quickly just to get it deployed fast.
In my personal use case, that would be Svelte 5 for me and I'm sure it will be something else for everyone.
It's also used on a dead simple app. These comparisons are almost always using apps no more complicated than to do apps, which is lightyears removed from actual commercial products
Yeah the author points out it's not Figma but ok how about doing something in between like a social media application with relatively complex UI flows? Astro is obviously gonna kill it on a site that's just presenting fairly static content, but how does it handle making a more performant and pleasant reddit-like site? And which one works best if you spin up a roadmap of 100+ features and have 6 or 7 "teams" of subagents working on it at once?
It may be partly due to how awful Angular v1 was. I know it put a bad taste in my mouth when I had to use it. But we stuck with it and things got way better with v2+.
I used v1 and ofcourse it scarred me but even v2+ versions felt like they encouraged over engineering compared to alternatives which I had a easier time wrapping my head around
Kinda interesting, but disjoint from all the real underlying reasons why React and other frameworks are so sticky.
After a decade of React, I'm not going to go go learn htmx or any other marginally better same-shaped tool for a new project, especially when it'd degrade my ability to review and debug another actor's work product. The cost of switching frameworks is now dramatically higher and the payoffs way lower.
Fundamentally, framework perf is about not incurring too heavy a cost for the abstractions, and then to improve dev efficiency. This matters most in the "explore"/prototype phase, when poor perf would be a good problem to have to care about.
In my projects, the real question has kinda moved down to "should I yeet 1/2 the app to wasm yet?" and similar higher-order questions.
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 haven't found that. I use Astro + SolidJS and it seems to work very well.
I intentionally avoid hydration (which I've always found to be flaky) and hydration-based frameworks like SolidStart, so possibly that helps. Or maybe that's just my own bias!
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.
> For “Vanilla,” note that the agent was told to use “vanilla JavaScript or TypeScript with Vite, without a UI framework.” Surprisingly, this underperforms several frameworks, which seems to demonstrate that having some framework can be better than nothing
I'd be curious how it does if you allow it some helpers or "micro frameworks" that are WAY short of a normal framework. Say vanilla js paired with nanostores as an example.
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.
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.
Either one can show a user stale data. Both need backend checks on user actions to make sure the user's view is current.
In my SPAs, server calls and the state copies they return to the client are numbered sequentially from the start of each session. A server response with a number earlier than the last client call is ignored. That mostly takes care of race conditions that arise from latency. Fundamentally this is similar to SSR in that the client will not update until the server sends new data... there is no client-side modification of the client data copy, ever, so it can never diverge from the last known server state. That would of course be a disaster. The difference is that the page can change progressively without reload, and the state is available between "pages" without more calls to the server.
> In most SPA, state is distributed with two copies floating around.
In all client-server systems, state is distributed with "two copies floating around". The difference between SSR and REST+SPA is that in the SSR, your server code is creating the markup to make it presentable to an end-user, but it's still fundamentally a copy of the state that exists on the server, and it's not obvious why the transformation to markup rather than structured data (like JSON) is desirable on the server. If anything, with SSR you need to copy more state from the client to the server, where it doesn't really belong.
Many people phrase it like this, insisting that server-rendered HTML is simpler. To me, SPA's are the simpler approach. They remind me more of the .EXE's I used to ship.
As long as you stick close to first-party defaults, you can circumvent almost all of that. I've had far less trouble with build steps in SPAs that follow this philosophy, than with most native environments. It only becomes an issue if you need to layer tons of individual dependencies for things to work.
I also stay away from dynamic prerendering and/or hydrating. If an SPA can't be hosted statically, it should have a very good reason.
IMO building around Vue has really paid off over the last decade. They fixed the frequent Webpack config issues with Vite, they fixed the frequent Jest issues with Vitest, they improved build times a lot with Rolldown and oxc, they fixed all the annoying linter/formatter config stuff with oxfmt & oxlint, and Vue itself prevents tons of issues that plague React projects.
> 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.
> 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.
I should have mentioned language/framework for JS. The thing with Elm is that it gives a straightforward way (even if verbose) to design the whole app around persistent data structures. That gives so many benefits especially long term (time-travelling debugging support, easy insights into app state, full coverage by unit tests etc.). On the other hand my experience with React is that the state hidden in all those functional hooks is hard to debug and reason about with completely unpredictable and non-intuitive behaviour. I think the switch from class components to hooks was a big mistake.
If all you're doing is generating static HTML sure, I'm sure your toy library templating system or whatever pure declarative functions Rich Hickey gave you permission to write works perfectly fine.
But I'm talking about interactive UIs which need state, as the environment its running in (the browser) is inherently stateful, and there are efficiency gains from doing so.
This isn't just an OOP thing, even in Elm & Purescript there are similar libraries for stateful UI. In you're doing anything like that in Closure or Clojurescript or whatever, I guarantee you its built on similar data structures and its foundation has many equilivant constructs.
It’s not that extraordinary. HN loads even faster. The React approach just isn’t fast. I recommend visiting multiple sites and using Chrome’s performance tab.
How you can make this argument then present the most unreadable memory hog mess of a language that’s really just functional sugar on top of Java as the example is hilarious. You must be trolling.
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.
It absolutely is and comes with all kinds of bullshit posturing from people simultaneously explaining how awesome they are while qualifying what they can’t do without their framework. It is the kind of lies I see from my autistic kiddo where they know they have fucked up and try to paint a rosy picture in 6 or more conflicting stories.
It’s really simple. You can write an original application in your own code or you just can’t. I don’t care about all the excuses, because it just isn’t that challenging. It’s not for everyone.
Lots of people can, but why should they if their clients are not paying for it? Even worse, if they switch developers, they now need to onboard them into bespoke solutions with little to no public documentation.
I would never hire you and people with that purist of a mindset.
In my last job I worked with someone who went on holy wars to troll people without evidence. I am not interested in working with anyone who seeks conventions over measures.
He was fired for a variety of things like withholding client communications, poor performance, absenteeism, lack of project awareness/status. It was pretty bad since he was in a leadership position as the Task Order Project Manager for a very high visibility project.
> 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.
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)
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.
> In the big corporate world, especially at non-software companies, there is a culture that strongly believes internally written software sucks.
But this is... true? Non-core software gets the shaft in resources / development, especially at non-software companies. And for most companies the underlying web architecture are not a core business. For Facebook, Amazon, Google it is, that is why they are often the ones making frameworks.
Fact is frontend development is very complicated and the platform doesn't provide enough support for large projects.
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.
And after you do it 2 or 3 times you extract the repetitive work into a framework. Not sure if you have never got to that phase but it is quite weird to see a programmer that does not like (or understand) abstractions.
I use functions for what you describe. I don't need a framework to accomplish reuse.
Also, the framework worship is always a bit bizarre to me because the front end of even the largest of single page applications is relatively tiny compared to the supporting back end. If a developer is writing the entire application then why invest so much effort into over engineering such a small slice of the total code? It isn't productive unless it is the maximal extent of a given developer's capabilities.
> I use functions for what you describe. I don't need a framework to accomplish reuse.
A framework is composed of many reusable functions. You are really confused, arguing for this nonstop on HN for years. Not sure what you get from this but as someone mentioned, just show us the code and what you call a complex system developed your way. Code talks.
I am not going to show you my code. You wouldn't understand it and then you would bitch and cry that its not your favorite framework. Agreed in advance, its not your favorite framework. It works differently.
If you operate purely from convention then what does it matter if I did show you my code? What do you hope to gain from looking at something you have already dismissed in advance?
I have to say that I too am curious to see your code given the confidence and assertiveness you express yourself with. The excuse about knowing the critique in advance comes across as quite a reach, not to mention "you wouldn't understand it"..!
I have had similar conversations with framework cultists in the past. Not showing the code is something I have had to learn from past experiences with repeated results. If people were authentically interested in seeing JavaScript applications not written with React there are plenty of examples out there.
We had this discussion in the past and at the time you were not ashamed to show this code of yours. I told you it is bad. It is really impressive that you talk so high of your programming skills on every JS thread tho. And it is not AI psychosis although it is very similar.
Let's make it simple. Is there any other code that is open source that it is as good as yours that you can point us to it?
You are not the only one. It is funny because initially I found his opinion slightly interesting as I dislike React and all frontend frameworks but my solution was to create my own. When you do more than 2 projects using the same base you have a framework. He can't realize that.
> All of his comments boil down to purist opinions
not even that, it is just an obsession and disconnection from reality. There are multiple benefits from not using frontend frameworks, React is really, really bad. He doesn't understand that the correct way tho he is right by pure coincidence.
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.
No, Next is a framework, React is a library. You could write React components in a web framework on a completely different stack if you wanted to, same with most JavaScript rendering libraries, which was my original issue with OPs comment, the bulk of JavaScript libraries noted in the article don't limit you at all.
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.
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.
Their biggest plus, which some HN commenters baffingly either don't get or ignore, is that another company and volunteers pay for maintenance. If you roll your own - and you will, if you're not using one for a larger app! - you're now paying for library code and your money making application, thereby making less in total per hour spent.
You're committing the very sin that the original article fingers as the problem with the webdev culture.
The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"—or, put more charitably, a hunch plus some inductive reasoning. It's not a tested hypothesis.
The crux of your argument* is essentially "a + b > a for some non-zero b", where b represents what you are "paying for your library code". The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method ("Just Do It") when it comes to dealing with things yourself (i.e. the framework cost—which, like b, is never zero).
* as stated at least; it's possible and probable that you really don't mean to say that c simply doesn't exist but that b > c (either by intuition or experience or both) but that's still just a claim—which is the entire basis for the author's criticism: not whether frameworks are or aren't actually more cost-effective, but the greater meta-level concern described here in this comment, in the original piece, and other comments by the author and people like Alex Russell elsewhere describing how resistant the culture is towards the notion of attempting to prove or falsify these kinds of claims (if you can even manage to get people to agree to formulate them in such a way that they can actually be subjected to the scientific method)
> The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"
Is it? Because in my experience, this is flat out wrong and it's very easy to verify, and it is a tested hypothesis.
> The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method
You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper. Why would that ever be true? React doesn't do DOM manipulation for funsies, if you foregoe a framework you'll be implementing reactivity, interactivity and performant code yourself. The browser is very barebones in that regard. The framework cost is always lower than rolling your own, and this isn't even the argument people are having. Non-Framework evangelists are arguing performance, never cost.
A framework doesn't come into existence out of thin air. If you choose one, you're working with a community of thousands of developers. I don't have to build my own reactive table, I can use TanStack table. I don't have to build my own playground, I can use stackblitz or storybook to showcase stuff to a client. I don't have to build my own cancellable asynchronous list, I can use a trusted library for that, too. My client doesn't care if I roll my own. They care about effect per hour spent.
> You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper.
No, I'm not. Nowhere in my comment have I made that claim, nor is there any claim that could even be mistaken for trying to argue one way or the other. It's like you lack the ability see words on a page and understand what's actually being discussed in the remarks you're responding to. (This also explains why, when challenged on succumbing to the industry tendency to make all-vibes arguments instead of evidence—directly in the comments of the article that calls this out—your direct response to that is to restate your claims and arguments and avoid providing any evidence. It's always just hunches and attempts at inductive reasoning, all the time.)
Claiming that one approach is cheaper than another is never a fallacy. It is a statement of fact that can be wrong if disqualified with evidence or proven correct.
> The framework cost is always lower than rolling your own, and this isn't even the argument people are having
First, not using a framework doesn’t mean you have to roll your own (otherwise you’re still using a framework?). Second, this is the claim the parent wants you to substantiate, that not using a framework is always more expensive than using one.
No, it is the painful experience of a decade of frontend software engineering and consulting, thank you very much. I‘m not talking about someones blog here, I‘m talking about commercial, complex applications.
If you plan to sell a digital product or SaaS on the internet and your use case is more complex than a blog or a portfolio site, your „vanilla js purity“ will outgrow the project, fast, and it will become a mess. I‘ve never not seen it end this way.
I've seen the situation where underqualified, overambitious programmers build an internal platform that becomes a monster. There isn't the time to mature it, there isn't a standard or docs to point to, it becomes a drain on the company, at worst someone's vanity project.
I've also seen the situation where a team absolutely refuses to build anything themselves out of anxiety, spending enormous amounts of money on an external solution that acts as a rent extractor.
The problem with buy-not-build, is if you do it for too long, you forget how to do the latter. This is great right up until you find a problem you can't buy your way out of.
Sometimes building something half good, is fast enough and educational enough to get you to the next step.
Exactly. When I realized my homegrown JS DOM management had grown into a version of Vue.js that I was the sole maintainer of, I switched to Vue.
There’s still value in building something from the ground up; you understand the framework that much better. But so long as your needs largely overlap with the community, the benefits of working with the community are real.
I've worked at a dozen clients where, like in every software project, tech debt accumulated. Suddenly, when the DOM manipulation code or reactivity had bugs, I had to think about both sides of the coin - was the bespoke homegrown framework causing a weird interaction, or was is the component I worked on? One can hate React/Vue/Svelte or their models, but you can place trust in their maturity if you choose correctly
I have been writing my own large applications in JavaScript/TypeScript for 18 years and watching other JavaScript developers not figure out and blame everything else for their inability to program. I have never needed a framework or tried to recreate one.
I do tire of the failure to perform and the endless empty excuses.
I find it very hard to believe you and blaming developers for using trusted library code to not re-solve problems, thereby earning a living, is a pretty harsh statement.
How are you convincing your clients that they should pay a senior to re-engineer solves problems?
That’s easy. When you can deliver a smaller product in less time you are saving the client money. Sometimes reinventing the wheel is as simple as copy/paste.
A single dev can churn out a basic React app in like a single workday pre-AI, the important parts are not at all hard to understand and you get reactivity out of the box which is a lifesaver later on as your app grows in complexity.
I'm not understanding why you have the idea that it's a huge drag on productivity and hand rolling the same patterns everyone ends up needing will somehow be more efficient.
A day is a very long time when the architecture is supposedly already well known.
Part of the foolishness here is that you are convinced your approach is faster but you have no idea what my approach is. You certainly aren’t measuring anything so even if you were aware of my approach you are still just randomly guessing at the result.
So you admit your workflow does not reflect in any way or form the needs and processes of even a small to medium org, let alone half a dozen teams or more? That's not a great point of few for someone with opinions that strong on purity.
So, my home grown architecture is stupendously simple enough that I could train another developer, depending upon the developer, on it in 30-60 minutes.
Your comment completely reaffirms my original comment way at the top in that these frameworks largely exists so that employers can avoid any kind of investment in their developers.
> So, my home grown architecture is stupendously simple enough that I could train another developer, depending upon the developer, on it in 30-60 minutes.
Then it is not complex enough to support the needs of large projects.
You admitted it yourself. You work with a small group of people in small projects, but you got huge opinions.
Building a bespoke framework, for nothing of value except because you want to, isn‘t investing in developers, it‘s creating a huge cost factor for no gain.
How can you say that if you don’t know what my approach is? My current project is moderately large at nearly 100 files of TS code of which some are thousands of lines. It does not employ any framework and does not create its own framework.
"I don't use frameworks, y'all can't program" - I mean, good for you, but I want to pay my bills and my clients sure aren't paying me to reinvent the wheel for the 20th time?
But you are claiming the opposite in your replies to me. You are telling me that I am taking the wrong approach without knowing what approach I am taking. How could that be the best tool for the job?
> You are telling me that I am taking the wrong approach without knowing what approach I am taking. How could that be the best tool for the job?
You wrote yourself that you roll your own and you insulted every developer who doesn't. The best tool for the job is the one that doesn't unecessarily strain your customers wallet for no extra gain.
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.
Its a matter of practice and measure. If you can build your own hammer in less time than it takes to drive to the store and back then building your own hammer makes complete sense. People irrationally fear not using frameworks for things not measured. If other people want to continue that irrationality, for whatever reason, then so be it.
> If you can build your own hammer in less time than it takes to drive to the store and back
You can't and your analogy doesn't hold. I've been writing JS frameworks work a decade, as have millions of other developers. They don't "drive to the store", they install their tool of choice in one second. You either build and maintain yours for hours or you copy paste code (which equates to the same).
> people irrationally fear not using frameworks for things not measured.
How would you know? You are choosing conventions over measures. If you measure nothing you have no idea what is faster or not. I have been doing this work for nearly 20 years and many JavaScript developers claim measuring things is easy, but they never do it. When pressed on it they never have and don't know how. Instead they guess at performance to reinforce their own preferences. I have an autistic kiddo that does this and everybody sees right through it.
> How would you know? You are choosing conventions over measures.
Because I worked in the industry when we all used jquery and I see the difference in real billable hours to nowadays. The entire industry has measured and shifted. Do you think million- and billion dollar companys shifted towards public shared framework for funsies and parties?
No. I don't have to hire an engineer and teach him our company bespoke framework. I can hire a react developer and he's productive from week one.
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.
> Why would you say that? What evidence leads to this conclusion?
Your own comments.
> Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do?
No. Not at all. I'm suggesting they're unwise if they do it voluntarily (as in: not constrained by compliance etc.).
> to me this sounds like you have absolutely no idea how to program
I'm not surprised. Surely you roll your own STD as well? Boy, I really hope you never import a function from any library. Otherwise you would be just like us, the stupid idiots who can't write original code. While we're at it, hopefully you don't build upon an operating system as well, since any reasonable dev would be rolling their own. In all seriousness: You and me both build solutions on millions of lines of other people's code. I'm really wondering why you're acting so high and mighty because you're using a couple hundred lines less.
> no faith that anybody can program original solutions
Original solutions can be created just fine with library code.
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.
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.
> another company and volunteers pay for maintenance
That is and has been a very good argument. One thing I do notice though is that, with the emergence of agentic automatic maintenance workflows, that same maintenance surface seems to start shrinking right now.
Maybe in some cases. In my experience maintenance often comes with exploratory work, the kind of where one needs to invest time, not to think about how your own side should work but in dissecting how a dependency or a target platform works in order to identify specific quirks that come and go with the passage of versions. I have seen significant acceleration in these kinds of workloads. This doesn't mean it makes maintenance free like some claim. It just makes it about 70% less of a burden
As a developer, React, Vue, Svelte, and the like absolutely do empower me to not have to deal with all the pain-in-the-ass bullshit of the jQuery and Gulp days.
IMO, the largest benefit of most JS frameworks is a great story for statee synchronization.
Imagine an e-commerce website that has a cart with some products. The site has a cart button showing the current total, a pop-up cart interface, as well as an assortment of 10 or 20 different components which let you add or remove products (E.G. the Christmas promotion page may be using a different, christmas-themed "Add to cart" button).
You need to keep all of these in sync. If you open the cart pop-up and remove the product you've just added on the Christmas promotion page, the button on that page must change color (and ARIA state / label) back to show that the product is not in the cart any more.
With traditional, imperative JS, you have ~20 places where this state is kept: The card array is the source of truth, the CSS classes, labels and aria properties of all these buttons must stay in sync with that array, but there's nothing that forces them to do so.
Sure, there are some software engineering patterns (I'm looking at event-driven design here in particular) which make this kind of bugs less likely, but they're still not really a guarantee of the code being correct by construction.
React and its ilk make it much, much harder to introduce that kind of bug, requiring you to basically go out of your way to do so.
Because AI agents love slop and "just one more edge case just to fix that one bug" thinking instead of addressing the underlying root cause of the bug class, this kind of thing is more important now than it ever was before. Agents are great only if you set them up for success, and the way to do that is to make bugs impossible to write.
Which of my opinions are purist? I have really only said I prefer to not use giant frameworks. Why should I use a factory when a hammer is more than sufficient?
People seem to have these conspiracy theories when in reality, frameworks do exist to make developers' (in aggregate at a company and in general) lives better. I'm not gonna write DOM manipulation code from scratch when React (or Solid, or Vue, or...) handles everything for me.
In my experience the large frameworks tend to make things easier for developers by bundling things into partially isolated components. They also tend to make the code much larger and more complex. For me working with the DOM is just a matter of assigning references to variables and making use of events (functions).
this comment is a non-programmers idea of a programmer's comment.
> For me working with the DOM is just a matter of assigning references to variables and making use of events (functions).
I loved this tech-coded business speak gibberish. "For me, managing business operations is just a matter of aligning strategic variables with organizational synergies and making use of scalable frameworks (processes)."
Can you write your own standard library, browser and operating system?
Let me put it this way: Chrome, the Linux Kernel and Ubuntu combined are about 600-700 million lines of code. React core has 70k (150kb). You‘re using 0.0017% less library and framework code than the rest of us.
There are also implementation differences due to using the framework, so the actual difference is really quite a bit larger than 70k LOC depending upon the given application. There are also all the plugins, build tools, and all their dependencies as well.
My personal preference is to ship less code because it means less to maintain over time, less tech debt.
> There are also implementation differences due to using the framework, so the actual difference is really quite a bit larger than 70k LOC depending upon the given application
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.
It helps if you've already got a decent codebase built in it with standard patterns covered.
Most of my sites start as a copy of an existing site as if it's a framework and then I clear out the product and just use the shell to build from. The result is that the agent is pretty good at replicating existing patterns and if I ever hit something similar I can just tell it to look up prior art in other projects.
The initial learning curve was definitely there, and I still hit edge cases as mentioned above. I just don't have to resolve the "how do I handle auth + middlewre + htmx targeting for a form in an admin screen (for a random example).
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).
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.
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”.
It doesn't apply to agents because people coming and going brought their own preferences, dislikes and ignorances. Also unspoken/unwritten rules and ideas for future structure. Agents follow the same AGENTS.md, know all the tricks other agents know, so I would expect them to code more uniformly.
I would encourage you to re-evaluate that expectation. A framework comes with strict, mechanical constraints for both developers and agents, while the contents of AGENTS.md can be ignored by agents. Even skills don't always get invoked, and you sometimes have to browbeat your agent to follow a skill or doc. But a framework provides a hard, mechanical guardrail with loud failures and known solutions. Combined with linting, strict types, and a language server, your LLM isn't going to be tempted to invent baffling solutions when a framework provides patterns for long-solved domains.
I would go so far as to argue that all of the reasons that frameworks are useful for human-led projects are equally, if not more applicable to those executed by agents.
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
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?
AFAIK, search is really a place for Algolia to show off its API based search services to the HN audience, not really just built to be a simple static page search result to match the HN architecture.
> 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.
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.
It's a mixed bag. The company I work for (nearly $6 billion anual revenue, southern EU) only started giving out the lowest tier of Github Copilot licenses this summer, and only widely at the business units they're desperate to see grow (I got lucky there due to wearing multiple hats). Everyone else keeps coding manually, although the nerdiest of us catch up with Codex/Claude/whatever on our own time, same as it ever was.
Meanwhile, a friend at a consulting company of similar scale tells me they don't hire anyone who shows a lack of experience with "agentic engineering" during the interview. They're turning all their projects into software factories from issue ticket to deployment. He's much more resourceful and experienced than me so I trust he isn't automating himself out of his own job, but I'm much more gloomy about this transition.
I agree in principle, but I don't feel in a position to bargain: I'm a junior dev earning below my region's average salary (for all industries, not just tech), far below other engineers my age because reasons, and my education is now becoming obsolete for industry. I'll let others take the high ground, I just want to stay employable and not lock myself out of a decent salary.
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.
$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 :)
This just scratches the surface of the cost-benefit analysis of JS frameworks. Frameworks were built mostly to simplify state mangement as we moved to complex apps from web forms, as they simplify partial loading/state updates.
The formula has changed significantly with LLMs. Managing state is still an architectural concern but not necessarily a human concern, as LLMs can sort out how to make things work. Which framework/approach is best is now an intersection of use case, performance/scale and LLM capabilities.
React wins by default for now because it has so much prior art in models and because devs know how to read and architect with it. In the future we may be generating WebAssembly code for performance with some bespoke state management that is fully rewritten after each change - what matters in the future wil not be legibility but accuracy, malleability and performance.
I’ve been really impressed with the current frontier models’ capabilities to build native macOS/iOS apps. I’ve had Claude build native apps which I would have built as web apps not long ago.
Also, when I first started out building with AI I made sure it would use frameworks and programming languages I know. Now I don’t care at all and let it choose the best technology. I don’t read a single line of code it generates and only work in the harnesses, never in an editor anymore.
I’m only building apps for myself and I’m not a professional developer.
> 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.
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.
Weirdly, this underscores my personal non-AI experience of Nuxt, which is that it is almost easier than you'd like it to be.
I'd prefer not to have used Nuxt for front-ends that don't need it, because it's chunky and a greater migration burden, but once a couple of patterns are in place, it's actually rather fun to use. A bit too much fun.
Also it's modestly large up front, which is the downside.
I suspect what is going on here, the same as with Laravel — which LLMs seem to really enjoy writing — is that the documentation is good, clear and ironically human-focussed, more oriented towards understandable recipes and reference, and the middleware setup is not absolutely arcane; at a glance of a Nuxt page's code you can kind of see mostly what it is going to do.
It's astonishing to me that even after a decade of SPA frameworks, most authors don't understand how a browser engine like Chrome works. There's enormous cost of manipulating the DOM from JS, as HTML elements get bound to JS objects lazily.
An actual high performance framework should manipulate HTML as a string directly, or through HTML templates (another feature that has existed in most browsers for a decade).
If you're not building a complex application on top of the web stack (interestingly these increasingly use WASM and their own GUI frameworks, so another moot point), but building an interactive consumption website (scrollable lists of static contents), I'd say instead of fronted frameworks, what most people actually would need is Chrome's experimental declarative partial updates:
String manipulation for HTML is a great way to introduce security vulnerabilities.
WASM is a non-starter for most web applications due to initial binary download.
Advising to use some experimental feature in one browser does not seem like a great idea.
JavaScript frameworks are not perfect but they exist for good reasons. People that brush them away usually lack the experience and understanding on the topic.
I don't disagree or really have a dog in the fight for three out of your four points, but it's unfortunate that WASM gets such a bad rap. The blobs are large because popular compilers force the semantics of popular languages into the Turing tar pit. WASM binaries are pretty compact by design:
const binary = Uint8Array.fromBase64(
"AGFzbQEAAAABBgFgAX8BfwMCAQAHBgECeDIAAAoJAQcAIABBAmwL"
);
const module = new WebAssembly.Module(binary);
const instance = new WebAssembly.Instance(module, {});
console.log(instance.exports.x2(3));
This is a trivial and useless example at 39 bytes, but a real example could be more compact than comparable minified JavaScript.
actually minified js is super compact. representing things as string immediately gives you the advantage of basic variable length encoding, whereas most binary formats will give you 32 to 64 bit integers with weird paddings for most structure fields. Afaik WASM also uses SSA forms which are super big compared to more compact representations such as RPN
Everything you said about WASM is false. It uses a variable length encoding for integers (LEB128). It presents as a stack machine (RPN) not SSA. It doesn't expose or impose padding in structs.
It seems like you're extrapolating from things you know to something you don't know at all, and you're spreading misinformation. WASM was designed to be compact.
Sorry I am not an expert on WASM, I just listed thing that are generally true of binary formats, and my main point was that text formats like minified js are pretty good when it comes to size - im sure a tiny js module would beat your wasm example.
The thing is to get these optimizations, like variable length encoding and tightly packed structs, engineers had to work hard, while a dumb text format gives it for free.
Additionally, they gave up the biggest advantage of binary formats - that they can be mmap-ed directly and read from code.
We'd have to get pretty specific to have a real bake-off on size, and that's probably more effort than either of us wants to spend for a HN thread that's basically dead. I could invent scenarios where either of JS or WASM has the advantage.
Code-golfing that particular example though, the JS could be "const x2=a=>2*a;" (15 bytes). If you ignore the one-time (insignificant) costs for the WASM headers and sections, the comparable byte code for that export is about the same number of bytes. If JS wins, it doesn't win by a lot.
Maybe I misunderstand, but I'm not sure I see the point about hard working engineers or memory mapping. I'm sure the JavaScript JIT engineers had to work really hard to get good performance. Among many other things, JS Objects using "shapes" or "hidden classes" was a pretty clever way to compensate for not having structs at all. For both JS and WASM, end developers don't need to worry about it, and you can't mmap JS to execute the code either.
> Maybe I misunderstand, but I'm not sure I see the point about hard working engineers or memory mapping
I was just saying, in my experience, binary formats tend to be easier to parse than text, relying on machine native constructs such as binary integers, sometimes even matching up their stored formats to C struct layouts (this is the case with, Linux's inode format for example).
Whereas complex textual formats such as JSON or Javascript usually have a tokenization and parsing pass. But they are mostly human readable in exchange, which is a ton more engineering effort to build and CPU time to run.
I was just trying trying to say, that once you really get into sophisticated binary formats, you have to take on similar levels of complexity to parsing something like a programming language, meaning that the parser is not simple, or fast, but the file is not human readable either. Which is kinda the worst of both worlds, and doesn't really drastically reduce file size.
TLDR: Text-based formats are fine, expecially for complex data, and are surprisingly competitive with hand-tuned binary formats.
Ahh, I see. That's why you were talking about structs and mmap. Thank you for the clarification.
I've written a lot of text parsers for pet programming languages and other things, and several binary parsers for work related stuff. I agree that bad binary formats are really awful. I don't remember the details now, but I gave up on trying to deal with Matlab data files.
WASM made it pretty easy to parse though. Kind of like TIFF or WAV files, the section type and length is right there when you need it even if you're streaming, and it's easy to skip sections you don't know or care about. There's a little bit of error-prone grossness having both unsigned and signed LEB128 inside of some sections though.
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.
Frontend has exploded in complexity. Separating concerns whereby the frontend does not care about the backend leads to better quality.
Just rendering a simple e-mail client on page 5 of a search result is simple enough to understand that streaming html for that state would require rocket science of string manipulation.
Besides that, you still did not answer how is updating the entire innerHTML for small changes better than just updating affected nodes?
I don't think you're understanding or reading what I linked to. The entire innerHTML of the page is not getting updated. If it was a page showing emails and there were next/prev buttons, next could trigger just the div (or area of the page that shows the list of emails) to reload with the server determined next 25 emails in an HTML snippet. The navigation areas don't change at all on the page, the page and browser don't go through a full refresh at all. There isn't a payload of JSON objects to parse and store in memory, nor a set of APIs to build on the server that output JSON.
Frontends have not exploded in complexity, they are still manipulating a DOM like they have been for 25 years. Complexity was writing different JS implementations for different browsers like Netscape Navigator 4 and Internet Explorer 4. I think a lot of frontend complexity is simply because of JS framework proliferation and a stance that the entire application should be JS in the browser, a full MVC framework when the backend is likely a full MVC framework already and has to validate all the inbound data changes.
What we're arguing about is mostly preference at this point. Please check out what different server frameworks do, there are server side JS frameworks too. If you're building simple web sites (like a pizza restaurant) vs. building a web application (like an app that processes millions of financial transactions per day) then the approach is going to be different and there are trade-offs to be made when picking a tech stack.
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.
AI cost of using anything is a good yard stick to measure things by. Red flags are a high degree of verbosity in tool outputs, complex failure modes, and slow running tools. Basically all that results in AIs having to look and dig through more output (tokens) and spend a lot of time polling tools for readiness (more tokens). The more complex a build for something is, the worse it gets. Especially if you also include things like running tests, linters, and all the rest. It adds up quickly when AI reasoning is causing a lot of trial and error to happen. It will eventually figure it out. But it might not be cheap.
Cost of iteration in time and tokens is really important if you like moving quickly without having to boil the oceans for simple changes. That was always true but AI kind of magnifies it because it's doing a lot of heavy lifting. Most of the time you wait for AI tools, you are actually waiting for tool calls to happen.
At this point just optimizing for all that could save you a lot of time and tokens. Which is really nice for your wallet and maintaining some flow state. I've stopped obsessing about my own biases in tools, frameworks, and programming languages. That made a lot of sense when I was the primary user of that stuff. But I'm not anymore. I might glance at the code to see if it's roughly doing what I expect. But there's too much of it for a detailed reviews and nit picking on my side. If I feel strongly about something, I'll ask for a change. But if it works, I'm often leaning to going with the choices the tool makes for me.
This is a bit of a leap of faith and a lot of people are not ready to make it. But I've found I can be productive with stuff I've never even used before now and that the cost of switching to whatever is fairly low. It does help to have good tools and tests to keep quality levels acceptable. The difference between vibe coding and responsible engineering is basically what you ask for and check for on that front. Having lots of experience doing things the old way definitely helps. But you should not constrain yourself to just stuff you know when solving new problems.
> If I feel strongly about something, I'll ask for a change.
Why not make the change yourself instead of burning more tokens and hoping the change as requested is actually made? Harnesses and models that make human code level collaboration difficult are not useful IMO.
It's akin to using a calculator where you can't access the numeric keypad.
I've found myself reaching for HTMX or Hotwire/TurboStream lately and it had nothing to do with vibe coding.
I find that HTML first web frameworks make way more sense, works out the gate, allows for caching of key parts easily and forces me to think in simpler terms when it comes to implementations. The end result is usually an easier to use app for my end users. The amount of complexity you can add to a UI should be limited but a lot of folks just go crazy with SPA.
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.
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.
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.
The vanilla advantage is also there in a pure client-side pwa. Arguably it’s even bigger, because the bundle size ends up way smaller and the agent needs to hold less in context.
Plus all the other vanilla advantages: fewer dependencies, lower maintenance, less retraining, etc…
I'm reading that agents can now mash up video games that were written in assembly. At that point I have to wonder if the abstractions are adding anything.
Of course, there is the question of "the human can still understand what is going on", but it's not clear the new frameworks are optimizing for that...
I mean maybe I'm too grumpy, but never in my life did I think I'd have to fight against a strong contingent of people who really don't see the value of abstraction. Taking crazy pills must feel like this.
They also were unnecessary even before AI, the biggest advantage of React over HTMX-style apps was that you could recruit someone more easily but the SPA complexity wasn't worth it and it scaled terribly.
Now that you don't write the code, I don't see why I would pick React style libraries unless the codebase is already there.
We just write different stuff. For content driven websites you can skip js frameworks altogether. For web apps it would not be a good idea.
It's all about how much interactivity you need. A lot of business web apps are full featured commercial software packed in SPA form. You will need a lot of stuff client side and without framework it will be a mess. Unless you write framework yourself but the you are reinventing a wheel.
In typical HN style, you are both pretentious and wrong. Javascript frameworks save you the complexity of an agent holding the entire library code in their context. For example, an agent can work with 2-4 react components for a current ticket without needing to know each line of internal React code.
This is what I was thinking while doing some work on my projects. I've been a full stack focused developer way before the AI age and at that time DX was something that was a priority for me.
But now, its just about AX (Agent experience lol) how easy can you make it for the agentic system/model to achieve better outcomes. Its as easy as letting the agent choose it's way of doing things - let it choose its own project framework be it Astro, using bun, using handlebars even.
Nowadays people have shifted from writing code anyways - claude code or codex or any agent can do it, all we do is plan and review.
> Its as easy as letting the agent choose it's way of doing things - let it choose its own project framework be it Astro, using bun, using handlebars even.
I would be very surprised if the tool that agents use most effectively is also the one they recommend. There's no clear reason why they'd be the same, until articles like this, neither they nor we know which is most efficient. They're recommending based on their model of normal best practice and patterns (what does everybody else do for a project like this) not "I have analyzed handlebar syntax and I think I will iterate more quickly with this".
I feel validated. Have turned to Astro or HTMX for years. They just made sense. That being said, I vibe coded a complex local-first SPA in Astro last year and the agent struggled with caching and service worker code. It literally wrote an entirely duplicated and separate SPA for “offline mode”
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.
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!
A significant part of the cost is that newer framework APIs are not known to the current agents. So they need to discover them and learn them on the fly. Eventually future models will have them trained into their weights and efficiency should increase. In the grand scheme of things, the cost might be negligible if it makes up for it in performance or quality.
I've built large FE systems with millions of lines of code pushing tens of billions of dolllars in revenue (I was lead FE dev on that one).
The idea that failing to do a small project (that should be clearly represented in the training data) means failing even harder at bigger projects doesn't suddenly gain merit because I have a lot of experience and have worked on big projects.
When I was running a small dev agency with a sprinkling of web projects, Angular was useful because it every project looked more or less the same. The rigidity (and verbosity) it imposed was an advantage in this setting, as it helped with the cognitive load when switching between projects. Apart from that, I wasn’t a fan either.
Angular is an absolute joy to work with as a framework, improving year after years, not scared of shifting heavily when a new favorable paradigm comes in. You never had data to prove that angular sucks because all the benchmarks don't say so.
Solid work, but it would be really cool if we can also test Pokemon motions and how the game responds in real-time. Is an agent able to think about reactions, directional movements and attack patterns of each Pokemon is where the real intelligence test lies.
Traditional languages may have their limitations, but [C++, Rust, JavaScript, TypeScript etc] can still do pretty well.
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.
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
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.
Interesting... Training data is really the same as experience in human developers. I favour frameworks I have experience in, the thing is most AI models have similar weights of "experience" and hence certain frameworks are accelerating in popularity.
I 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 genuinely been curious about this as well, recently instead of prescribing next, since its the framework i was most comfy w, i let the agent decide a stack
it chose plain solid wo a frameworks since i wanted the backend in rust anyway.
the rationale was streaming ai responses is better in it, since react re-diffs the dom every time a token is streamed, while solid just updates the exact node text changed.
tbh nowadays ive stopped caring about frameworks. wtver is comfier for the agent to write in, with enough back pressure from tests, ci and lifting so that agent fuckups dont reach me is good enough for me
This 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.
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!
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 should first note two caveats about my benchmark:
> The Pokémon app is small and doesn’t represent a large, complex real-world application.
That's a pretty big self-inflicted caveat. How do you know the results will translate to complex-real world applications?
Why not try adding a bunch of complex features to the app (Auth, battles, marketplace, social interactions, etc.) to see how an actual production frontend would hold up?
> But in the agentic era, when developers are no longer typing code by hand and are thus less constrained by DX, I still see vibes ruling the day (and not just in the sense of “vibe-coding”). Frontends are rewritten because some framework or another is “better for agents.” (Did anyone think to ask the agents?) The resulting code is “faster,” the agents make “fewer mistakes,” etc. Once again, these claims are often made without evidence. Whenever I read one of these accounts, I think to myself, “Where are the benchmarks?”
Again the law is laid down. Developers no longer X. They Y.
Feign dismissal over vibes all you want. Same old inevitability posting.
Enlightenment will be achieved when agents set up the benchmarks for what JS frameworks are good for agents. Other agents will interpret the results. Modern, peer-reviewed science.
Anecdotally, sveltekit 2 was super quick to use for me. I tried building a somewhat interactive app with htmx and found the user experience was often incorrect on the Claude 4 family models. I switched to sveltekit 2 and it produced what wanted almost immediately. Features were added instantly. Even today with React and Opus 5.5 it couldn't match the development performance of version 2.
That said, both are "fast enough" and if you're on an enterprise plan, the cost difference is neglible. I waste way more more tokens due to poor or imprecise requirements than I do on development.
If you are working on a typical web app, you either use a canned framework or write your own. Models are trained on existing frameworks, so they don't have to hold it all in their context to reason about it; it's baked into the weights. Same goes for the humans reviewing the code. I don't see the benefit of writing your own framework for most companies.
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).
React Native has always been so so terrible, I was convinced anyone who advocated for it had no taste or care for UX
I have the same feelings about React, so much so that I've never given it a second chance. Vue handles my use cases when it does, and when it doesn't it hasn't been because I needed _more_ in any way that React offers.
In my experience:
Flutter good, React Native bad. (mobile)
In the time of LLM, Dart with its hermetically sealed environment and amazing tooling may be at a real advantage.
> 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
This has largely been my experience navigating the JS framework world from basically the beginning of React. It's wild how poorly some of the earliest presentations about React have aged, as that framework has gone through endless major API/design refactors.
Not to mention that benchmarks are a very flawed way to assess technology for builds with complex and open-ended requirements. If you're operating in a constrained environment and you have a clear bottleneck that a particular tool can solve, then benchmarks can be really helpful. But starting on a new product from 0 that needs flexibility to pivot does not necessarily benefit from picking the fastest tool in the shed.
[dead]
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.
> the cleanest of the micro spa frameworks I've seen
Ah, you're the author of it? :P Cherry on top
I did this recently with a dependency that has stalled out. For the past 3-4 years, the ngx-infinite-scroller has been in maintenance mode of just updating the Angular version. Then the maintainer (which is a fork of a fork of the original) disappeared.
I forked, put AI on it to not only fix the issue I was facing with the new Angular (zoneless) but add full testing to it and make it resilient. Massive benefit to my apps and trust.
https://github.com/Kareadita/ngx-virtual-scroller for anyone that's interested.
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 is beautiful. I believe people consider it complete mostly, that's why there have not been updates. I have been doing the same and adding a bunch of features on top. Will check yours. Let's make super-mithril !
Yes, Mithril enhanced with signals feels very efficient und saves tokens.
Which library do you use to get signals?
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?
agreed but i would definitely take this kind of methodical, systematic work over shallow, superficial pelican stuff
I guess the conclusion is Angular was the worst choice pre AI and continues to be post AI
I like angular quite a bit idk why it gets so much hate
It may be partly due to how awful Angular v1 was. I know it put a bad taste in my mouth when I had to use it. But we stuck with it and things got way better with v2+.
I used v1 and ofcourse it scarred me but even v2+ versions felt like they encouraged over engineering compared to alternatives which I had a easier time wrapping my head around
[dead]
Kinda interesting, but disjoint from all the real underlying reasons why React and other frameworks are so sticky.
After a decade of React, I'm not going to go go learn htmx or any other marginally better same-shaped tool for a new project, especially when it'd degrade my ability to review and debug another actor's work product. The cost of switching frameworks is now dramatically higher and the payoffs way lower.
Fundamentally, framework perf is about not incurring too heavy a cost for the abstractions, and then to improve dev efficiency. This matters most in the "explore"/prototype phase, when poor perf would be a good problem to have to care about.
In my projects, the real question has kinda moved down to "should I yeet 1/2 the app to wasm yet?" and similar higher-order questions.
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.
I haven't found that. I use Astro + SolidJS and it seems to work very well.
I intentionally avoid hydration (which I've always found to be flaky) and hydration-based frameworks like SolidStart, so possibly that helps. Or maybe that's just my own bias!
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.
> I know what I'm using for my next project.
Django?
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.
next project? pun of the year?
> For “Vanilla,” note that the agent was told to use “vanilla JavaScript or TypeScript with Vite, without a UI framework.” Surprisingly, this underperforms several frameworks, which seems to demonstrate that having some framework can be better than nothing
I'd be curious how it does if you allow it some helpers or "micro frameworks" that are WAY short of a normal framework. Say vanilla js paired with nanostores as an example.
Or if you just ask it to perform better than the frameworks, probably it could do it then.
[flagged]
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.
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.
Either one can show a user stale data. Both need backend checks on user actions to make sure the user's view is current.
In my SPAs, server calls and the state copies they return to the client are numbered sequentially from the start of each session. A server response with a number earlier than the last client call is ignored. That mostly takes care of race conditions that arise from latency. Fundamentally this is similar to SSR in that the client will not update until the server sends new data... there is no client-side modification of the client data copy, ever, so it can never diverge from the last known server state. That would of course be a disaster. The difference is that the page can change progressively without reload, and the state is available between "pages" without more calls to the server.
> In most SPA, state is distributed with two copies floating around.
In all client-server systems, state is distributed with "two copies floating around". The difference between SSR and REST+SPA is that in the SSR, your server code is creating the markup to make it presentable to an end-user, but it's still fundamentally a copy of the state that exists on the server, and it's not obvious why the transformation to markup rather than structured data (like JSON) is desirable on the server. If anything, with SSR you need to copy more state from the client to the server, where it doesn't really belong.
>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.
> 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.
> 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.
You clearly did not understand the comment or watch the linked talk. You saw only what you wanted to see.
I just saw that I wasted time debating a person that named an anti-framework law after themselves in their HN profile. So nevermind.
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.
I should have mentioned language/framework for JS. The thing with Elm is that it gives a straightforward way (even if verbose) to design the whole app around persistent data structures. That gives so many benefits especially long term (time-travelling debugging support, easy insights into app state, full coverage by unit tests etc.). On the other hand my experience with React is that the state hidden in all those functional hooks is hard to debug and reason about with completely unpredictable and non-intuitive behaviour. I think the switch from class components to hooks was a big mistake.
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.
It’s not that extraordinary. HN loads even faster. The React approach just isn’t fast. I recommend visiting multiple sites and using Chrome’s performance tab.
HN is not a complicated website. At all.
> The React approach just isn’t fast.
React is pretty damn fast and it's not even the fastest framework out there.
How you can make this argument then present the most unreadable memory hog mess of a language that’s really just functional sugar on top of Java as the example is hilarious. You must be trolling.
Clojure supports multiple run time environments including JVM, V8, and .NET. It is not syntactic sugar on Java and I did not use it as an example.
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.
>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.
In my last job I worked with someone who went on holy wars to troll people without evidence. I am not interested in working with anyone who seeks conventions over measures.
> I am not interested in working with anyone who seeks conventions over measures.
This is exactly what you're doing. You're seeking the convention of building your own over the measure of valueable developer time
Is the "troll" still working there?
He was fired for a variety of things like withholding client communications, poor performance, absenteeism, lack of project awareness/status. It was pretty bad since he was in a leadership position as the Task Order Project Manager for a very high visibility project.
> 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.
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)
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.
> In the big corporate world, especially at non-software companies, there is a culture that strongly believes internally written software sucks.
But this is... true? Non-core software gets the shaft in resources / development, especially at non-software companies. And for most companies the underlying web architecture are not a core business. For Facebook, Amazon, Google it is, that is why they are often the ones making frameworks.
Fact is frontend development is very complicated and the platform doesn't provide enough support for large projects.
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.
And after you do it 2 or 3 times you extract the repetitive work into a framework. Not sure if you have never got to that phase but it is quite weird to see a programmer that does not like (or understand) abstractions.
I use functions for what you describe. I don't need a framework to accomplish reuse.
Also, the framework worship is always a bit bizarre to me because the front end of even the largest of single page applications is relatively tiny compared to the supporting back end. If a developer is writing the entire application then why invest so much effort into over engineering such a small slice of the total code? It isn't productive unless it is the maximal extent of a given developer's capabilities.
> I use functions for what you describe. I don't need a framework to accomplish reuse.
A framework is composed of many reusable functions. You are really confused, arguing for this nonstop on HN for years. Not sure what you get from this but as someone mentioned, just show us the code and what you call a complex system developed your way. Code talks.
I am not going to show you my code. You wouldn't understand it and then you would bitch and cry that its not your favorite framework. Agreed in advance, its not your favorite framework. It works differently.
If you operate purely from convention then what does it matter if I did show you my code? What do you hope to gain from looking at something you have already dismissed in advance?
I have to say that I too am curious to see your code given the confidence and assertiveness you express yourself with. The excuse about knowing the critique in advance comes across as quite a reach, not to mention "you wouldn't understand it"..!
Here is the code if anybody is curious:
https://github.com/prettydiff/share-file-systems
Just a poorly specified framework built on endless amounts of appendChild, createElement, etc.
I have had similar conversations with framework cultists in the past. Not showing the code is something I have had to learn from past experiences with repeated results. If people were authentically interested in seeing JavaScript applications not written with React there are plenty of examples out there.
>Not showing the code is something I have had to learn from past experiences with repeated results.
lol sure!
We had this discussion in the past and at the time you were not ashamed to show this code of yours. I told you it is bad. It is really impressive that you talk so high of your programming skills on every JS thread tho. And it is not AI psychosis although it is very similar.
Let's make it simple. Is there any other code that is open source that it is as good as yours that you can point us to it?
He won't. At this point I'm not sure if the user in question is mentally unwell or maybe even a robot. I've made the same observations as well.
You are not the only one. It is funny because initially I found his opinion slightly interesting as I dislike React and all frontend frameworks but my solution was to create my own. When you do more than 2 projects using the same base you have a framework. He can't realize that.
Austin is most likely not a developer, none of his comments make any sense. All of his comments boil down to purist opinions and contradictions.
> All of his comments boil down to purist opinions
not even that, it is just an obsession and disconnection from reality. There are multiple benefits from not using frontend frameworks, React is really, really bad. He doesn't understand that the correct way tho he is right by pure coincidence.
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.
No, react is a framework composed by countless react-* packages.
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.
No, Next is a framework, React is a library. You could write React components in a web framework on a completely different stack if you wanted to, same with most JavaScript rendering libraries, which was my original issue with OPs comment, the bulk of JavaScript libraries noted in the article don't limit you at all.
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.
Yes, this closely aligns to the Law of Leaky Abstractions.
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
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.
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.
You're committing the very sin that the original article fingers as the problem with the webdev culture.
The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"—or, put more charitably, a hunch plus some inductive reasoning. It's not a tested hypothesis.
The crux of your argument* is essentially "a + b > a for some non-zero b", where b represents what you are "paying for your library code". The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method ("Just Do It") when it comes to dealing with things yourself (i.e. the framework cost—which, like b, is never zero).
* as stated at least; it's possible and probable that you really don't mean to say that c simply doesn't exist but that b > c (either by intuition or experience or both) but that's still just a claim—which is the entire basis for the author's criticism: not whether frameworks are or aren't actually more cost-effective, but the greater meta-level concern described here in this comment, in the original piece, and other comments by the author and people like Alex Russell elsewhere describing how resistant the culture is towards the notion of attempting to prove or falsify these kinds of claims (if you can even manage to get people to agree to formulate them in such a way that they can actually be subjected to the scientific method)
> The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"
Is it? Because in my experience, this is flat out wrong and it's very easy to verify, and it is a tested hypothesis.
> The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method
You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper. Why would that ever be true? React doesn't do DOM manipulation for funsies, if you foregoe a framework you'll be implementing reactivity, interactivity and performant code yourself. The browser is very barebones in that regard. The framework cost is always lower than rolling your own, and this isn't even the argument people are having. Non-Framework evangelists are arguing performance, never cost.
A framework doesn't come into existence out of thin air. If you choose one, you're working with a community of thousands of developers. I don't have to build my own reactive table, I can use TanStack table. I don't have to build my own playground, I can use stackblitz or storybook to showcase stuff to a client. I don't have to build my own cancellable asynchronous list, I can use a trusted library for that, too. My client doesn't care if I roll my own. They care about effect per hour spent.
> You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper.
No, I'm not. Nowhere in my comment have I made that claim, nor is there any claim that could even be mistaken for trying to argue one way or the other. It's like you lack the ability see words on a page and understand what's actually being discussed in the remarks you're responding to. (This also explains why, when challenged on succumbing to the industry tendency to make all-vibes arguments instead of evidence—directly in the comments of the article that calls this out—your direct response to that is to restate your claims and arguments and avoid providing any evidence. It's always just hunches and attempts at inductive reasoning, all the time.)
Claiming that one approach is cheaper than another is never a fallacy. It is a statement of fact that can be wrong if disqualified with evidence or proven correct.
> 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,
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.
He's either trolling or he is genuinely dense. I'm leaning towards the latter at this point.
He may also be unwell. He‘s in every single thread that mentions frameworks.
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?
The code you reuse every time you build a website. Are you done playing coy? Or, do you really not understand what I'm saying?
I don‘t think he does. I had the same problem. Either he‘s willingly obtuse or the matter is beyond him.
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.
How can you say that if you don’t know what my approach is? My current project is moderately large at nearly 100 files of TS code of which some are thousands of lines. It does not employ any framework and does not create its own framework.
Well personally I would not gloat about my genius non-framework code if it had files with "thousands of lines".
Its not a brag. Its just not small and its not a framework. How else would you make that point?
100 files of TS code is not moderately large.
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.
But you are claiming the opposite in your replies to me. You are telling me that I am taking the wrong approach without knowing what approach I am taking. How could that be the best tool for the job?
> You are telling me that I am taking the wrong approach without knowing what approach I am taking. How could that be the best tool for the job?
You wrote yourself that you roll your own and you insulted every developer who doesn't. The best tool for the job is the one that doesn't unecessarily strain your customers wallet for no extra gain.
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.
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.
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.
Its a matter of practice and measure. If you can build your own hammer in less time than it takes to drive to the store and back then building your own hammer makes complete sense. People irrationally fear not using frameworks for things not measured. If other people want to continue that irrationality, for whatever reason, then so be it.
> Its a matter of practice and measure.
It really isn't.
> If you can build your own hammer in less time than it takes to drive to the store and back
You can't and your analogy doesn't hold. I've been writing JS frameworks work a decade, as have millions of other developers. They don't "drive to the store", they install their tool of choice in one second. You either build and maintain yours for hours or you copy paste code (which equates to the same).
> people irrationally fear not using frameworks for things not measured.
It is very easy to measure the hours spent.
> You can't
How would you know? You are choosing conventions over measures. If you measure nothing you have no idea what is faster or not. I have been doing this work for nearly 20 years and many JavaScript developers claim measuring things is easy, but they never do it. When pressed on it they never have and don't know how. Instead they guess at performance to reinforce their own preferences. I have an autistic kiddo that does this and everybody sees right through it.
> How would you know? You are choosing conventions over measures.
Because I worked in the industry when we all used jquery and I see the difference in real billable hours to nowadays. The entire industry has measured and shifted. Do you think million- and billion dollar companys shifted towards public shared framework for funsies and parties?
No. I don't have to hire an engineer and teach him our company bespoke framework. I can hire a react developer and he's productive from week one.
This is exactly what I posted in my top comment.
> If you roll your own - and you will
That's the best case. Usually it was just thousands of lines of jquery spaghetti.
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.
> Why would you say that? What evidence leads to this conclusion?
Your own comments.
> Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do?
No. Not at all. I'm suggesting they're unwise if they do it voluntarily (as in: not constrained by compliance etc.).
> to me this sounds like you have absolutely no idea how to program
I'm not surprised. Surely you roll your own STD as well? Boy, I really hope you never import a function from any library. Otherwise you would be just like us, the stupid idiots who can't write original code. While we're at it, hopefully you don't build upon an operating system as well, since any reasonable dev would be rolling their own. In all seriousness: You and me both build solutions on millions of lines of other people's code. I'm really wondering why you're acting so high and mighty because you're using a couple hundred lines less.
> no faith that anybody can program original solutions
Original solutions can be created just fine with library code.
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.
You called people idiots and accused them of having no ability to write software. That is a personal attack.
> 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.
People don't respond well to "everybody doing X is an idiot without skills". Who knew?
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.
Tedious and replying to the wrong post?
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.
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?
Which of my opinions are purist? I have really only said I prefer to not use giant frameworks. Why should I use a factory when a hammer is more than sufficient?
No, you‘re implying that anyone who will use one is useless as a developer
So its not about purity, but about you being sad? Why are you so invested in my personal opinion about developer capabilities?
> Why are you so invested in my personal opinion about developer capabilities?
Because I don't like people spewing vitrol on hn?
People seem to have these conspiracy theories when in reality, frameworks do exist to make developers' (in aggregate at a company and in general) lives better. I'm not gonna write DOM manipulation code from scratch when React (or Solid, or Vue, or...) handles everything for me.
In my experience the large frameworks tend to make things easier for developers by bundling things into partially isolated components. They also tend to make the code much larger and more complex. For me working with the DOM is just a matter of assigning references to variables and making use of events (functions).
this comment is a non-programmers idea of a programmer's comment.
> For me working with the DOM is just a matter of assigning references to variables and making use of events (functions).
I loved this tech-coded business speak gibberish. "For me, managing business operations is just a matter of aligning strategic variables with organizational synergies and making use of scalable frameworks (processes)."
It's ok to say you can't do it. I wouldn't think less of you for your honesty.
Can you write your own standard library, browser and operating system?
Let me put it this way: Chrome, the Linux Kernel and Ubuntu combined are about 600-700 million lines of code. React core has 70k (150kb). You‘re using 0.0017% less library and framework code than the rest of us.
There are also implementation differences due to using the framework, so the actual difference is really quite a bit larger than 70k LOC depending upon the given application. There are also all the plugins, build tools, and all their dependencies as well.
My personal preference is to ship less code because it means less to maintain over time, less tech debt.
> There are also implementation differences due to using the framework, so the actual difference is really quite a bit larger than 70k LOC depending upon the given application
Not really.
Meanwhile, LLMs have massively buffed internally developed software.
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.
It helps if you've already got a decent codebase built in it with standard patterns covered.
Most of my sites start as a copy of an existing site as if it's a framework and then I clear out the product and just use the shell to build from. The result is that the agent is pretty good at replicating existing patterns and if I ever hit something similar I can just tell it to look up prior art in other projects.
The initial learning curve was definitely there, and I still hit edge cases as mentioned above. I just don't have to resolve the "how do I handle auth + middlewre + htmx targeting for a form in an admin screen (for a random example).
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).
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
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”.
It doesn't apply to agents because people coming and going brought their own preferences, dislikes and ignorances. Also unspoken/unwritten rules and ideas for future structure. Agents follow the same AGENTS.md, know all the tricks other agents know, so I would expect them to code more uniformly.
I would encourage you to re-evaluate that expectation. A framework comes with strict, mechanical constraints for both developers and agents, while the contents of AGENTS.md can be ignored by agents. Even skills don't always get invoked, and you sometimes have to browbeat your agent to follow a skill or doc. But a framework provides a hard, mechanical guardrail with loud failures and known solutions. Combined with linting, strict types, and a language server, your LLM isn't going to be tempted to invent baffling solutions when a framework provides patterns for long-solved domains.
I would go so far as to argue that all of the reasons that frameworks are useful for human-led projects are equally, if not more applicable to those executed by agents.
> 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
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.
AFAIK, search is really a place for Algolia to show off its API based search services to the HN audience, not really just built to be a simple static page search result to match the HN architecture.
> 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".
> 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 don't think we're talking about Microsoft here.
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
I agree in principle, but I don't feel in a position to bargain: I'm a junior dev earning below my region's average salary (for all industries, not just tech), far below other engineers my age because reasons, and my education is now becoming obsolete for industry. I'll let others take the high ground, I just want to stay employable and not lock myself out of a decent salary.
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.
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.
And why hire someone who writes instructions for the agent? https://www.youtube.com/watch?v=uYG1TAzexdo
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 :)
This just scratches the surface of the cost-benefit analysis of JS frameworks. Frameworks were built mostly to simplify state mangement as we moved to complex apps from web forms, as they simplify partial loading/state updates.
The formula has changed significantly with LLMs. Managing state is still an architectural concern but not necessarily a human concern, as LLMs can sort out how to make things work. Which framework/approach is best is now an intersection of use case, performance/scale and LLM capabilities.
React wins by default for now because it has so much prior art in models and because devs know how to read and architect with it. In the future we may be generating WebAssembly code for performance with some bespoke state management that is fully rewritten after each change - what matters in the future wil not be legibility but accuracy, malleability and performance.
I’ve been really impressed with the current frontier models’ capabilities to build native macOS/iOS apps. I’ve had Claude build native apps which I would have built as web apps not long ago.
Also, when I first started out building with AI I made sure it would use frameworks and programming languages I know. Now I don’t care at all and let it choose the best technology. I don’t read a single line of code it generates and only work in the harnesses, never in an editor anymore.
I’m only building apps for myself and I’m not a professional developer.
[dead]
> 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.
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.
Weirdly, this underscores my personal non-AI experience of Nuxt, which is that it is almost easier than you'd like it to be.
I'd prefer not to have used Nuxt for front-ends that don't need it, because it's chunky and a greater migration burden, but once a couple of patterns are in place, it's actually rather fun to use. A bit too much fun.
Also it's modestly large up front, which is the downside.
I suspect what is going on here, the same as with Laravel — which LLMs seem to really enjoy writing — is that the documentation is good, clear and ironically human-focussed, more oriented towards understandable recipes and reference, and the middleware setup is not absolutely arcane; at a glance of a Nuxt page's code you can kind of see mostly what it is going to do.
It's astonishing to me that even after a decade of SPA frameworks, most authors don't understand how a browser engine like Chrome works. There's enormous cost of manipulating the DOM from JS, as HTML elements get bound to JS objects lazily.
An actual high performance framework should manipulate HTML as a string directly, or through HTML templates (another feature that has existed in most browsers for a decade).
If you're not building a complex application on top of the web stack (interestingly these increasingly use WASM and their own GUI frameworks, so another moot point), but building an interactive consumption website (scrollable lists of static contents), I'd say instead of fronted frameworks, what most people actually would need is Chrome's experimental declarative partial updates:
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
Everything you said about WASM is false. It uses a variable length encoding for integers (LEB128). It presents as a stack machine (RPN) not SSA. It doesn't expose or impose padding in structs.
It seems like you're extrapolating from things you know to something you don't know at all, and you're spreading misinformation. WASM was designed to be compact.
Sorry I am not an expert on WASM, I just listed thing that are generally true of binary formats, and my main point was that text formats like minified js are pretty good when it comes to size - im sure a tiny js module would beat your wasm example.
The thing is to get these optimizations, like variable length encoding and tightly packed structs, engineers had to work hard, while a dumb text format gives it for free.
Additionally, they gave up the biggest advantage of binary formats - that they can be mmap-ed directly and read from code.
No worries, and I apologize if I was too blunt.
We'd have to get pretty specific to have a real bake-off on size, and that's probably more effort than either of us wants to spend for a HN thread that's basically dead. I could invent scenarios where either of JS or WASM has the advantage.
Code-golfing that particular example though, the JS could be "const x2=a=>2*a;" (15 bytes). If you ignore the one-time (insignificant) costs for the WASM headers and sections, the comparable byte code for that export is about the same number of bytes. If JS wins, it doesn't win by a lot.
Maybe I misunderstand, but I'm not sure I see the point about hard working engineers or memory mapping. I'm sure the JavaScript JIT engineers had to work really hard to get good performance. Among many other things, JS Objects using "shapes" or "hidden classes" was a pretty clever way to compensate for not having structs at all. For both JS and WASM, end developers don't need to worry about it, and you can't mmap JS to execute the code either.
> Maybe I misunderstand, but I'm not sure I see the point about hard working engineers or memory mapping
I was just saying, in my experience, binary formats tend to be easier to parse than text, relying on machine native constructs such as binary integers, sometimes even matching up their stored formats to C struct layouts (this is the case with, Linux's inode format for example).
Whereas complex textual formats such as JSON or Javascript usually have a tokenization and parsing pass. But they are mostly human readable in exchange, which is a ton more engineering effort to build and CPU time to run.
I was just trying trying to say, that once you really get into sophisticated binary formats, you have to take on similar levels of complexity to parsing something like a programming language, meaning that the parser is not simple, or fast, but the file is not human readable either. Which is kinda the worst of both worlds, and doesn't really drastically reduce file size.
TLDR: Text-based formats are fine, expecially for complex data, and are surprisingly competitive with hand-tuned binary formats.
Ahh, I see. That's why you were talking about structs and mmap. Thank you for the clarification.
I've written a lot of text parsers for pet programming languages and other things, and several binary parsers for work related stuff. I agree that bad binary formats are really awful. I don't remember the details now, but I gave up on trying to deal with Matlab data files.
WASM made it pretty easy to parse though. Kind of like TIFF or WAV files, the section type and length is right there when you need it even if you're streaming, and it's easy to skip sections you don't know or care about. There's a little bit of error-prone grossness having both unsigned and signed LEB128 inside of some sections though.
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.
Frontend has exploded in complexity. Separating concerns whereby the frontend does not care about the backend leads to better quality.
Just rendering a simple e-mail client on page 5 of a search result is simple enough to understand that streaming html for that state would require rocket science of string manipulation.
Besides that, you still did not answer how is updating the entire innerHTML for small changes better than just updating affected nodes?
I don't think you're understanding or reading what I linked to. The entire innerHTML of the page is not getting updated. If it was a page showing emails and there were next/prev buttons, next could trigger just the div (or area of the page that shows the list of emails) to reload with the server determined next 25 emails in an HTML snippet. The navigation areas don't change at all on the page, the page and browser don't go through a full refresh at all. There isn't a payload of JSON objects to parse and store in memory, nor a set of APIs to build on the server that output JSON.
Frontends have not exploded in complexity, they are still manipulating a DOM like they have been for 25 years. Complexity was writing different JS implementations for different browsers like Netscape Navigator 4 and Internet Explorer 4. I think a lot of frontend complexity is simply because of JS framework proliferation and a stance that the entire application should be JS in the browser, a full MVC framework when the backend is likely a full MVC framework already and has to validate all the inbound data changes.
What we're arguing about is mostly preference at this point. Please check out what different server frameworks do, there are server side JS frameworks too. If you're building simple web sites (like a pizza restaurant) vs. building a web application (like an app that processes millions of financial transactions per day) then the approach is going to be different and there are trade-offs to be made when picking a tech stack.
I am backend, not frontend but doesn’t this basically mean that the data will never be indexed by a search engine?
All SPA are completely broken for search engines anyway.
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.
AI cost of using anything is a good yard stick to measure things by. Red flags are a high degree of verbosity in tool outputs, complex failure modes, and slow running tools. Basically all that results in AIs having to look and dig through more output (tokens) and spend a lot of time polling tools for readiness (more tokens). The more complex a build for something is, the worse it gets. Especially if you also include things like running tests, linters, and all the rest. It adds up quickly when AI reasoning is causing a lot of trial and error to happen. It will eventually figure it out. But it might not be cheap.
Cost of iteration in time and tokens is really important if you like moving quickly without having to boil the oceans for simple changes. That was always true but AI kind of magnifies it because it's doing a lot of heavy lifting. Most of the time you wait for AI tools, you are actually waiting for tool calls to happen.
At this point just optimizing for all that could save you a lot of time and tokens. Which is really nice for your wallet and maintaining some flow state. I've stopped obsessing about my own biases in tools, frameworks, and programming languages. That made a lot of sense when I was the primary user of that stuff. But I'm not anymore. I might glance at the code to see if it's roughly doing what I expect. But there's too much of it for a detailed reviews and nit picking on my side. If I feel strongly about something, I'll ask for a change. But if it works, I'm often leaning to going with the choices the tool makes for me.
This is a bit of a leap of faith and a lot of people are not ready to make it. But I've found I can be productive with stuff I've never even used before now and that the cost of switching to whatever is fairly low. It does help to have good tools and tests to keep quality levels acceptable. The difference between vibe coding and responsible engineering is basically what you ask for and check for on that front. Having lots of experience doing things the old way definitely helps. But you should not constrain yourself to just stuff you know when solving new problems.
> If I feel strongly about something, I'll ask for a change.
Why not make the change yourself instead of burning more tokens and hoping the change as requested is actually made? Harnesses and models that make human code level collaboration difficult are not useful IMO.
It's akin to using a calculator where you can't access the numeric keypad.
I've found myself reaching for HTMX or Hotwire/TurboStream lately and it had nothing to do with vibe coding.
I find that HTML first web frameworks make way more sense, works out the gate, allows for caching of key parts easily and forces me to think in simpler terms when it comes to implementations. The end result is usually an easier to use app for my end users. The amount of complexity you can add to a UI should be limited but a lot of folks just go crazy with SPA.
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
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.
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.
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.
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.
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.
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.
Interesting, I’m just sad svelte didnt behave better because of the LLM reading migration guide on every answer
This is what I was thinking while doing some work on my projects. I've been a full stack focused developer way before the AI age and at that time DX was something that was a priority for me.
But now, its just about AX (Agent experience lol) how easy can you make it for the agentic system/model to achieve better outcomes. Its as easy as letting the agent choose it's way of doing things - let it choose its own project framework be it Astro, using bun, using handlebars even.
Nowadays people have shifted from writing code anyways - claude code or codex or any agent can do it, all we do is plan and review.
> Its as easy as letting the agent choose it's way of doing things - let it choose its own project framework be it Astro, using bun, using handlebars even.
I would be very surprised if the tool that agents use most effectively is also the one they recommend. There's no clear reason why they'd be the same, until articles like this, neither they nor we know which is most efficient. They're recommending based on their model of normal best practice and patterns (what does everybody else do for a project like this) not "I have analyzed handlebar syntax and I think I will iterate more quickly with this".
I feel validated. Have turned to Astro or HTMX for years. They just made sense. That being said, I vibe coded a complex local-first SPA in Astro last year and the agent struggled with caching and service worker code. It literally wrote an entirely duplicated and separate SPA for “offline mode”
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.
Why is there no Vue.js in the benchmarks?
there’s nuxt, which is a framework based on vue.js
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.
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.
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!
htmx for the win, as always
Express, EJS and PostgreSQL have never failed me, and AI knows them extremely well
Oh btw, there is nothing, and I really mean it, nothing in the Node world faster than that
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.
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.
Nice to see Nuxt holding its own. Astro or Nuxt are my gotos for client work and personal projects.
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.
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
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
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...
Interesting... Training data is really the same as experience in human developers. I favour frameworks I have experience in, the thing is most AI models have similar weights of "experience" and hence certain frameworks are accelerating in popularity.
I 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.
i've genuinely been curious about this as well, recently instead of prescribing next, since its the framework i was most comfy w, i let the agent decide a stack
it chose plain solid wo a frameworks since i wanted the backend in rust anyway.
the rationale was streaming ai responses is better in it, since react re-diffs the dom every time a token is streamed, while solid just updates the exact node text changed.
tbh nowadays ive stopped caring about frameworks. wtver is comfier for the agent to write in, with enough back pressure from tests, ci and lifting so that agent fuckups dont reach me is good enough for me
this is what i was building https://github.com/clauseo-ai/boxbox2
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.
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!
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).
It is fairly obvious that it is all going to be some kind of React/JSX with tailwind.
It's definitely all tail wind
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.
No Vue, huh
Nuxt is listed
> I should first note two caveats about my benchmark:
> The Pokémon app is small and doesn’t represent a large, complex real-world application.
That's a pretty big self-inflicted caveat. How do you know the results will translate to complex-real world applications?
Why not try adding a bunch of complex features to the app (Auth, battles, marketplace, social interactions, etc.) to see how an actual production frontend would hold up?
> But in the agentic era, when developers are no longer typing code by hand and are thus less constrained by DX, I still see vibes ruling the day (and not just in the sense of “vibe-coding”). Frontends are rewritten because some framework or another is “better for agents.” (Did anyone think to ask the agents?) The resulting code is “faster,” the agents make “fewer mistakes,” etc. Once again, these claims are often made without evidence. Whenever I read one of these accounts, I think to myself, “Where are the benchmarks?”
Again the law is laid down. Developers no longer X. They Y.
Feign dismissal over vibes all you want. Same old inevitability posting.
Enlightenment will be achieved when agents set up the benchmarks for what JS frameworks are good for agents. Other agents will interpret the results. Modern, peer-reviewed science.
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.
[flagged]
[flagged]
[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.