6 ms·

I just don’t understand this opinion. Backend (and frontend!) can be use stable technology choices if you want to. There are also plenty of bleeding edge libra

I just don’t understand this opinion. Backend (and frontend!) can be use stable technology choices if you want to. There are also plenty of bleeding edge libraries/frameworks/languages that come out every week. As an example, how do you want to deploy your backend? VPS, severless, Kubernetes? What database? Which language? Which libraries? There are boring stable answers to the above for backend, just like there are boring stable answers to frontend. Really, I think you’ve just found those boring stable options for the backend and you haven’t done that for the frontend yet. React has been out for more than a decade and it’s the dominant way of building UIs. And there are pros and cons to this with 1000 solutions, but, really, plain React will work for most things you want to do.

WD-42 2y ago
What exactly is "plain React" though? Not sure I've ever seen a project that used only React and nothing else. It would seem you'd need a build step, at the minimum.
- roywiggins 2y ago
  You only really need a build step to use JSX, which is strictly speaking optional.
  - shepherdjerred 2y ago
    This is true (and part of why I love React/JSX) but in practice nobody writes JSX by hand.
    - cowoder 2y ago
      Isn't it the other way around, nobody writes React by hand they all use JSX?
      - shepherdjerred 2y ago
        You're right :)
  - Lutger 2y ago
    Technically you don't even need react, you can do it all in javascript! Joking aside, you really do need to solve the problems jsx solves, but also webpack, next.js, react-router and depending on your application, something like mantine or tailwind. These are the minimum I think. If you have a smallish project you can get by hand-rolling your own solutions, but it doesn't make the problems themselves go away. In fact, it is exactly the claim in this thread that there are a lot of beaten paths in backend languages with relative stability over time, whereas in frontend it is 1) not clear what the beaten path is (there isn't one) and 2) when there appears to be favored solution, it often changes radically or disappears after just a couple of years. For example, create-react-app used to be the default way to start a react app, it is now deprecated. But for python, Django has been a stable beaten path for many, many years. Same for Rails. C# also tends to change every couple of years, but there is always just one single Microsoft recommended way to do things. Sure there are many experimental libraries and contenders in these languages as well, but there isn't really anything with the same maturity and stability in frontend.
  - fijiaarone 2y ago
    you can always just do: <script src="react.js"> <script src="react-dom.js"> <script> const recognition = undefined var foo = document.querySelector("#foo") let bar = ReactDOM.createRoot(foo) foo.innerHTML = bar.render("<b>eyond<a>ll{recognition}"); </script>
- shepherdjerred 2y ago
  Yes, you would need a build step. create-react-app has existed for a very long time and works quite well though advanced applications tend to outgrow it. Alternatives are Webpack (stable, boring), Vite (starting to overtake Webpack since it's significantly simpler), and 1000 other libraries. Again, there is some movement here, but Webpack has been in a dominant position for nearly a decade and there's no reason you can't continue to use it today if you value stability. It's the equivalent of choosing to host your backend on a VPS instead of trying out serverless. Needing a build step is part of the complexity of frontend. I think frontend is getting much simpler with build tools like Vite and the addition of ES modules. But, even with these new things coming out, you can stick to your boring stable choices on the frontend just like you can on the backend.
  - WD-42 2y ago
    Yea I'm not really buying it. create-react-app is deprecated. https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project points you directly at Next.js as a *starting point* and the section about using React without a framework does it's best to discourage you from doing it. This is insane for beginners.
  - nsonha 2y ago
    You use a lot of words to respond to such a minor point. The main point is that actual "plain react" is useless. You need at least a router, some way to manage state, some way to manage style and so on. It's why nextjs is so popular, they are practically "plain react"
    - __jonas 2y ago
      Useless is a massive exaggeration. > You need at least a router You only need a router if you want to build a SPA with different routes, not all web applications are that! Tons of practical React apps are just a single screen, or even embedded component. > some way to manage state You do not need an external library for complex state management, the React docs have some great guides on how to achieve this with plain React: https://react.dev/learn/scaling-up-with-reducer-and-context https://react.dev/learn/scaling-up-with-reducer-and-context > some way to manage style Plain CSS and the JSX style property are entirely enough for most apps. If you are using a build tool like Vite, you can also do CSS modules for scoping styles to your React components for more complex applications. I do agree that styling is not a strong point of React, but I don't think pulling in a dependency is necessary.
- aprdm 2y ago
  You don't need a build step if you do everything in javascript without jsx. I have done it like that in the past on air gapped environments (and vendored the deps)
Lutger 2y ago
React proper may be more or less stable since hooks came out 6 years ago, on its own it isn't sufficient. You still need to think about react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever. And some of these have changed radically from year to year. The react ecosystem is not stable. It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app. It is true that for backend it is more or less the same, however it is a matter of degree. If frontend is all you do, it may be managable, but for full-stack devs who also need to manage infra it can sometimes be overwhelming.
- __jonas 2y ago
  > You still need to think about react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever You really don't need any of this though, you can get super far with React alone, and the new docs on react.dev are great at explaining this and pushing this idea in my opinion.
  - deleted 2y ago
    [deleted]
  - fijiaarone 2y ago
    React alone is just a bad template library.
- shepherdjerred 2y ago
  > react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever You don't need any of this (aside from a bundler). That's my whole point. You can use these libraries and be on the cutting edge, or go with something simpler. You'll have the exact same problem on the backend if you want to use a library for everything.
- alexanderchr 2y ago
  > It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app. I've maintained a sizeable react app for 8 years, and this has not been my experience at all. Maybe 10 years ago things would break monthly but nowadays things are quite stable, with very reasonable deprecation schedules and upgrade paths. I have lots of code running that I haven't touched in 5+ years and it is not causing any problems even when I'm keeping the main parts of the appliaction up to date with modern practices.
mattgreenrocks 2y ago
The churn in React keeps me out. I also get really suspicious of tech that spawns mini cottage industries, where there has to be a React-ified wrapper for every single thing. Maybe in 2025. I've learned Svelte 5 and think it is pretty good for the tradeoffs it makes though. And I think MPA is the right default for 95% of sites.
- fijiaarone 2y ago
  As soon as Svelte 5 stabilizes you can start porting libraries to work with it. In the meantime, you can play with the tutorial in a textarea in a browser and feel as productive as you want.
jrochkind1 2y ago
I think part of the issue is that the "boring stable" choice for front-end, React, is disliked by many, and often doesn't actually seem very boring (if that means easy to understand how to do it right) or stable (if that means doens't drastically change much) to many.
zonethundery 2y ago
I think the responses to your comment show the whirlwind of 'wtf?' confronting any programmer contemplating front end development for the first time. What you wrote is probably true (and the one "see how far you can get in react only" comment is probably a decent path, but the landscape is overwhelming.
- LegionMammal978 2y ago
  Yeah, the frontend scene definitely suffers from hype-driven development: it's not good enough that we have a tool to do the job, we need the tool to be the bestest ever on every possible metric, so we end up with a treadmill of additional frameworks, bundlers, etc. that are hyped up in any given year. E.g., I might think to ask, "Which tool creates the output with the lesser overhead on the client, Webpack or Vite?" But I can't find anything solid about that, since everyone's too busy hyping up the dev experience or whatever. It's a shame that you have to swim against the tide so heavily, if you value simplicity over immediate kitchen-sink levels of functionality. Personally, I've landed on pure client-side React (with any bundler, or with Babel alone if you're feeling adventurous) since it doesn't try to have any purpose other than updating components according to state. Many of its competitors have too much poorly-documented magic for my taste.

WD-42 2y ago

What exactly is "plain React" though? Not sure I've ever seen a project that used only React and nothing else. It would seem you'd need a build step, at the minimum.

roywiggins 2y ago
You only really need a build step to use JSX, which is strictly speaking optional.
- shepherdjerred 2y ago
  This is true (and part of why I love React/JSX) but in practice nobody writes JSX by hand.
  - cowoder 2y ago
    Isn't it the other way around, nobody writes React by hand they all use JSX?
    - shepherdjerred 2y ago
      You're right :)
- Lutger 2y ago
  Technically you don't even need react, you can do it all in javascript! Joking aside, you really do need to solve the problems jsx solves, but also webpack, next.js, react-router and depending on your application, something like mantine or tailwind. These are the minimum I think. If you have a smallish project you can get by hand-rolling your own solutions, but it doesn't make the problems themselves go away. In fact, it is exactly the claim in this thread that there are a lot of beaten paths in backend languages with relative stability over time, whereas in frontend it is 1) not clear what the beaten path is (there isn't one) and 2) when there appears to be favored solution, it often changes radically or disappears after just a couple of years. For example, create-react-app used to be the default way to start a react app, it is now deprecated. But for python, Django has been a stable beaten path for many, many years. Same for Rails. C# also tends to change every couple of years, but there is always just one single Microsoft recommended way to do things. Sure there are many experimental libraries and contenders in these languages as well, but there isn't really anything with the same maturity and stability in frontend.
- fijiaarone 2y ago
  you can always just do: <script src="react.js"> <script src="react-dom.js"> <script> const recognition = undefined var foo = document.querySelector("#foo") let bar = ReactDOM.createRoot(foo) foo.innerHTML = bar.render("<b>eyond<a>ll{recognition}"); </script>
shepherdjerred 2y ago
Yes, you would need a build step. create-react-app has existed for a very long time and works quite well though advanced applications tend to outgrow it. Alternatives are Webpack (stable, boring), Vite (starting to overtake Webpack since it's significantly simpler), and 1000 other libraries. Again, there is some movement here, but Webpack has been in a dominant position for nearly a decade and there's no reason you can't continue to use it today if you value stability. It's the equivalent of choosing to host your backend on a VPS instead of trying out serverless. Needing a build step is part of the complexity of frontend. I think frontend is getting much simpler with build tools like Vite and the addition of ES modules. But, even with these new things coming out, you can stick to your boring stable choices on the frontend just like you can on the backend.
- WD-42 2y ago
  Yea I'm not really buying it. create-react-app is deprecated. https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project points you directly at Next.js as a *starting point* and the section about using React without a framework does it's best to discourage you from doing it. This is insane for beginners.
- nsonha 2y ago
  You use a lot of words to respond to such a minor point. The main point is that actual "plain react" is useless. You need at least a router, some way to manage state, some way to manage style and so on. It's why nextjs is so popular, they are practically "plain react"
  - __jonas 2y ago
    Useless is a massive exaggeration. > You need at least a router You only need a router if you want to build a SPA with different routes, not all web applications are that! Tons of practical React apps are just a single screen, or even embedded component. > some way to manage state You do not need an external library for complex state management, the React docs have some great guides on how to achieve this with plain React: https://react.dev/learn/scaling-up-with-reducer-and-context https://react.dev/learn/scaling-up-with-reducer-and-context > some way to manage style Plain CSS and the JSX style property are entirely enough for most apps. If you are using a build tool like Vite, you can also do CSS modules for scoping styles to your React components for more complex applications. I do agree that styling is not a strong point of React, but I don't think pulling in a dependency is necessary.
aprdm 2y ago
You don't need a build step if you do everything in javascript without jsx. I have done it like that in the past on air gapped environments (and vendored the deps)

Lutger 2y ago

React proper may be more or less stable since hooks came out 6 years ago, on its own it isn't sufficient. You still need to think about react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever. And some of these have changed radically from year to year. The react ecosystem is not stable. It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app. It is true that for backend it is more or less the same, however it is a matter of degree. If frontend is all you do, it may be managable, but for full-stack devs who also need to manage infra it can sometimes be overwhelming.

__jonas 2y ago
> You still need to think about react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever You really don't need any of this though, you can get super far with React alone, and the new docs on react.dev are great at explaining this and pushing this idea in my opinion.
- deleted 2y ago
  [deleted]
- fijiaarone 2y ago
  React alone is just a bad template library.
shepherdjerred 2y ago
> react-router, mobx, redux, nextjs, remix, vite, tailwind or mantine or material ui or whatever You don't need any of this (aside from a bundler). That's my whole point. You can use these libraries and be on the cutting edge, or go with something simpler. You'll have the exact same problem on the backend if you want to use a library for everything.
alexanderchr 2y ago
> It is unavoidable to have a truly gigantic amount of (transitive) dependencies, and its rare you go a month of updates without it breaking your app. I've maintained a sizeable react app for 8 years, and this has not been my experience at all. Maybe 10 years ago things would break monthly but nowadays things are quite stable, with very reasonable deprecation schedules and upgrade paths. I have lots of code running that I haven't touched in 5+ years and it is not causing any problems even when I'm keeping the main parts of the appliaction up to date with modern practices.

mattgreenrocks 2y ago

The churn in React keeps me out. I also get really suspicious of tech that spawns mini cottage industries, where there has to be a React-ified wrapper for every single thing. Maybe in 2025. I've learned Svelte 5 and think it is pretty good for the tradeoffs it makes though. And I think MPA is the right default for 95% of sites.

fijiaarone 2y ago
As soon as Svelte 5 stabilizes you can start porting libraries to work with it. In the meantime, you can play with the tutorial in a textarea in a browser and feel as productive as you want.

jrochkind1 2y ago

I think part of the issue is that the "boring stable" choice for front-end, React, is disliked by many, and often doesn't actually seem very boring (if that means easy to understand how to do it right) or stable (if that means doens't drastically change much) to many.

zonethundery 2y ago

I think the responses to your comment show the whirlwind of 'wtf?' confronting any programmer contemplating front end development for the first time. What you wrote is probably true (and the one "see how far you can get in react only" comment is probably a decent path, but the landscape is overwhelming.

LegionMammal978 2y ago
Yeah, the frontend scene definitely suffers from hype-driven development: it's not good enough that we have a tool to do the job, we need the tool to be the bestest ever on every possible metric, so we end up with a treadmill of additional frameworks, bundlers, etc. that are hyped up in any given year. E.g., I might think to ask, "Which tool creates the output with the lesser overhead on the client, Webpack or Vite?" But I can't find anything solid about that, since everyone's too busy hyping up the dev experience or whatever. It's a shame that you have to swim against the tide so heavily, if you value simplicity over immediate kitchen-sink levels of functionality. Personally, I've landed on pure client-side React (with any bundler, or with Babel alone if you're feeling adventurous) since it doesn't try to have any purpose other than updating components according to state. Many of its competitors have too much poorly-documented magic for my taste.