4 ms·

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 pro

by simonw 1y ago

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.

michaelyin 1y ago
[dead]
jq_2023 1y ago
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 1y ago
  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 1y ago
  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 1y ago
  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 1y ago
    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 1y ago
    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 1y ago
      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-folders-with-single-file-logic 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 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-structure#redux-slices https://redux.js.org/tutorials/essentials/part-2-app-structu...
xnx 1y ago
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 1y ago
  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-future/ https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...
dangus 1y ago
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 1y ago
_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 1y ago
  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 1y ago
    Hot reloading is pretty common now for React or other JavaScript projects
  - MrJohz 1y ago
    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 1y ago
> 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 1y ago
  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 1y ago
    > [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 1y ago
      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.
hresvelgr 1y ago
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 1y ago
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-future/ https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...
- simonw 1y ago
  > 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.
  - mwcampbell 1y ago
    Are you saying that frameworks might become less important because LLMs can just generate boilerplate code instead? Or do I misunderstand? Personally, if the vibe-engineering future that some executives are trying to foist on us means that I'll be reading more code than I write directly, then I want that code to be _doubly_ succinct.
- port11 1y ago
  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 1y ago
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 1y ago
  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 1y ago
    Templates are horribly limited compared to the free mixing of js and markup Jsx gives you
    - aatd86 1y ago
      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 1y ago
  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 1y ago
    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".
mexicocitinluez 1y ago
> 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 1y ago
  > 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 1y ago
    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 1y ago
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 1y ago
  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 1y ago
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 1y ago
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 1y ago
  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 1y ago
    Isn't that what Geoff did: https://ghuntley.com/cursed/ https://ghuntley.com/cursed/ OK, it wasn't a Claude Skill, but it was done using Claude.
    - simonw 1y ago
      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.
  - 1y ago
zarzavat 1y ago
> 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 1y ago
  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 1y ago
  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 1y ago
    > 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 1y ago
      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.
lunias 1y ago
Yeah, I agree. I always ask it to use Vue.js and it always gives me Vue.js.
nothinghere789 1y ago
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!
boosyeller 1y ago
> I don't buy this. I think that while it may be easier to develop with LLMs in languages and frameworks the LLM may “know” best, in theory, models could be trained to code well in any language and could even promote languages that either the sponsoring company or LLM “prefers”.

by simonw 1y ago

michaelyin 1y ago

[dead]

jq_2023 1y ago

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 1y ago
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 1y ago
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 1y ago
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 1y ago
  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 1y ago
  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 1y ago
    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-folders-with-single-file-logic 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 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-structure#redux-slices https://redux.js.org/tutorials/essentials/part-2-app-structu...

xnx 1y ago

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 1y ago
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-future/ https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...

dangus 1y ago

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 1y ago

_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 1y ago
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 1y ago
  Hot reloading is pretty common now for React or other JavaScript projects
- MrJohz 1y ago
  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 1y ago

> 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 1y ago
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 1y ago
  > [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 1y ago
    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.

hresvelgr 1y ago

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 1y ago

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-future/ https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...

simonw 1y ago
> 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.
- mwcampbell 1y ago
  Are you saying that frameworks might become less important because LLMs can just generate boilerplate code instead? Or do I misunderstand? Personally, if the vibe-engineering future that some executives are trying to foist on us means that I'll be reading more code than I write directly, then I want that code to be _doubly_ succinct.
port11 1y ago
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 1y ago

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 1y ago
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 1y ago
  Templates are horribly limited compared to the free mixing of js and markup Jsx gives you
  - aatd86 1y ago
    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 1y ago
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 1y ago
  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".

mexicocitinluez 1y ago

> 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 1y ago
> 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 1y ago
  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 1y ago

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 1y ago
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 1y ago

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 1y ago

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 1y ago
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 1y ago
  Isn't that what Geoff did: https://ghuntley.com/cursed/ https://ghuntley.com/cursed/ OK, it wasn't a Claude Skill, but it was done using Claude.
  - simonw 1y ago
    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.
- 1y ago

zarzavat 1y ago

> 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 1y ago
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 1y ago
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 1y ago
  > 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 1y ago
    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.

lunias 1y ago

Yeah, I agree. I always ask it to use Vue.js and it always gives me Vue.js.

nothinghere789 1y ago

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!

boosyeller 1y ago

> I don't buy this. I think that while it may be easier to develop with LLMs in languages and frameworks the LLM may “know” best, in theory, models could be trained to code well in any language and could even promote languages that either the sponsoring company or LLM “prefers”.