The AI cost of JavaScript frameworks

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.

Very easy to setup and way more readable than the equivalent React code.

The last ten years I spent as a front-end "full stack" dev and every time there was some new shiny JS framework, all the devs would get out their tiki torches and pitchforks, go to management and tell them they should really really move to this new framework because blah blah blah.

In less than five years our department did this:

backbone -> angular -> react -> ember -> next -> vue -> svelte -> and finally back to angular/react which is what a majority of what we build with now.

Doing this insanity also created a way for mangers to make sure their year-end reviews looked good and polished. Every time an app that was built on a framework a few years old, suddenly a manager would declare it "dead" and needed to be re-built in record time (because the new framework allows devs to build Rome in a few days time). We would bust ass, usually hitting the deadline with something put together with duct tape and code no dev would willingly sign off on. Manager gets their raise and bonus at the expense of a host of devs running for the door.

Rinse, repeat. But 100% of the framework changes were always pushed the hardest by the devs.

I have seen countless "founding engineer" job ads with every little detail of the desired stack/architecture spelled out: Java/Spring/MySQL/Linux/Log4J, C#/RabbitMQ/MSSQL/SSIS/Windows, etc. Non-technical founders/recruiters/etc don't want to "leave things to chance", and will happily overly specify the constraints, mostly informed by popularity ("Nobody Gets Fired For Buying IBM"), rather than leave the solution space unconstrained for some "generalist" to choose. I mean, how do you even know someone is competent if you can't grill them on a concrete set of buzzwords?! The horrors! So of course the recruiters gotta make up constraints to find someone "qualified".

Heck, I've personally seen this pattern at every step of company growth, from 5 employees to hundreds. I've watched as my employer's recruiters would explicitly seek tons of things we weren't yet using. Why? Because when performance isn't as desired, the first thought is not "hey, maybe our approach to managing people and projects is dysfunctional", but rather "maybe we just haven't found the silver bullet yet; let's go shopping". In my experience over 20 years, that represents 99% of the cases where new crap gets introduced: Scrum, Jira, SQL Server Integration Services (SSIS), front/back end frameworks, consultants ("our developers must be idiots, so let's get outside experts"), etc.

I think it is true that there are cases where developers will push for things like particular front end frameworks, but that's almost always the exceptionally rare case where there's any resistance to push against: few companies aren't already using the stack du jour, so most developers (especially greenhorns) will have bought into that stack ('cause "gotta pay the bills"), so a new developer brought into a nonconforming engineering org will quite likely want to use the tools they know and thus push for it. The real culprits, though, are usually the non-engineers: founders/recruiters/etc who create a financial imperative to adopt whatever is trending, which results in developers who spread that popular mediocrity elsewhere.

This is backwards. The pressure from the business/product side is to create more and more interactive applications. Jquery hit its limits supporting that reasonably, sometime around the early 2010s.

The reason we moved away from this and into functional/reactive programming with things like React is that it eventually creates a mess too big to untangle. We made this experience with human developers and I made exactly the same experience with LLMs, trying to go "vanilla". It works for a while but the defect rate rises quickly und the LLM spends a large amount of time navigating the mess it created. I ended up with React again because it lets you express a lot of stuff as pure transforms, which are easy to reason about for human and LLM alike, and the LLM knows it very well out of the gate.

And by "React" I don't mean "react router" and all the other unstable crap in the ecosystem. React itself is stable and that is extremely important for LLMs, otherwise it will constantly conflate what the API actually looks like now. Breaking API changes are poison, worse than going with an in-house library that the LLM doesn't know how to use, because at least then it will look it up straight away, rather than messing it up (because it _thought_ it knew how it is supposed to work) and _then_ looking it up..

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/

[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.

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.

This is something that people who cannot live without frameworks often repeat, but its a fiction of their own creation.

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)

That's the best case. Usually it was just thousands of lines of jquery spaghetti.

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.

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.

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.

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.

The only feature that appears to require JavaScript is search.

    const binary = Uint8Array.fromBase64(
        "AGFzbQEAAAABBgFgAX8BfwMCAQAHBgECeDIAAAoJAQcAIABBAmwL"
    );
    const module = new WebAssembly.Module(binary);
    const instance = new WebAssembly.Instance(module, {});
    console.log(instance.exports.x2(3));

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.

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

Nowadays: Electron slop that will also eat a bunch of their RAM.

Personally I think that’s due to the failure of native development properly taking off: you know, actually being good and easy instead of a long line of dead or half dead attempts; alongside platform vendors hating each other and each having a vastly different GUI framework instead of some inter-OS WG to come up with at least good common standards.

Imagine if you could ship your desktop app in a natively running virtual machine, that is as perfect as it gets from sandboxing code and running a lightning fast JIT compiler instead of virtualization. It delivers a common user experience, digital accessibility, endless customization while being secure, it's free for developers and users, constantly updated and it delivers an absurdly powerful, while also perfectly printable markup and styling engine.

That's what a browser is. Your apps are native.

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 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.

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.