The are some very real costs to JavaScript frameworks. These frameworks do not exist to empower developers. They exist to:<p>* so that employers do not have to invest in training developers.<p>* to ease candidate selection at hiring, which greases the wheels of hiring/firing<p>In the big corporate world, especially at non-software companies, there is a culture that strongly believes internally written software sucks. This is <i>Invented Here</i> syndrome, and it reflects that internal developers cannot write software and employers will not invest in maintenance.<p>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.<p>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.<p>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.
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.<p>[1] <a href="https://blog.risingstack.com/the-history-of-react-js-on-a-timeline/" rel="nofollow">https://blog.risingstack.com/the-history-of-react-js-on-a-ti...</a><p>[2] <a href="https://medium.com/@sjarancio/reactjs-a-brief-history-3c1e969a477f" rel="nofollow">https://medium.com/@sjarancio/reactjs-a-brief-history-3c1e96...</a><p>[3] <a href="https://medium.com/the-startup-lab-blog/the-history-of-angular-3e36f7e828c7" rel="nofollow">https://medium.com/the-startup-lab-blog/the-history-of-angul...</a><p>[4] <a href="https://medium.com/@andrewchall92/how-jquery-was-born-a-brief-history-of-the-most-popular-javascript-library-df3eb5256833" rel="nofollow">https://medium.com/@andrewchall92/how-jquery-was-born-a-brie...</a><p>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.
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.
I think you put way too faith in a human capacity to plan in such a "long-term".<p>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 <i>and</i> 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.<p>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.<p>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 <i>not</i> 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).<p>* 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 <i>claim</i>—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)
> If you roll your own - and you will,<p>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 <i>blog</i> here, I‘m talking about commercial, complex applications.<p>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“ <i>will</i> 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.<p>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.<p>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.<p>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.<p>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.<p>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 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.<p>I do tire of the failure to perform and the endless empty excuses.
> another company and volunteers pay for maintenance<p>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
Meanwhile, LLMs have massively buffed internally developed software.
This is buried at the end.<p>> 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.<p>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.<p>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 :)
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: <a href="https://code.garage44.eu/jeroen/mithril" rel="nofollow">https://code.garage44.eu/jeroen/mithril</a>
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. <a href="https://arrow-js.com/" rel="nofollow">https://arrow-js.com/</a>
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. <a href="https://github.com/standardagents/arrow-js/graphs/contributors?from=2%2F1%2F2021&to=10%2F25%2F2026" rel="nofollow">https://github.com/standardagents/arrow-js/graphs/contributo...</a><p>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.<p>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 (<a href="https://web.archive.org/web/20230609020338/https://www.arrow-js.com" rel="nofollow">https://web.archive.org/web/20230609020338/https://www.arrow...</a>), incredibly funny they pivoted into making it a fully fledged framework after all.
Yeah it's really enjoyable to be able to take old, stale dependencies, and simply make them into something great, typesafe, ESM, well tested etc, without having to change the whole codebase.
Yes, Mithril enhanced with signals feels very efficient und saves tokens.
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.<p>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).<p>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:<p><a href="https://developer.chrome.com/docs/web-platform/declarative-partial-updates" rel="nofollow">https://developer.chrome.com/docs/web-platform/declarative-p...</a><p>Which basically stream HTML fragments from the web.
String manipulation for HTML is a great way to introduce security vulnerabilities.<p>WASM is a non-starter for most web applications due to initial binary download.<p>Advising to use some experimental feature in one browser does not seem like a great idea.<p>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:<p><pre><code> const binary = Uint8Array.fromBase64(
"AGFzbQEAAAABBgFgAX8BfwMCAQAHBgECeDIAAAoJAQcAIABBAmwL"
);
const module = new WebAssembly.Module(binary);
const instance = new WebAssembly.Instance(module, {});
console.log(instance.exports.x2(3));
</code></pre>
This is a trivial and useless example at 39 bytes, but a real example could be more compact than comparable minified JavaScript.
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.<p>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.
I am backend, not frontend but doesn’t this basically mean that the data will never be indexed by a search engine?
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?
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.<p>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.
> There's enormous cost of manipulating the DOM from JS, as HTML elements get bound to JS objects lazily.<p>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.
this doesn't even benchmark anything really wrt user experience, so what does that have to do with the article?<p>the author measured near perfect scores on lighthouse across the board, which, i mean no surprise there?<p>then it has takes about payloads and ttfb, which is nearly meaningless without implementation details and one being an expert in each framework, imo.<p>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?<p>> HTML templates (another feature that has existed in most browsers for a decade).<p>not really? browsers weren't even at the level of <i>baseline</i> a decade ago. microsoft edge on chromium is six years old.
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.<p>Nowadays: Electron slop that will also eat a bunch of their RAM.<p>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?<p>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.<p>That's what a browser is. Your apps <i>are</i> native.
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.<p>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.<p>In my personal use case, that would be Svelte 5 for me and I'm sure it will be something else for everyone.
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.<p>If anyone interested here is the source code all done by Opus 5.5
<a href="https://github.com/ramigb/esdara" rel="nofollow">https://github.com/ramigb/esdara</a>
Astro comes out on top with the best time, #2 lowest spend and <i>zero</i> 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.
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.<p>Very easy to setup and way more readable than the equivalent React code.
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.
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.<p>Django?
next project? pun of the year?
HTMX is interesting.<p>I have most of my apps in it without much trouble.<p>One of my recent ones had a very complicated form and state management.<p>AI really struggled with HTMX in that use case.<p>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.<p>If I rewrote that in react it would have one shot it without a doubt. Some things are just better models for different problems.<p>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 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?<p>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.<p>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.<p>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<p>I'm still sour why goto doesn't exist in javascript
Yes, I keep saying this. Async await is like loading spinners - a fix for a problem that shouldn't exist in the first place.<p>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).<p>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.<p>This hurts most badly for iterators.<p>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.<p>If you have ten layers of transformation it will be 655,350 defensive deferrals and 10 real waits.<p>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: <a href="https://github.com/nodejs/node/issues/31979" rel="nofollow">https://github.com/nodejs/node/issues/31979</a><p>The solution is stream iterators. They are sync when they can be and async when they must be: <a href="https://docs.bablr.org/architecture/spacetime" rel="nofollow">https://docs.bablr.org/architecture/spacetime</a>
not a surprise - frameworks or libraries that were easier for humans e.g htmx, hono (expressjs like) are also easier for agents.
> in the agentic era, when developers are no longer typing code by hand<p>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.<p>The overwhelming majority AI spend is being done by startups funded by venture capital.<p>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.<p>Perhaps dead internet theory applies more than normal to programming forums.
Thank the gods, nobody's forcing me to be employed.
Neocities ride hard on the old-internet hand-crafted HTML aesthetic. Maybe we could start a similar club?
Java script frameworks are just extra boiler plate that isn't needed in the age of ai-coding.<p>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.<p>All of these thing still matter no matter what you are coding with.
The vanilla advantage is also there in a pure client-side pwa. Arguably it’s even bigger, because the bundle size ends up way smaller and the agent needs to hold less in context.<p>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.<p>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...
All web pages should be WASM binaries now.
In typical HN style, you are both pretentious <i>and</i> wrong. Javascript frameworks save you the complexity of an agent holding the entire library code in their context. For example, an agent can work with 2-4 react components for a current ticket without needing to know each line of internal React code.
They also were unnecessary even before AI, the biggest advantage of React over HTMX-style apps was that you could recruit someone more easily but the SPA complexity wasn't worth it and it scaled terribly.<p>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.
If you want to see how to write a maintainable application without a huge framework here's an example: <a href="https://github.com/wisercoder/eureka/tree/master/webapp/ClientApp" rel="nofollow">https://github.com/wisercoder/eureka/tree/master/webapp/Clie...</a><p>It uses two 500-line libraries, one for using JSX syntax, and the other for MVC.
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.
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.
"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?<p>and what % of users have JS turned off? 0.00001%?
> At the very least, make your your websites degrades gracefully when JS is turned off.<p>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.
HN uses JavaScript though, not just plain HTML.
At least one (or maybe two depending how you define things) of the examples does that. Because you mean "client side javascript".
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.<p>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.<p>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).<p>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.<p>A while ago, I showed Claude a relatively complex application I had built with my framework <a href="https://saasufy.com/" rel="nofollow">https://saasufy.com/</a> 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.<p>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).
Interesting, I’m just sad svelte didnt behave better because of the LLM reading migration guide on every answer
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.<p>Obvious solutions are to vendor your dependencies (compile the framework from owned source) or to drop to the lower level of abstraction.<p>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.
Interesting that the lines of code are basically the same across all frameworks, including vanilla JS.
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.<p>Traditional languages may have their limitations, but [C++, Rust, JavaScript, TypeScript etc] can still do pretty well.
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.
This was very interesting and I was fortunate to have my bias validated further for HTMX ;)<p>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.<p>Why are agents when given control to decide, almost always choose Next.js? SEO/AEO?<p>Aside from a more complex web app for the future benchmark, I have suggestions of what else I'd like to see included:<p>- 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.
Nice to see Nuxt holding its own. Astro or Nuxt are my gotos for client work and personal projects.
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.<p>If you aim to make small apps that don’t represent complex real-world applications you should not use Angular.<p>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?
Well if you aim to make complex real-world applications you also should not use Angular. Hate towards Angular comes with experience.
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.
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.<p>Not necessarily that Angular would win that, but I imagine that it would at least significantly shuffle the order.
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.
It is fairly obvious that it is all going to be some kind of React/JSX with tailwind.
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!
where is jquery? :(
my experience is that one-shotting a simple front end works great. Then you want to add features and move things around and each turn starts getting slower and the single page with JS and CSS and HTML starts to turn into a 3000 line monster and your context window starts to creak under the strain of even simple changes, because the LLM has to keep more and more of the application in its head just to make relatively small changes without breaking something else. Either you should have started with some kind of framework with hygienic rules on how to separate concerns or at minimum a good set of coding standards that force the LLM to start building clean components from scratch. The benefit isn't necessarily cleaner code for its own sake, it's that the LLM can work on one part of the application without having to understand the whole thing every time. That being said, once you have a 3000 line prototype it's not that complex to simply ask the LLM to refactor it into a set of orthogonal components. As long as it was building unit tests using playwright or something this can turn your slop into <i>framework</i> code cleanly. The interesting question is whether you saved anything by putting off that structure in the first place.<p>I run into this problem turning claude artifacts into things I might want to maintain longer term.
htmx for the win, as always
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.
Unfortunately the author is not only correct about front end development vibes, but due to this state of affairs, I ceased to recognize browser based UIs as being software development at all. Too much browser tech is broken to call it software. As for agents, good for them!
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]