Very easy to setup and way more readable than the equivalent React code.
Django?
If you aim to make small apps that don’t represent complex real-world applications you should not use Angular.
But blanket statements like yours are what I hate the most in software industry.
I've built large FE systems with millions of lines of code pushing tens of billions of dolllars in revenue (I was lead FE dev on that one).
The idea that failing to do a small project (that should be clearly represented in the training data) means failing even harder at bigger projects doesn't suddenly gain merit because I have a lot of experience and have worked on big projects.
Your first sentence is telling me you were in more of a bike shedding projects than skyscraper one.
Not necessarily that Angular would win that, but I imagine that it would at least significantly shuffle the order.
and what % of users have JS turned off? 0.00001%?
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.
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.
Server side page generation with a sprinkle of js will give you the same results with GBS less of packages and comple time
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...
Plus all the other vanilla advantages: fewer dependencies, lower maintenance, less retraining, etc…
Now that you don't write the code, I don't see why I would pick React style libraries unless the codebase is already there.
It's all about how much interactivity you need. A lot of business web apps are full featured commercial software packed in SPA form. You will need a lot of stuff client side and without framework it will be a mess. Unless you write framework yourself but the you are reinventing a wheel.
I think unless you have a very low number of features or employees (and are sure from the start to keep it this way) I don't see it working.
In my 3 previous companies I had similar issues so I think it's widespread.
All of these thing still matter no matter what you are coding with.
Having some sort of reusable framework is important for maintainability, always has been. Sure, you can have an agent "write a small JS framework that covers common functionality", but then you need to know what should fit into that framework. Having a framework pre-defined saves a lot of decision making and helps avoid drift.
In my opinion, this has always been true and it hasn't changed with AI-coding.
I hope I'll be the last person on Earth writing code by hand.
The overwhelming majority AI spend is being done by startups funded by venture capital.
Meanwhile, big companies have massively cut/capped AI spending at the exact time these companies need to triple prices to get any margins at all.
Perhaps dead internet theory applies more than normal to programming forums.
$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.
Meanwhile, a friend at a consulting company of similar scale tells me they don't hire anyone who shows a lack of experience with "agentic engineering" during the interview. They're turning all their projects into software factories from issue ticket to deployment. He's much more resourceful and experienced than me so I trust he isn't automating himself out of his own job, but I'm much more gloomy about this transition.
Technologists uncritically doing the bidding of Silicon Valley billionaires. Same as it ever was. https://news.ycombinator.com/item?id=50274456
> 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 :)
I have most of my apps in it without much trouble.
One of my recent ones had a very complicated form and state management.
AI really struggled with HTMX in that use case.
Like the form might work but the page would take 30s to load. Or some state would randomly drop or a toggle wouldn't work after changing a dependency.
If I rewrote that in react it would have one shot it without a doubt. Some things are just better models for different problems.
For the record I eventually got enough tests in place to keep the agent honest and the HTMX version is now a lot faster anything I could have got out of react but yeah, it was an adventure.
Also, it’s a language where everything happens somewhere else. Not here and now, somewhere else on some other event. That sucks for the small stuff.
Async JavaScript using callbacks had a learning curve, but once you learned how to contain it and treat callback indentation as an opportunity to refactor it felt similar to coding in lisp.
The problem was the learning curve, and the fact you had to rewire your brain a bit compared to coding in something procedural.
As much as possible should be happening locally, synchronously on the computer, in-process, or at least without yielding your thread context (and even then there are things like page faults which async/await wont save you from, they are 'invisible' to a regular developer).
While you might dismiss this idea, page faults used to be THE leading cause of delays back when hard drives were the norm.
This hurts most badly for iterators.
Files are usually read from disks in chunks of 64K bytes. If you present the data as an async byte iterator you'll get 65,534 defensive deferrals, and one actual wait.
If you have ten layers of transformation it will be 655,350 defensive deferrals and 10 real waits.
These defensive deferrals aren't so expensive in terms of CPU time, but they ARE very expensive in terms of wall clock time. All other work must be halted so the event loop code can run. Eventually synthetic deferrals dominate the wall clock cost of running the program. This isn't hypothetical either. Here's someone trying to build steam parsing on Node and finding that it's too slow to be useful: https://github.com/nodejs/node/issues/31979
The solution is stream iterators. They are sync when they can be and async when they must be: https://docs.bablr.org/architecture/spacetime
That's a (bad) JS design choice, for example C# doesn't do this. Actually I'm pretty sure even in JS, async/await gets transpiled to state machines, so I think this is easily fixable by shipping a new transpiler implementation that only defers when necessary.
I get your point, but I don't think we should go back to oldschool yield-based iterators to hack around a broken implementation.
I would like to see official support for `Symbol.streamIterator` and for the `for await?(item of iter)` syntax which would transpile to code like you see here (or all the way down to regenerator state machines if needed).
I'm still sour why goto doesn't exist in javascript
Traditional languages may have their limitations, but [C++, Rust, JavaScript, TypeScript etc] can still do pretty well.
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.
I run into this problem turning claude artifacts into things I might want to maintain longer term.
https://github.com/anthropics/skills/blob/main/skills/web-ar...
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 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.
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.
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.
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.
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.
I’m the first to complain about the bloat of modern frameworks but stepping all the way back to HTML strings would be a total mess for anything relying on heavy interactivity.
the author measured near perfect scores on lighthouse across the board, which, i mean no surprise there?
then it has takes about payloads and ttfb, which is nearly meaningless without implementation details and one being an expert in each framework, imo.
are you just ranting about javascript in browsers because its accepted and articles like this become a place to welcome such without anyone caring about the topic?
> HTML templates (another feature that has existed in most browsers for a decade).
not really? browsers weren't even at the level of baseline a decade ago. microsoft edge on chromium is six years old.
I think a lot of JS developers fail to recognize the variations of client systems power or people's usage patterns like how many tabs are open, how much GB of memory is their browser using, is the client machine paging out to disk, stuff like that. Not everyone is running a MacBook Pro so heavy client side JS apps tend to be "slow" to end users, at least perception.
Read more here: https://turbo.hotwired.dev/handbook/introduction
Elixir has a similar mechanism with Phoenix LiveView.
And the cost comes from the fact the browser builds its internal lightweight representation of the DOM when parsing and rendering. You can access this optimized happy path when you are manipulating the HTML through innerHTML or with the <template> DOM tag.
Whenever you access the DOM via JS, a proxy object is created by the VM for each node, and manipulation happens through that. This is a fairly substantial memory and bookkeeping cost, which you don't pay with static HTML.
You can
WASM is a non-starter for most web applications due to initial binary download.
Advising to use some experimental feature in one browser does not seem like a great idea.
JavaScript frameworks are not perfect but they exist for good reasons. People that brush them away usually lack the experience and understanding on the topic.
const binary = Uint8Array.fromBase64(
"AGFzbQEAAAABBgFgAX8BfwMCAQAHBgECeDIAAAoJAQcAIABBAmwL"
);
const module = new WebAssembly.Module(binary);
const instance = new WebAssembly.Instance(module, {});
console.log(instance.exports.x2(3));
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.
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.
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
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.
Fewer lines of code (per piece of functionality) does, in fact, correlate strongly with maintainability. The downside of this metric to watch out for (as Goodhart's Law would have it) is to ensure that the framework isn't compromising (current or future) flexibility in an unacceptable way. I imagine if this kind of benchmark becomes popular, people would start coming up with low code frameworks which are extremely rigid and inflexible. Because rigidity is a good way to cut lines of code. There needs to be a way to ascertain the flexibility limits of the framework too.
Would be good to have a similar benchmark for a more complex application; one with authentication, access control (with individual ownership of records and group ownership).
Also would be good to compare the security of different frameworks in this way. See which frameworks leave security gaps. Would be good to set up a benchmark where an AI agent is made to impersonate different users (with different roles) and test access to all possible data types and views in an exhaustive way.
A while ago, I showed Claude a relatively complex application I had built with my framework https://saasufy.com/ and asked it to estimate how many lines of code and how long would be required to build the same application with a stack like React + Node.js + Postgres and it estimated that it would require 4 to 5 times the amount of code and amount of time so I'm keen to actually test it out with a benchmark like this.
I was not surprised that HTMX lead in a lot of the benchmarks. I suspect it would do even better with a more complex application. IMO, its design is closer in spirit to where the industry needs to go. There are a lot of maintainability and security gains to be had by standardizing frontend and backend interactions; though I believe there are other way to do this which can yield even more gains (though obviously with some tradeoffs depending on the use case).
I once also worked on a simpler application (feature-wise) for someone else which was approaching 100k lines but it was poorly architected with a lot of bad abstractions and over-engineered. In this case I could claim that my framework is cutting almost 99% of the code but that's comparing to the worst possible situation. Still, even that's not necessarily an unfair comparison because, in practice, a lot of real projects do end up bloated to such extent after a decade or so, likely even more so now with AI. Any framework which can prevent that bloat code from being generated is genuinely delivering long term benefits.
* 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.
[1] https://blog.risingstack.com/the-history-of-react-js-on-a-ti...
[2] https://medium.com/@sjarancio/reactjs-a-brief-history-3c1e96...
[3] https://medium.com/the-startup-lab-blog/the-history-of-angul...
[4] https://medium.com/@andrewchall92/how-jquery-was-born-a-brie...
Now if you have written your own applications nearly 60-80% of it executes outside the browser even when the only interface and use case is in the browser. The current common use case for these frameworks is that most developers cannot write original software and when they try they either fail, with plenty of face-saving excuses, or just create something that looks identical to their favorite framework. This is the primary problem these frameworks currently exist to solve for.
It most certainly is not.
It’s really simple. You can write an original application in your own code or you just can’t. I don’t care about all the excuses, because it just isn’t that challenging. It’s not for everyone.
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.
That's where most complo theories fail...
This is something that people who cannot live without frameworks often repeat, but its a fiction of their own creation.
If you plan to sell a digital product or SaaS on the internet and your use case is more complex than a blog or a portfolio site, your „vanilla js purity“ will outgrow the project, fast, and it will become a mess. I‘ve never not seen it end this way.
I do tire of the failure to perform and the endless empty excuses.
If that's true, that's just pointlessly wasteful of your time and effort.
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."
> 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.
For reference, my last job at an industry giant had a frontend-facing monorepo of a million lines or two.
It's not your fault, since most companies don't want to invest resources on properly maintaining their code.
It's not your fault, since assuming the best about people on the internet is not actively rewarded by social media these days.
"I don't use frameworks, y'all can't program" - I mean, good for you, but I want to pay my bills and my clients sure aren't paying me to reinvent the wheel for the 20th time?
We have different wheels for different use cases. You can't use the same wheel for all of them.
It helps when you write software other people want to use and provide good enough documentation.
Your comment completely reaffirms my original comment way at the top in that these frameworks largely exists so that employers can avoid any kind of investment in their developers.
I find it very hard to believe you and blaming developers for using trusted library code to not re-solve problems, thereby earning a living, is a pretty harsh statement.
How are you convincing your clients that they should pay a senior to re-engineer solves problems?
I'm not understanding why you have the idea that it's a huge drag on productivity and hand rolling the same patterns everyone ends up needing will somehow be more efficient.
Part of the foolishness here is that you are convinced your approach is faster but you have no idea what my approach is. You certainly aren’t measuring anything so even if you were aware of my approach you are still just randomly guessing at the result.
I've seen the situation where underqualified, overambitious programmers build an internal platform that becomes a monster. There isn't the time to mature it, there isn't a standard or docs to point to, it becomes a drain on the company, at worst someone's vanity project.
I've also seen the situation where a team absolutely refuses to build anything themselves out of anxiety, spending enormous amounts of money on an external solution that acts as a rent extractor.
The problem with buy-not-build, is if you do it for too long, you forget how to do the latter. This is great right up until you find a problem you can't buy your way out of.
Sometimes building something half good, is fast enough and educational enough to get you to the next step.
There’s still value in building something from the ground up; you understand the framework that much better. But so long as your needs largely overlap with the community, the benefits of working with the community are real.
My coworkers are very smart -- smarter than me -- so I'm low confidence anyone else could have done significantly better or avoided the pitfalls we fell into.
That 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.
The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"—or, put more charitably, a hunch plus some inductive reasoning. It's not a tested hypothesis.
The crux of your argument* is essentially "a + b > a for some non-zero b", where b represents what you are "paying for your library code". The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method ("Just Do It") when it comes to dealing with things yourself (i.e. the framework cost—which, like b, is never zero).
* as stated at least; it's possible and probable that you really don't mean to say that c simply doesn't exist but that b > c (either by intuition or experience or both) but that's still just a claim—which is the entire basis for the author's criticism: not whether frameworks are or aren't actually more cost-effective, but the greater meta-level concern described here in this comment, in the original piece, and other comments by the author and people like Alex Russell elsewhere describing how resistant the culture is towards the notion of attempting to prove or falsify these kinds of claims (if you can even manage to get people to agree to formulate them in such a way that they can actually be subjected to the scientific method)
Is it? Because in my experience, this is flat out wrong and it's very easy to verify, and it is a tested hypothesis.
> The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method
You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper. Why would that ever be true? React doesn't do DOM manipulation for funsies, if you foregoe a framework you'll be implementing reactivity, interactivity and performant code yourself. The browser is very barebones in that regard. The framework cost is always lower than rolling your own, and this isn't even the argument people are having. Non-Framework evangelists are arguing performance, never cost.
A framework doesn't come into existence out of thin air. If you choose one, you're working with a community of thousands of developers. I don't have to build my own reactive table, I can use TanStack table. I don't have to build my own playground, I can use stackblitz or storybook to showcase stuff to a client. I don't have to build my own cancellable asynchronous list, I can use a trusted library for that, too. My client doesn't care if I roll my own. They care about effect per hour spent.
First, not using a framework doesn’t mean you have to roll your own (otherwise you’re still using a framework?). Second, this is the claim the parent wants you to substantiate, that not using a framework is always more expensive than using one.
That's the best case. Usually it was just thousands of lines of jquery spaghetti.
1. I tried to write vanilla JavaScript once and failed miserably so therefore humanity is completely incapable of accomplishing such
2. I cannot organize instructions to save my life so therefore the result for all developers must always be spaghetti
The unspoken third option is that the people making these claims can’t write software and need to blame something else, however irrationally, because they lack the maturity to find a way forward.
I'm just reflecting what I've seen in the field. Webapps evolve over time and sometimes that has meant just ladling on more kludgy javascript event handling. If there is a homegrown state manager, that's usually better than the alternative. (although the frameworks are mostly just fine)
I suspect your point is that Angular or React must exist as the primary work product for a team to operate, but why? Are you suggesting that nobody is capable of writing software without a third party framework to tell them what to do? To me this sounds like you have absolutely no idea how to program or that you have no faith that anybody can program original solutions... except for the people who invent large frameworks.
1. Ad hominem attacks on the original commenter
2. The arrogance and limited viewpoint that ignores the very fact that this can be observed by non-original writers of code, and that this scenario is so common that it coined an original term and spawned an entire industry of clean-uppers.
Ad hominem literally translates as "to the man". It is a direct attack on the person in conversation instead of the subject of conversation, which does not apply on nameless third parties.
They clearly feel personally attacked by your statement. Almost as if there is some truth to it.
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.
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.
The reason we moved away from this and into functional/reactive programming with things like React is that it eventually creates a mess too big to untangle. We made this experience with human developers and I made exactly the same experience with LLMs, trying to go "vanilla". It works for a while but the defect rate rises quickly und the LLM spends a large amount of time navigating the mess it created. I ended up with React again because it lets you express a lot of stuff as pure transforms, which are easy to reason about for human and LLM alike, and the LLM knows it very well out of the gate.
And by "React" I don't mean "react router" and all the other unstable crap in the ecosystem. React itself is stable and that is extremely important for LLMs, otherwise it will constantly conflate what the API actually looks like now. Breaking API changes are poison, worse than going with an in-house library that the LLM doesn't know how to use, because at least then it will look it up straight away, rather than messing it up (because it _thought_ it knew how it is supposed to work) and _then_ looking it up..
But in most web apps, interactive widgets are just little islands in the page. The higher concerns are routing, authorization,… which are already handled by the browser/server interaction.
Many people phrase it like this, insisting that server-rendered HTML is simpler. To me, SPA's are the simpler approach. They remind me more of the .EXE's I used to ship.
I also stay away from dynamic prerendering and/or hydrating. If an SPA can't be hosted statically, it should have a very good reason.
IMO building around Vue has really paid off over the last decade. They fixed the frequent Webpack config issues with Vite, they fixed the frequent Jest issues with Vitest, they improved build times a lot with Rolldown and oxc, they fixed all the annoying linter/formatter config stuff with oxfmt & oxlint, and Vue itself prevents tons of issues that plague React projects.
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.
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.
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”
I have seen countless "founding engineer" job ads with every little detail of the desired stack/architecture spelled out: Java/Spring/MySQL/Linux/Log4J, C#/RabbitMQ/MSSQL/SSIS/Windows, etc. Non-technical founders/recruiters/etc don't want to "leave things to chance", and will happily overly specify the constraints, mostly informed by popularity ("Nobody Gets Fired For Buying IBM"), rather than leave the solution space unconstrained for some "generalist" to choose. I mean, how do you even know someone is competent if you can't grill them on a concrete set of buzzwords?! The horrors! So of course the recruiters gotta make up constraints to find someone "qualified".
Heck, I've personally seen this pattern at every step of company growth, from 5 employees to hundreds. I've watched as my employer's recruiters would explicitly seek tons of things we weren't yet using. Why? Because when performance isn't as desired, the first thought is not "hey, maybe our approach to managing people and projects is dysfunctional", but rather "maybe we just haven't found the silver bullet yet; let's go shopping". In my experience over 20 years, that represents 99% of the cases where new crap gets introduced: Scrum, Jira, SQL Server Integration Services (SSIS), front/back end frameworks, consultants ("our developers must be idiots, so let's get outside experts"), etc.
I think it is true that there are cases where developers will push for things like particular front end frameworks, but that's almost always the exceptionally rare case where there's any resistance to push against: few companies aren't already using the stack du jour, so most developers (especially greenhorns) will have bought into that stack ('cause "gotta pay the bills"), so a new developer brought into a nonconforming engineering org will quite likely want to use the tools they know and thus push for it. The real culprits, though, are usually the non-engineers: founders/recruiters/etc who create a financial imperative to adopt whatever is trending, which results in developers who spread that popular mediocrity elsewhere.
This is backwards. The pressure from the business/product side is to create more and more interactive applications. Jquery hit its limits supporting that reasonably, sometime around the early 2010s.
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.
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.
That said, almost every JS framework degrades to... a browser, do whatever you want, I find it hard to believe any have actually limited your ability to accomplish something unless it was truly beyond the ability of a web browser.
Libraries are code that you call to perform specific tasks. You control the program's structure and execution flow. You're in charge and you call the library when needed.
Frameworks invert the relationship and call into your code and hence dictate the overall structure and execution flow of your application. It's in charge and it calls various customization points that you provide to it at predefined points.
These definitions largely date back to the late 1980s with the introduction of object oriented frameworks (see Designing Reusable Classes from 1988). Further references include:
https://en.wikipedia.org/wiki/Software_framework#Comparison_...
> a culture that strongly believes internally written software sucks. This is Invented Here syndrome
It's the inverted invented here syndrome ;)
But it is oh, so true. Entirely, unsurprisingly -- an internal software stack has captive audience, and never compete with anyone else.
They can good, but exception to the rule.
No, I think they had it right. Your "inverted invented here syndrome" would be the original NIH syndrome, in which people prefer building their own version of everything.
I don't think we should discount the overhead that goes into making a component system with state management, and how much that simplifies application design as it allows you just to focus on data flow. The leap from a render function with a declarative dom DSL to something with state management in terms of complexity is nontrivial, and the amount of code you can you clean up with going from one to the other is also massive.
I get everyones definition of a framework slightly differs, mine is mostly when there's some level of inversion of control that you need to buy into through an app, and I think component system fits that description. Even so it may be a less contested kind of a framework.
Component systems are the new OOP. They are numerically complex. People think they are all the rave and I don't know why, but then people also think OOP is generally all the rave and I don't think they know why.
You don't need component systems, but if you choose to go down that path just realize everything is far more work because there is tremendous amounts of duplication both explicitly in your logic and under the hood where you are not looking. Most people who believe they need this are locked into an enormous framework and deliberately avoid looking under the hood, because its a giant scary beast they believe they cannot live without.
If you want simple you will do everything in your power to avoid component systems, because simple does not mean easy. Rich explains it better in what might be the best computer science talk ever given: Simple Made Easy
React is actually more functional than anything else.
Of course if you actually try to be pure functional many developers will scream at you “prop drilling! Code smell!” But to me that it is a much lesser evil than useContext() and what is essentially global variables
The only language/framework that is truly functional in that sense is Elm.
But I'm talking about interactive UIs which need state, as the environment its running in (the browser) is inherently stateful, and there are efficiency gains from doing so.
This isn't just an OOP thing, even in Elm & Purescript there are similar libraries for stateful UI. In you're doing anything like that in Closure or Clojurescript or whatever, I guarantee you its built on similar data structures and its foundation has many equilivant constructs.
It uses two 500-line libraries, one for using JSX syntax, and the other for MVC.
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.
If anyone interested here is the source code all done by Opus 5.5 https://github.com/ramigb/esdara
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.
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.
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.
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.
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.
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.
But for agents it doesn't matter, so why frameworks at all?
PS: authors comparison is not relevant, as it's simple mostly-static app with very little cross-dependencies, localizations, component re-usage.
Point is frameworks or not, Agents make a mess in javascript, so maybe it’s actually an improvement to establish the standard lib as the foundation and steer Agents from there. Adding frameworks expliodes the surface are of options.
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.
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 think it, also, had a lot to do with the promise that most machines could run Java if they had the runtime installed
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.
> 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?