[HN Gopher] Dead Framework Theory
___________________________________________________________________
Dead Framework Theory
Author : jhuleatt
Score : 99 points
Date : 2025-11-07 03:17 UTC (19 hours ago)
(HTM) web link (aifoc.us)
(TXT) w3m dump (aifoc.us)
| gibbitz wrote:
| This is the AI apocalypse. Not AI nuking us, but nuking choice.
| grebc wrote:
| Just write some code that uses your preferred framework?
| miohtama wrote:
| It matters if one cannot write code.
| grebc wrote:
| Ask your wizard to use a different framework?
| Cthulhu_ wrote:
| Nothing different then - before AI it would have been search
| engines or social networks / upvotes of the masses.
|
| The common factor is the reader, taking what the search engine,
| SO commenter or AI takes as gospel. A good software developer
| can judge multiple inputs on their own.
|
| And if someone doesn't care what an AI does it really isn't
| important what they are having it build or what tool it uses,
| clearly.
| add-sub-mul-div wrote:
| That was depressing as shit.
| tow21 wrote:
| On the plus side, maybe this means the endless churn of JS
| libraries will finally slow down and as someone who isn't a JS
| developer but occasionally needs to dip their toe into the
| ecosystem, I can actually get stuff done without having to worry
| about 6-month old tutorials being wrong and getting caught in
| endless upgrade hell.
| grebc wrote:
| For what it's worth - vanilla JS is pretty darn good and if
| you're only dipping in for some small functionality I highly
| doubt a framework brings much benefit.
| jfengel wrote:
| I find vanilla JS unusable for anything bigger, though. It
| was designed for quickie scripts on throwaway web pages, but
| it's not great for anything you'd call a web app.
|
| Typescript, however, does scale pretty well. But now you've
| added a compiler and bundler, and might as well use some
| framework.
| andrewl-hn wrote:
| Has this actually been true, though? I admit I don't write
| JavaScript much recently, but to me it feels like things have
| pretty stabilized. React released hooks in early 2019 before
| Covid, and after that things don't really change much at all.
|
| At this point there are several large Rust UI libraries that
| try to replicate this pattern in web assembly, and they all had
| enough time to appear and mature without the underlying
| JSX+hooks model becoming outdated. To me it's a clear sign that
| JS world slowed down.
| xerox13ster wrote:
| Yes. When I dipped my toes into the front end ecosystem in
| 2021 to build a portfolio site, the month old tutorial video
| I followed, was already out of date. React had released an
| update to routers and I could not find any documentation on
| it. Googling for the router brought me to pages that said to
| do what I had done, which disagreed with the error message
| that I was getting from react.
|
| React had just updated and documentation hadn't.
|
| I then discovered that Meta owns React so I got frustrated as
| hell with their obfuscation and ripped out all of the React
| and turned what was left into vanilla html+js.
| sesm wrote:
| React-router is it's own separate project not affiliated
| with Meta. React library doesn't ship a router.
| xerox13ster wrote:
| Yet at the time it seemed to need one. Glad I never
| looked back at that fragmented mess.
|
| I also don't 'KTH-Trust' Meta of all corporations to have
| a compile step for a web technology.
| williamdclt wrote:
| > React released hooks in early 2019 before Covid, and after
| that things don't really change much at all.
|
| Server-side components became a thing, as well as the React
| compiler. And libraries in the React (and JS at large)
| ecosystem are pretty liberal with breaking changes, a few
| months is enough to have multiple libraries that are out-of-
| date and whose upgrade require handling different breaking
| changes.
|
| React Native is it own pit of hell.
|
| It did slow down a little since a few years ago, but it's
| still not great.
| simonw wrote:
| The argument here is that React has permanently won because LLMs
| are so heavily trained on it and default to it in their answers.
|
| I don't buy this. The big problem with React is that the
| compilation step is almost required - and that compilation step
| is a significant and growing piece of friction.
|
| Compilation and bundling made a lot more sense before browsers
| got ES modules and HTTP/2. Today you can get a long way without a
| bundler... and in a world where LLMs are generating code that's
| actually a more productive way to work.
|
| Telling any LLM "use Vanilla JS" is enough to break them out of
| the React cycle, and the resulting code works well and,
| crucially, doesn't require a round-trip through some node.js
| build mechanism just to start using it.
|
| Call me a wild-eyed optimist, but I'm hoping LLMs can help us
| break free of React and go back to building things in a simpler
| way. The problems React solve are mostly around helping
| developers write less code and avoid having to implement their
| own annoying state-syncing routines. LLMs can spit out those
| routines in a split-second.
| jq_2023 wrote:
| what about the value of abstraction to readability and
| maintainability? Do you really want to be stuck with
| debugging/upgrading and generally working with such low level
| vanilla js code when elegant abstractions are so much more
| efficient ?
| Fire-Dragon-DoL wrote:
| To be fair, React is a very leaky abstraction, I wouldn't
| define it "elegant". It does work at simplifying things for
| certain usecases though
| simonw wrote:
| I've been leaning more on web components as an abstraction
| here, once an LLM can take care of their boilerplate they're
| a pretty nice way to modularize frontend code.
| t8sr wrote:
| Abstraction for its own sake, especially with js frameworks,
| doesn't make anything more readable or maintainable. React
| apps are some of the most spaghetti style software I've ever
| seen, and it takes like 10 steps to find the code actually
| implementing business logic.
| bottd wrote:
| Do they do this notably worse than say a Spring boot API or
| a Vue frontend? I don't think this is a React thing. Those
| spaghetti projects would be so with or without React.
| jfengel wrote:
| Some of that is the coding standards rather than the
| framework. I think Dan Abramov did a hang-up job on React,
| but his naming conventions and file structure are deranged.
|
| Unfortunately there isn't any one preferred alternative
| convention. But if you ignore his and roll your own it will
| almost certainly be better. Not great for reading other
| people's code but you can make your own files pretty clear.
| acemarke wrote:
| What "naming conventions and file structures" are you
| referring to? I don't think Dan ever really popularized
| anything like that for _React_.
|
| If you're thinking of _Redux_, are you referring to the
| early conventions of "folder-by-type" file structures? ie
| `actions/todos.js`, `reducers/todos.js`,
| `constants/todos.js`? If so, there's perfectly
| understandable reasons why we ended up there:
|
| - as programmers we try to "keep code of different kinds
| in different files", so you'd separate action creator
| definitions from reducer logic
|
| - but we want to have consistency and avoid accidental
| typos, especially in untyped plain JS, so you'd extract
| the string constants like `const ADD_TODO = "ADD_TODO"`
| into their own file for reuse in both places
|
| To be clear that was never a requirement for using Redux,
| although the docs did show that pattern. We eventually
| concluded that the "folder-by-feature" approach was
| better:
|
| - https://redux.js.org/style-guide/#structure-files-as-
| feature...
|
| and in fact the original "Redux Ducks" approach for
| single-file logic was created by the community just a
| couple months after Redux was created:
|
| - https://github.com/erikras/ducks-modular-redux
|
| which is what we later turned into "Redux slices", a
| single file with a `createSlice` call that has your
| reducer logic and generates the action creators for you:
|
| - https://redux.js.org/tutorials/essentials/part-2-app-
| structu...
| xnx wrote:
| I share your optimism. Once you move up a conceptual layer
| (from writing code to guiding an LLM), the lower level almost
| becomes interchangeable. You can even ask the LLM to translate
| from one language/framework to another.
| kinlan wrote:
| Author here. Fwiw this is my hope too. I wrote about
| something similar in the past https://paul.kinlan.me/will-we-
| care-about-frameworks-in-the-...
| dangus wrote:
| I also think the pitfall that might exist here is the base
| assumption that developers are allowing the LLMs to make
| architecture decisions either not addressing the issue at all
| and just prompting for end results or not making the choice
| before asking the LLM.
|
| E.g., if most developers are telling their LLMs "build me a
| react app" or "I want to build a website with the most popular
| framework," they were going to end up with a react app with or
| without LLMs existing.
|
| I'm sure a lot of vibecoders are letting Jesus take the wheel,
| but in my vibecoding sessions I definitely tend to have some
| kind of discussion about my needs and requirements before
| choosing a framework. I'm also seeing more developers talking
| about using LLMs with instructions files and project
| requirement documents that they write and store in their repo
| before getting started with prompting, and once you discover
| that paradigm you don't tend to go back.
| akst wrote:
| _I'm gonna narrow in on the bit about compilation steps_.
|
| Anyone shipping production code will one way of another have
| some kind of build step, whether that's bundling, minification,
| typechecking, linting, finger printing files, etc. At that
| point it makes little difference if you add a build step for
| compilation.
|
| I'm sympathetic to not wanting to deal with build processes I
| try to avoid them where I can in my side projects. The main web
| project I've been working on for the last year has no build
| step, uses Vanilla JS & web components. But it's also not a
| consumer facing product.
|
| I think there's friction for sure, but I just can't see this
| being an issue for most cases where a build step is already in
| place for other concerns. And Developers are fairly familiar
| with build steps especially if you do anything outside the web
| in C/C++ or Java/C# or Rust or whatever.
| aatd86 wrote:
| For release but not for development. Sufficient for the build
| step to take a long time and you start to notice the
| friction. The web/browser should not rely on bundlers and
| compilation steps overall. This should remain optional.
| bottd wrote:
| Hot reloading is pretty common now for React or other
| JavaScript projects
| MrJohz wrote:
| Hot-reloads in a modern bundler like Vite will typically be
| instantaneous. Normally in development, only dependencies
| are bundles, and the files you write are served as-is
| (potentially with a per-file compilation step for e.g. jsx
| or TypeScript). That means that when you save a file, the
| bundler will run the compiler over that single file, then
| notify the hot-reload component in the browser to re-fetch
| it. That would be quick even if it were done in JavaScript,
| but increasingly bundlers use parts with in Go or Rust to
| ensure that builds happen every more quickly.
|
| If you've got a huge project, even very quick bundlers will
| end up slowing down considerably (although hot reload
| should still be pretty quick because it still just affects
| individual files). But in general, bundlers are pretty damn
| quick these days, and getting even quicker. And of course,
| they're still fully optional, even for a framework like
| React.
| lmm wrote:
| > The big problem with React is that the compilation step is
| almost required - and that compilation step is a significant
| and growing piece of friction.
|
| Having a build step more than pays for itself just in terms of
| detecting errors without having to execute that codepath. The
| friction is becoming less and less as the compilation step is
| increasingly built into your project/dependency management tool
| and increasingly faster (helped by the trend towards Rust or Go
| now that the required functionality is relatively well-
| understood)
|
| > The problems React solve are mostly around helping developers
| write less code and avoid having to implement their own
| annoying state-syncing routines. LLMs can spit out those
| routines in a split-second.
|
| An LLM can probably generate the ad hoc, informally-specified,
| bug-ridden, slow implementation of half of React that every
| non-React application needs very quickly, sure. But can the LLM
| help you comprehend it (or fix bugs in it) any faster? That's
| always been the biggest cost, not the initial write.
| t8sr wrote:
| The problem with React apologetics is that you need to only
| take a cursory look at literally every production app written
| in React to see it's terrible and must be abandoned in the
| long-term.
|
| To see how fast a properly engineered app can be if it avoids
| using shitty js frameworks just look at fastmail. The
| comparison with gmail is almost comical: every UI element
| responds immediately, where gmail renders at 5 fps.
| procaryote wrote:
| > [most used web framework, powering innumerable successful
| businesses]
|
| > [literally unusable]
|
| > [one of the most successful web apps]
|
| > [look at how bad it is]
|
| Your standards might be uncalibrated with reality
|
| I use gmail every day and it's fine, apart from when they
| push AI features I don't want, but I can't blame that on
| the framework
| t8sr wrote:
| My friend, it renders at 15 fps on a literal
| supercomputer. It takes 30 seconds to load. The time
| between clicking a button and something happening is
| measured in seconds. It may be successful, but it is not
| good.
|
| The problem is that you've (and we all have) learned to
| accept absolute garbage. It's clearly possible to do
| better, because smaller companies have managed to build
| well functioning software that exceeds the performance of
| Google's slop by a factor of 50.
|
| I'm not saying RETVRN to plain JS, but clearly the horrid
| performance of modern web apps has /something/ to do with
| the 2 frameworks they're all built on.
| procaryote wrote:
| Our experiences of gmail are very different.
| tehbeard wrote:
| > Takes 30 seconds to load.
|
| Tried a cleared cache load, open and usable in 3 seconds,
| loading my work inbox which is fairly busy and not clean.
|
| I'm not sure what FPS has to do with this? Have you some
| sort of fancy windows 11 animations extension installed
| that star wipes from inbox to email view and it's
| stuttering??
|
| I click and email it shows instantly, the only thing
| close to "low FPS" is it loads in some styles for a
| calendar notification and there's a minor layout shift on
| the email.
|
| What / how are you using it that you apparently get such
| piss poor performance?
| array_key_first wrote:
| Well yeah, most software is bad. In fact it's so bad
| that's its almost unbelievable.
|
| We're all used to it and that's fine. But it's still bad.
| We're still wasting, like, 10,000x more resources than we
| should to do basic things, and stuff still only works,
| like, 50% of the time.
| ASalazarMX wrote:
| GMail is becoming the Lotus Notes of the 21st century. It
| uses half a gigabyte of RAM, for evey tab. God forbid you
| need to handle several accounts, i.e., for monitoring
| DMARC reports across domains.
|
| And IT IS SLOW, despite your experience, which is highly
| dependant on how much hardware can you throw at it.
| SomeUserName432 wrote:
| > I use gmail every day and it's fine
|
| The past couple of weeks I've been having loading times
| up to 1 minute to open gmail.
|
| No idea what they are up to. Loading google workshop or
| something like that, takes eons.
| eyeris wrote:
| When did gmail migrate to react?
| yakshaving_jgt wrote:
| If you must have a build step, then why use JavaScript?
| alehlopeh wrote:
| Lots of possible answers here but I'll go with DOM bindings
| yakshaving_jgt wrote:
| That's not part of the language.
| bottd wrote:
| If you wanna access DOM you can't avoid JavaScript
| yakshaving_jgt wrote:
| That's not _quite_ true. There are a number of languages
| which compile to JavaScript, _e.g._ , Elm, and provide an
| API for interacting with the DOM, as well as some kind of
| FFI.
| Wowfunhappy wrote:
| Couldn't you use WebAssembly? I think (?) GP's point is
| that it would make more sense to use a different language
| that compiles to WebAssembly. (Or transpile to Javascript
| I guess, but I don't know why you'd do that.)
| saulpw wrote:
| With WASM, you still have to have a JS layer that
| interacts with the DOM. WASM can't touch the DOM by
| itself, it can only communicate with JS.
| WorldMaker wrote:
| WebAssembly still doesn't have direct DOM bindings.
| That's at least two levels deeper and several more
| standards to go after the very basic Wasm GC that was
| only just recently standardized. For the moment you
| basically have an FFI/IPC bridge that you can send
| TypedArray buffers and attempt to UTF-8 decode them and
| then JSON.parse that on the JS side. (We don't even have
| _strings_ agreed upon yet, mostly just arrays of bytes.
| Wasm Strings is a possible standard still in the
| process.)
|
| Anyone doing serious HTML rendering with WebAssembly
| today A) _has a build step_ , B) still has a bunch of JS
| to do memory buffer FFI/IPC and decoding/encoding, C) is
| usually using some form of Virtual DOM in the Wasm side
| and the JS side is some version of JSON-driven
| React/Preact-Lite. It is not today more efficient than
| React's build process nor React's runtime experience.
| hresvelgr wrote:
| While I tend to agree, I think there's still an undercurrent of
| React-like paradigms being strongly preferenced in the training
| data so assuming LLMs continue to get much better, if you were
| to build a simple UI toolkit with an LLM, there's a strong
| chance that over time with accretion you will end up remaking
| React or any one other framework unless you're particularly
| opinionated about direction.
| kinlan wrote:
| Fwiw - I'm hoping it can break out too. But one of the biggest
| challenges is that last bit "asking it to use vanilla JS" -
| unsee this all the time in developer relations: getting
| developers to ask for a specific thing or even have it on their
| mind to think about using it is one of the biggest hurdles.
|
| My actual long term hope is that in the future we won't need to
| think about frameworks at all: https://paul.kinlan.me/will-we-
| care-about-frameworks-in-the-...
| simonw wrote:
| > Frameworks are abstractions over a platform designed for
| people and teams to accelerate their teams new work and
| maintenance while improving the consistency and quality of
| the projects. [...] I was just left wondering if there will
| be a need for frameworks in the future? Do the architecture
| patterns we've learnt over the years matter? Will new
| patterns for software architecture appear that favour LLM
| management?
|
| Yes! That's exactly what I was trying to get at.
| port11 wrote:
| Maybe in a distant future, but why are so obsessed with the
| anti-framework sentiment? We don't shy away from a framework
| when coding in Node, PHP, Java...
|
| Is there something about the web -- with its eternal
| backwards compatibility, crazy array of implementations, and
| 3 programming languages -- that seems like it's the ideal
| platform for a framework-free existence?
|
| Maybe if we bake all of the ideas into JavaScript itself, but
| then where does it stop? Is PHP done evolving? Does Java, by
| itself, do everything as well as you want out of Spring?
| jemmyw wrote:
| I'm actually surprised that jsx hasn't made it's way into the
| standard yet. That still seems a more likely outcome than react
| going away.
| aatd86 wrote:
| jsx is not really needed. We have templates. Besides it
| really is a dsl with a weird syntax. I'm doubtful it will
| ever become an ES standard. And for good reasons. That should
| be left to the different frameworks to handle.
| Bolwin wrote:
| Templates are horribly limited compared to the free mixing
| of js and markup Jsx gives you
| aatd86 wrote:
| If you use them raw, yes. They are just the building
| block you can build upon. And that's a really good
| building block. You can create your own parsers. I am
| doing exactly this for a framework that has yet to be
| released, full disclosure. Makes html clearly html, and
| javascript fully javascript. No bastardization of either
| one into a chimera. And the junction of the two is why
| the custom parser is required. But it is really light
| from a dev experience.
| recursive wrote:
| JSX is syntax only with no defined behavior. Which standard
| would it make it into? HTML and javascript specs define
| syntax AND semantics.
|
| I sincerely doubt that either of JSX's syntax or its
| semantics under React's transforms would make it into a W3 or
| WHAT spec as they exist today.
| WorldMaker wrote:
| The direct semantics of JSX are "transform this syntax into
| this nested sequence of function calls and this layout of
| arguments". That's been the case since nearly the
| beginning. The only real semantics
| "fights"/"changes"/"React-specifics" you can see in the
| compiler options in Babel and Typescript: what the function
| is named and how do you import it. Enough other libraries
| that aren't React use JSX that it is easy to see what the
| generic approach looks and find ideas for runtime
| configuration of "jsx function name" and an import strategy
| that isn't just "import these hardcoded names from these
| hardcoded React modules".
| MrJohz wrote:
| > The direct semantics of JSX are "transform this syntax
| into this nested sequence of function calls and this
| layout of arguments".
|
| Not exclusively. SolidJS, for example, transforms the
| syntax into string templates with holes in them. The
| "each element is a function call" approach works really
| well if those calls are cheap (i.e. with a VDOM), but if
| you're generating DOM nodes, you typically want to group
| all your calls together and pass the result to the
| browser as a string and let it figure out how to parse
| it.
|
| For example, if you've got some JSX like:
| <div> <div> <span>{text}</span>
| <div> <div>
|
| You don't want that to become nested calls to some
| wrapper around 'document.createElement`, because that's
| slow. What you want is to instead do something like
| const template = parseHtml(` <div>
| <div> <span></span> <div>
| <div> `);
| template.children[0].children[0].innerText = text
|
| This lets the browser do more of the hard parsing and
| DOM-construction work in native code, and makes
| everything a lot more efficient. And it isn't possible if
| JSX is defined to only have the semantics that it has in
| React.
| recursive wrote:
| > You don't want that to become nested calls to some
| wrapper around 'document.createElement`, because that's
| slow.
|
| It's really not slow. It might seems slow if you're using
| react behavior which re-invokes the "render function" any
| time anything changes. But eventually they get reconciled
| into the DOM which creates the elements anyway. And most
| other code bases are not based on this reconciliation
| concept. So I don't think that's a given.
| recursive wrote:
| No. You're thinking of how React uses it.
|
| The library [0] _I_ wrote that uses JSX converts
| expression attributes into parameter-less lambdas before
| providing them as function parameters or object
| properties. This is a different behavior than react 's
| build tools or any of typescripts jsx options. But it's
| not inconsistent with the spec.
|
| [0] https://mutraction.dev/
| SahAssar wrote:
| It sorta was, even before jsx:
| https://en.wikipedia.org/wiki/ECMAScript_for_XML
| mexicocitinluez wrote:
| > The argument here is that React has permanently won because
| LLMs are so heavily trained on it and default to it in their
| answers.
|
| I can't find the author making that argument. Can you point to
| where they're declaring that React has permanently won?
|
| > The big problem with React is that the compilation step is
| almost required - and that compilation step is a significant
| and growing piece of friction.
|
| This is orthogonal to what the article is addressing.
|
| > Call me a wild-eyed optimist, but I'm hoping LLMs can help us
| break free of React and go back to building things in a simpler
| way
|
| If you didn't read the article, I think you should. Because
| this is generally the conclusion that the author comes to. That
| in order to break out of React's grip, LLM's can be trained to
| use other frameworks.
| simonw wrote:
| > If the industry continues its current focus on
| maintainability and developer experience, we'll end up in a
| world where the web is built by LLMs using React and a
| handful of libraries entrenched in the training data.
| Framework innovation stagnates. Platform innovation focuses
| elsewhere. React becomes infrastructure--invisible and
| unchangeable.
|
| So I guess I'm in agreement with the author: let's actively
| work to make that not happen.
| mexicocitinluez wrote:
| Agreed. I've been using React as the front-end for a few
| years now and while I enjoy it, I really, really don't want
| React to be the only option.
| jbs789 wrote:
| Yup. The central argument seems to include an assumption that
| LLMs will be the same tomorrow as today.
|
| I'd note that people learn and accumulate knowledge as new
| languages and frameworks develop, despite there being
| established practices. There is a momentum for sure, but it
| doesn't preclude development of new things.
| majewsky wrote:
| Not quite. The central argument is that LLMs tomorrow will be
| based on what LLMs output today. If more and more people are
| vibe-coding their websites, and vibe-coding predominantly
| yields React apps, then the training data will have an ever
| larger share of React in it, thus making tomorrow's LLMs even
| more likely to produce React apps.
| victorbjorklund wrote:
| yea, and models now are so good the difference between writing
| react or svelte code is moot. maybe 2 years ago choosing react
| just because an LLM would be better at it would make sense but
| not today.
|
| (For the AI-sceptics, you can read this as models are equally
| bad at all code)
| Wowfunhappy wrote:
| I think a more interesting (and significant) question is
| whether there can ever be a new programming language.
|
| Like, if you really believe that in the future 95% of code will
| be written by LLMs, then there can never be a Python 4, because
| there would be no humans to create new training data.
|
| To me, this is evidence that LLMs _won't_ be writing 95% of
| code, unless we really do get to some sort of mythical "AGI"
| where the AI can learn entirely from its own output and improve
| itself exponentially. (In which case there would still wouldn't
| be a Python 4, it would be some indecipherable LLM speak.) I'll
| believe that when I see it.
| simonw wrote:
| My hunch is that existing LLMs make it _easier_ to build a
| new programming language in a way that captures new
| developers.
|
| Most programming languages are similar enough to existing
| languages that you only need to know a small number of
| details to use them: what's the core syntax for variables,
| loops, conditionals and functions? How does memory management
| work? What's the concurrency model?
|
| For many languages you can fit all of that, including
| illustrative examples, in a few thousand tokens of text.
|
| So ship your new programming language with a Claude Skills
| style document and give your early adopters the ability to
| write it with LLMs. The LLMs should handle that very well,
| especially if they get to run an agentic loop against a
| compiler or even a linter that you provide.
| dotemacs wrote:
| Isn't that what Geoff did: https://ghuntley.com/cursed/
|
| OK, it wasn't a Claude Skill, but it was done using Claude.
| simonw wrote:
| That's slightly different - that's draining and
| implementing a new language from scratch, not just using
| LLMs to help onboard new language users.
|
| That said, part of what he did with Cursed was get LLMs
| to read its own documentation and use that to test and
| demonstrate the language.
| gmuslera wrote:
| It is not pseudocode? It doesn't have to be something with
| strict syntax or very limited keywords, but maybe the
| compiler/linter (llm) could point out when you are being
| ambiguous or not defining how something should be done if
| several alternatives are possible.
| zarzavat wrote:
| > React is that the compilation step is almost required - and
| that compilation step is a significant and growing piece of
| friction.
|
| As a recovering C++ programmer the idea that a basically
| _instant_ compilation step is a source of friction is
| hysterical to me.
|
| Try waiting overnight for a build to finish. Frontend devs
| don't know they're born. It takes like 5 minutes to set up
| vite.
| port11 wrote:
| Exactly, and I wouldn't miss a chance to give React some
| crap; when I was learning Java or Swift, the compilation
| times seemed horrendous. Web developers have it very good
| with fast incremental compilation, hot reload, etc.
| pbalau wrote:
| There is an extra thing that the people complaining about the
| compilation step in react are missing: using c++, for
| example, if you find an issue, you have to fix the issue,
| rebuild the thing, then run the thing and *do all the steps
| required to get your state to duplicate the issue*, just to
| check you fixed the issue. With react and the other js
| inspired frameworks and adjacent tooling, you just have to
| save the file.
| brazukadev wrote:
| > With react and the other js inspired frameworks and
| adjacent tooling, you just have to save the file.
|
| React and TS people are making sure that is not the case
| anymore, allegedly for our own benefit.
| MrJohz wrote:
| With a bundler like Vite or TSX (not the same as the .tsx
| file extension), you really do just save the file, and
| everything reloads, usually instantaneously. That said,
| TS is now supported by default in NodeJS, Deno, and Bun,
| so if you're doing server-side stuff, you probably don't
| need a bundler at all, at least for development.
| brazukadev wrote:
| ESM is good enough that vite is not necessary anymore,
| typescript never was but it won't take longer for some
| people to come gaslit anybody not claiming it is the best
| thing to ever happen to web development.
| lunias wrote:
| Yeah, I agree. I always ask it to use Vue.js and it always
| gives me Vue.js.
| nothinghere789 wrote:
| I don't buy it either. The reality is that the people who do
| hiring don't understand the problems they are working on and
| which tech stack is appropriate. They might not understand or
| even like React, but they are going to pick it because they
| know that they can hire other people who understand it. We will
| end up with lots of projects in 5-10 years where people will
| ask "why the hell did you use React for this?" ....actually
| thats the reality now!
| timinou wrote:
| I don't buy it either. I've been building my own backend
| framework for the past 2.5 years, and even though it's a DSL over
| Python and there's no documentation online and barely one in my
| computer, Claude Code understands it with enough usage examples
| in my codebase.
|
| In front-end as well--I've been able to go much farther for
| simple projects using alpine than more complex frameworks. For
| big products I use Elm, which isn't exactly the most common
| front-end choice but it provides a declarative programming style
| that forces the LLM to write more correct code faster.
|
| In general, I think introspectible frameworks have a better case,
| and whether they're present in training data or not becomes more
| irrelevant as the introspectibility increases. Wiring the Elm
| compiler to a post-write hook means I basically have not written
| front-end code in 4 or 5 months. Using web standards and micro
| frameworks with no build step means the LLM can inspect the
| behaviour using the chrome dev tools MCP and check its work much
| more effectively than having to deal with the React loop. The
| ecosystem is so fragmented there, I'm not sure about the "quality
| because of quantity of training data" argument.
| kinlan wrote:
| Author here. This is a fair comment. If you have a corpus that
| can be used as context already it's not like the LLMs will be
| forcing you in to React, there's probably enough bias (in a
| good way) to ensure the tool continues to be useful.
|
| What I was trying to get at in the post is that net new
| experiences is where I see a massive delta
| timinou wrote:
| Yeah for sure but I think frameworks will adapt. It's like
| going back to 2002 and saying that it's better to program in
| Java because of all the IDEs available and all the corporate
| money being poured into having the best developer experience
| there can be. But since LSP arrived, developers choosing a
| smaller language suffer much less.
|
| The 'LSP' that would allow new frameworks or languages to
| shine with coding agents is already mostly here, and it's
| things like hooks, MCPs, ACP, etc. They keep the code
| generation aligned with the final intent, and syntactically
| correct from the get go, with the help of very advanced
| compilers/linters that explain to the LLM the context it's
| missing.
|
| That's without hypothesising on future model upgrades where
| fine-tuning becomes simple and cheap, local, framework-
| specific models become the norm. Then, React's advantage (its
| presence in the training data) becomes a toll (conflicting
| versions, fragmented ecosystem).
|
| I also have a huge bias against the javascript/typescript
| ecosystem, it gives me headaches. So I could be wrong.
| miffy900 wrote:
| I feel like there could be a loophole here for the new-framework-
| author. Stick to using JSX for the view; JSX is just syntax sugar
| for built in react functions for constructing a tree, which can
| be easily swappable with your own implementation. I recall years
| ago using a babel plugin that just emitted static HTML from JSX.
| I know Vue.js v2 also had JSX support that way.
|
| I think LLMs, despite already being trained massively on React,
| can easily adapt their output to suit a new framework's-specific
| API surface with a simple adjustment to the prompt. Maybe include
| an abbreviated list of type/function signatures that are specific
| to your new framework and just tell the LLM to use JSX for the
| views?
|
| What I think will definitely be a challenge for new library
| authors in the age of LLMs is state management. There are already
| tons of libraries that basically achieve the same thing but have
| vastly different APIs. In this case, new lib-authors may be
| forced to just write pluggable re-implementations of existing
| libraries just to enable LLMs to emit compilable/runnable code.
| Though I dont know of any state management library that dominates
| the web like React does with the view layer.
| kinlan wrote:
| Huh - that's actually pretty interesting and I hadn't thought
| of that as an option.. I know Preact was built as a faster
| alternative while being broadly compatible, but what you are
| describing is maybe even blending the technologies as that
| short circuit. neat.
| recursive wrote:
| > Stick to using JSX for the view
|
| That's what I did. https://mutraction.dev/
|
| My framework has approximately zero users and this is not a
| plug, but the idea is sound and it works.
| contrarian1234 wrote:
| I'm not really sure why this focuses so much on React, when it's
| a general "issue"/"feature"
|
| More broadly, obviously there is some pressure to use a
| framework/library/programminglang/editor that has better LLM
| training. But even before LLMs.. you'd want to choose the one
| that has more SO questions, more blog posts and books published
| about it. The one where you can hire experienced programmers.
|
| New players has a certain activation energy they need to overcome
| - which is probably good. B/c it slows down the churn of new
| shiny with incrementally improvements. I think a paradigm shift
| is sufficient though. Programmers like new shiny things -
| especially the good ones that are passionate about their craft
| kinlan wrote:
| I used it as an example because I felt the data was pretty
| clear. I also felt that it follows a very human pattern
| (generative tools need customers, like other tools before, so
| they go with what the industry is demanding).... but now we
| seen an acceleration.
| Incipient wrote:
| I find pretty much all models in vscode decent enough on
| Vue+Quasar. The fact they make bad choices I don't blame on them
| not understanding Vue.
|
| I absolutely wouldn't be swapping because the output 'isn't good
| enough'.
| gdulli wrote:
| And while the bulk of the internet stagnates into mediocrity is
| there a competitive advantage for people who never let their
| actual skills dull?
| dangus wrote:
| Maybe, or maybe not. Is a welder valuable to Ford Motor Company
| if all their welders are robots?
| Cthulhu_ wrote:
| Sure. Is there a competitive advantage to people who know COBOL
| and never bothered to learn Java?
|
| At the moment I still consider it a tool alongside all other
| tool, or else a business strategy next to e.g. outsourcing. My
| job didn't go away because there's 1000x more of them overseas.
| But likewise, it also didn't go away because there's
| individuals 1000x better (educated, developed, paid, connected)
| than me in the US.
| raincole wrote:
| Thanks god. The days people kept inventing new JS frameworks or
| even dialects (coffeescript, remember?) every three months
| couldn't be gone fast enough.
| DemocracyFTW2 wrote:
| Shoutout to CoffeeScript!
| Cthulhu_ wrote:
| Coffeescript was great though, because at the time Javascript
| was growing fast but the language was developing slowly or not
| at all. There was also Atscript for a little while which added
| annotations because Typescript didn't want to add them; they
| eventually budged and Atscript was dead. Then there was a fork
| of Node because Node at the time was still tightly controlled
| by Joyent, whereas its fork (io.js or js.io or something) was
| an open governance model. It was eventually merged back into
| node.
|
| TL;DR sometimes you need to make an alternative to get the
| original to move.
| throw_m239339 wrote:
| > Thanks god. The days people kept inventing new JS frameworks
| or even dialects (coffeescript, remember?) every three months
| couldn't be gone fast enough.
|
| Coffeescript helped Javascript to evolve the right way, so in
| retrospect, it was absolutely a good thing. It's like people
| here don't remember the days of ES3 or ES5...
|
| And the days? Remember Typescript right now? Typescript is not
| Javascript.
| recursive wrote:
| One of the guiding principles of typescript is that its
| semantics should be consistent with ES. This was not the case
| for coffeescript. I think TS is doing it the right way.
| sshine wrote:
| I embraced this when I had the same realisation that React will
| get reinforced the most, and vibe-coded something in it.
|
| I had to ditch the whole thing and rewrite it in Vue when it got
| big enough that I couldn't debug it without learning React.
|
| Vibe-coding something in a stack you know or want to know means
| you can get off your high horse and peek into the engine.
|
| I still agree with the sentiment that React is winning; if the
| competition of volume. But other frameworks won't stop existing
| unless you believe that people exclusively choose what is
| dominant. But there will always be artisans, even after all old
| people who learned the alternatives were flushed out.
| renewiltord wrote:
| LLMs are great at HTMX and Python. Both Claude Code and Codex do
| well at it so I'm fine with things like that. React is fine but
| HTMX does well. I also frequently used to copy Claude's generated
| React things into ChatGPT and ask it to rewrite them in Vanilla
| JS and it would work but that was a year ago when artifacts were
| just being launched.
| righthand wrote:
| You could always write some code in a different framework and
| help spread around other types of reusable template frameworks.
| Like in XSLT for example...oh wait... that's been killed off too.
| procaryote wrote:
| If this gets me out of the "This framework that almost everyone
| uses and is easy to hire for and that works well for a lot of
| people is _literally unusable_ compared to this new hot framework
| I fell in love with recently! We need to rebuild everything!
| "-discussion, I'm fine with it
|
| I try to filter out such people in hiring nowadays but sometimes
| you miss, or come into an existing team with these issues
| the_gipsy wrote:
| Why make all these graphs to show that react is dominating, which
| we already know, to make a guess?
|
| Should have made graphs testing LLMs with different frameworks.
| jnewt wrote:
| yup, patterns due to llms may alter languages and preferential
| bits quite a bit
| bubblyworld wrote:
| I don't buy it, I've used LLMs (well, mostly sonnet 4.5 and
| sometimes gpt5) in a variety of front-end frameworks (react, vue,
| htmx) and they do just fine. As usual, requires a lot of
| handholding and care to get good results, but I've found this is
| true for react codebases just as much as anything else.
| mexicocitinluez wrote:
| > I don't buy it, I've used LLMs (
|
| You don't buy what, exactly?
|
| > As usual, requires a lot of handholding and care to get good
| results, but I've found this is true for react codebases just
| as much as anything else.
|
| I think you and others in this thread have either just skimmed
| the article or just read the headline. The point isn't that you
| can't use LLMs for other languages, its that the creators of
| these tools AREN'T using other languages for them. Yes, LLM's
| can write Angular. But if there's less data to train on, the
| results won't be as good. And because of this, it's creating a
| snowball effect.
| hu3 wrote:
| Not your parent commenter but their point was clear to me.
|
| To me, they don't buy the argument that the snowball effect
| is significant enough to overcome technical merits of
| different frontend frameworks.
|
| And I'll add that: older libraries like React have at least
| one disavantage: there's a lot of outdated React code out
| there that AI is being trained on.
| mexicocitinluez wrote:
| That makes sense.
|
| > there's a lot of outdated React code out there that AI is
| being trained on.
|
| Yea, but that's better than no code as far as an LLM is
| concerned, which is what this article is about.
| hu3 wrote:
| Fair, but when the alternative is something like Svelte,
| there's a lot of new code for AI to train.
|
| And specifically Svelte has their own MCP to help LLMs
| https://svelte.dev/docs/mcp/overview
|
| I wonder if React has something to keep AI on their toes
| about best practices.
| mexicocitinluez wrote:
| > I wonder if React has something to keep AI on their
| toes about best practices.
|
| Ahh, I wouldn't hold my breath.
|
| And to your point, I guess another thing Svelte has is
| it's compatibility with just vanilla JS, meaning (I
| think) it doesn't necessarily have to be "Svelte" code to
| still work with Svelte.
| iso1631 wrote:
| And in the future there will be a lot of AI generated react
| code that future AI trains on
| phplovesong wrote:
| So its going to be just like jquery. Never really dying fully.
| Kwpolska wrote:
| A blog named "AI Focus" is of course going to push LLMs and vibe
| coding. But here in the real world, people can still code without
| LLMs, or use them with a human in control, where the LLM can look
| at existing code written in a framework that is not React.
|
| Also, React was extremely popular before any LLMs were out there.
| I would not ascribe much of the growth to vibe coding.
| kinlan wrote:
| Just to push back on this a tad. Yes there's growth React, it's
| popular, but it was consistent up until the introduction of
| some of the more popular code generation tools where there is a
| clear acceleration (if you believe builtwith.com data) in the
| last 9 months or so.
| jillesvangurp wrote:
| As LLMs improve, it matters less what they are trained on and
| more what they understand. I've used codex on some very obscure
| code bases and frameworks. It's fine. It understands them. It
| broadly does the right things. It can understand from examples in
| your code how to use things. To give you one example, I'm using
| an obscure framework called fritz2 with kotlin-js. Kotlin-js is
| not that widely used. And I'm probably one of a handful of active
| users of this Fritz2 framework in the world. There isn't a whole
| lot of code to train on. And what little there is is probably a
| bit outdated.
|
| It's fine. I've been using codex on some code bases with this
| with pretty alright results. I also use codex to generate
| typescript/react code. I'm getting similar results. I had a
| little wow moment when I asked it to add some buttons and then
| afterwards realized that it had figured out the localization
| framework (one of my creations) and added translations for the
| button labels. All unprompted. It clearly understood the code
| base and how I like things done. So it just went ahead and did
| them. The syntax is not a problem. The obscurity of the library
| is not a problem as long as you give it enough to work with. It
| does less well coding something from scratch than working on
| existing code.
|
| IMHO, things like react are optimized for humans. They aren't
| actually that optimal for LLMs to work with. It's actually
| impressive that they can. Too much expressiveness and ambiguity.
| LLMs like things spelled out. Humans don't. We're still doing
| things manually so it helps if we can read and edit what the LLMs
| do. But that won't stay like that.
|
| I think in a few years, we'll start seeing languages and
| frameworks that are more optimal for Agentic coding tools as they
| will be the main users. So, stronger typing. More verbosity and
| less ambiguity.
| z3t4 wrote:
| A built in feature with frameworks is that you constantly have to
| update your code to be in sync with the latest version of the
| framework, this create work for contractors, it's like a taxation
| of software.
| gitaarik wrote:
| Yeah, it makes sense, LLMs are trained on slop, and so they
| produce more slop. And then everybody uses the same slop.
|
| In the meantime real engineers still use the proper tools.
| ramon156 wrote:
| Oof, a lot of unnecessary em dashes. The content is good, I just
| wish people wrote in their own style.
| TZubiri wrote:
| This was true when stackoverflow came out and jquery gave the
| best upvoteable succint answers.
|
| This too shall pass.
| hu3 wrote:
| Some with Windows.
|
| Sure it has a lot of staying power because of network effects
| (and qualities like backwards compatibility and gaming). But
| it's not a terminal, self-reinforcing snowball, force of nature
| like the article implies React is.
| TZubiri wrote:
| I noticed something similar. Even non technical clients now come
| with technical requirements because they use chatgpt, and it's
| always a react app.
|
| Poking client reqs is such a high value skill, most freelancers
| will just build what the client asks, "ok here's a react frontend
| with a postgres db and a crud app for your ecommerce website"
| instead of asking what the functional requirements are, maybe it
| can be a shopify thing, or just post it on amazon, or maybe a
| plain html app (optionally with js)
|
| It can be valid to ask for a brick house if you know what the
| other ways to build a house are, but if you just asked chatgpt
| for a house plan and it said "bricks", because it's the most
| housey thing and you said ok because it rings a bell and sounds
| housey, having a dev that asks and tells you about wooden houses
| or steel beams or concrete is the best that can happen.
|
| I appreciate when it happens the other way around, I go to a
| lawyer and tell them I want a corp, they start off assuming I
| know my shit, and after 5 minutes we are like, oh I don't want a
| corp
| janislaw wrote:
| The LLM owners also don't like to burn the knowledge into model
| weights or prompts, sharing some concerns of the post, e.g.
| freshness. RAG is the new hotness.
| aatd86 wrote:
| As someone who is currently writing their own js framework, llms
| are able to generate code quite easily. So I am not worried that
| we will be able to see new frameworks.
|
| Now, about the incentives? Probably less inference costs for
| llms, which probably means that they are more legible than the
| current state of the art for humans as well.
|
| Less API changes than let's say react also means that the
| generated code as less branching although llms can adapt anyway.
| Cheaper.
|
| Will probably be closer to the platform too (vanillaJS).
| atmonostorm wrote:
| I don't think 2004 was an appropriate time frame for the start of
| a "react usage over time" graph...
| mcphage wrote:
| I don't think "React is unstoppable because a vast wave of AI
| slop sites were written using it" is really the argument the
| author thinks it is.
| w4 wrote:
| Because of benchmarking LLMs have also been pushed towards
| fluency in Python, and related frameworks like Django and Flask.
| For example, SWE-Bench Verified is nearly 50% Django framework PR
| tasks: https://epoch.ai/blog/what-skills-does-swe-bench-verified-
| ev...
|
| It will be interesting to see how durable these biases are as
| labs work towards developing more capable small models that are
| less reliant on memorized information. My naive instinct is that
| these biases will be less salient over time as context windows
| improve and models become increasingly capable of processing
| documentation as a part of their code writing loop, but also
| that, in the absence of instruction to the contrary, the models
| will favor working with these tools as a default for quite some
| time.
| thr0w wrote:
| LLMs will not abstract away framework choice. They will concrete
| it away. React is for humans. You'll know we're out of the AI
| stoneage when coding models just generate direct machine
| instruction, because their output won't need to be touched by
| humans.
| Artoooooor wrote:
| "You're not competing with React's technical merits--you're
| competing with React's statistical dominance" is the industry so
| bad, that it can't decide framework on technical merit?
| w10-1 wrote:
| Yes, new frameworks will have a harder time getting uptake.
|
| Worse, with LLM's easily generating boilerplate, there's less
| pressure to make old framework code concise or clear, and the
| superior usability of a new framework won't be a big draw.
|
| But coding is a primary application/profit center, and you can be
| sure they'll reduce the latency between release and model
| support, and they'll start to emphasize/suggest new
| frameworks/paradigms as a distinguishing feature.
|
| My concern is about gaming the system, like SEO. If LLM coding is
| the gatekeeper, they'll be corrupted by companies seeking
| access/exposure. Developer uptake used to be a reasonable measure
| of quality, but in this new world it might only reflect exposure.
___________________________________________________________________
(page generated 2025-11-07 23:02 UTC)