8 ms·

Somewhat kinda sorta related. I have been working in React for the past 7ish years or so. I decided to try Svelte/Kit for my last project that I have been worki

Somewhat kinda sorta related. I have been working in React for the past 7ish years or so. I decided to try Svelte/Kit for my last project that I have been working on for a year and a half. I liked it, but didn’t think much of it. That was until I joined a new company a few months ago that was building a NextJS app. It was amazing how overly complicated all the app code seemed to do relatively simple things. Comparing readability to my Svelte code was like me trying to read hieroglyphics. React was amazing for complex web apps coming from JQuery. But there are other more modern and much simpler and ergonomic frameworks that have built on and learned from the past decade of React development. Seems like the industry has a bit of Stockholm syndrome thanks to the amazing ecosystem React has…which no other front end framework comes close to IMO.

phildenhoff 2y ago
On the other hand, while I really enjoyed using Svelte for a side project, I ended up rewriting it back in React. I’ve got years of experience with React and found the Svelte story just wasn’t as refined. Particularly, I was missing support in Biome and Storybook integration was essentially not there a year ago. I’m not sure what it’s like today! But that’s the joy of bleeding edge tech vs. a tool that’s been a market leader for a decade
gedy 2y ago
A more apples to apples comparison is NextJS and SvelteKit - you'll see they have similar levels of complexity when solving the same type of problems. (I like Svelte too, but NextJS is pretty convenient for what it does.)
- carlgreene 2y ago
  SvelteKit is what I used and I think they are both pretty reasonable in how they approach server vs. client side rendering, REST API's, etc... But strictly in dealing with client-side interactions and state, Svelte seems to just get out of my way, while React has so many foot-guns I have to conciously to avoid.
no_wizard 2y ago
IMO Next.js is overly complex for what it does. Look at something like Remix gets the job done with much the same features. Though I’d keep an eye on what Tanstack is doing in this space more than any project. They seem to understand the proper trade off between developer ergonomics and app complexity
- freedomben 2y ago
  I agree that it does feel overly complex, and generally speaking I loathe complexity, but Next.js does do a lot for you in exchange for that complexity. If you don't want/need the fancy client-side/SSR/SSG abilities to really optimize your app, then some of the hoops feel unnecessary, but if you really want that sweet edge, it's fantastic. That said, I rarely choose Next.js nowadays because even though it enables some real incredible performance/optimization, Phoenix (Elixir) is still great and uses a much simpler (IMHO) model. That could just be because I'm used to that model though from many, many years of Rails and MVC patterns in GUIs before that.
- crooked-v 2y ago
  Next is trying to be everything out of box in part to directly fight (for their own benefit) the whole "no two React projects look alike" issue, so of course it's complicated.
jitl 2y ago
I don’t think it’s React that’s responsible for complicated code. I’ve never seen a large GUI app written in any language or toolkit that isn’t super complicated. I’ve dealt with much worse horrors with “vanilla JS” (aka, a home grown framework that does everything a bit worse in every way) than with React or Svelte. I too have personal project code that is sunshine and roses compared to my Business React day job, but that could also be because my personal project app serves 2 users, is developed by 2 people over a year, and my Business React application serves 100 million users, is developed by ~300 people over 8 years.
- torginus 2y ago
  not sure - I've yet to see any React code that handles large or incomplete state cleanly (think very long lists not loaded into memory)
- mikedelfino 2y ago
  One advantage of vanilla JavaScript is its long-term stability. A developer can often revisit code written years ago, make a quick tweak to add a feature, and move on. It will probably feel as familiar and straightforward as it did back then, with new APIs and syntax improvements adoptable in small steps. By contrast, a project built on the framework of the moment might not age as gracefully; the build process can feel outdated or cumbersome as standards evolve. Of course, if you’re able to keep everything up-to-date, it’s less of an issue, but that’s not always feasible. And while vanilla JS may not be ideal for a project scaled to 100 million users, it’s a practical choice for many situations.
  - _puk 2y ago
    Have you seen vanilla js lately? It's moved on massively as a language, picked up many, many new paradigms. Going back to code more than a few years old and your newer devs are going to be asking "what's all this var nonsense"?!
    - KronisLV 2y ago
      Not just that, but the tooling has also evolved and changed. Good luck trying to get an old project with old versions of Yarn and Gulp working well, where trying to update either breaks the build but using anything other than var confuses the tooling. Provided that you have a build step of any sort (e.g. minifying the assets) and people picked whatever was popular at the time of the project being made.
Tade0 2y ago
As someone who works mainly with Angular but dipped toes professionally in both React and Vue what bothered me the most in the former was the fact that no two React projects are the same, as you're expected to have a collection of libraries for all the things React doesn't provide out of the box. Angular is terrible in more ways than one, but I've never had to think or worse - argue with anyone what routing/form validation/http request/unit testing library to use or what selection of those is used in a project I'm about to join.
- deleted 2y ago
  [deleted]
phito 2y ago
Every time I have to use React, I'm astounded at how convoluted web app development still is in 2024. Am I out of touch or is it really that bad?
- pjmlp 2y ago
  You're right, I have to deal with that world instead of .NET and Java, because of many enterprises products now only offering React based SDKs.
- crooked-v 2y ago
  If you don't want the fancy stuff, just use react-redux and build an SPA. It gets complicated past that, but that's because trying to mix streamed server generated HTML and client rendered HTML (and often one and then the other in the same piece of UX) is hard to do.
- deergomoo 2y ago
  Everyone in JS-land seems to have an opinion about how tooling should work, and because the platform (well, Node at least) provides no opinions of its own, everyone goes ahead and implements it. So you end up with a thousand-and-one competing bundlers, linters, formatters, test runners, etc, with all the associated churn and cost in learning it all and getting a new project up and running. Compare that to something like Go which includes all of that stuff out of the box—by and large everyone has just said "yep that seems to work" and stuck with the defaults. I think the second problem is the browser still fundamentally wants to be a displayer of documents. Yes there has been continued additions of new APIs over the years that have made the SPA pattern much easier to work with, the fact of the matter is you can still save yourself about an order of magnitude of complexity if you can get away with your app being an "old school" multi-page affair.
  - mirekrusin 2y ago
    Yet I wouldn't call gui ecosystem in go a success like js'es is.
    - 2y ago
DanielHB 2y ago
Any codebase that is worked on by a lot of people tends to become over-complicated unless there is very good technical leadership (and even then). When you are solo-dev in a project and run into some underlying problem[1] of your codebase you fix the problem. When you have a team the less-powerful[2] tend to work around it because fixing the underlying problem is not just a technical problem, but an organizational problem[3]. The same applies as a codebase gets older and bigger. The best I can explain is through a formula: real cost fixing underlying problem = size of team * size of codebase affected by problem * nominal cost of fixing problem Which makes this (in math terms) cubic (^3) while people scale linearly (*n). Which is why when people compare technologies it is very important to also think about the "Pit of Success": https://blog.codinghorror.com/falling-into-the-pit-of-success/ https://blog.codinghorror.com/falling-into-the-pit-of-succes... React and Svelte are very similar, but React it so much more powerful[4] people often misuses those powers causing them to become foot-gun. [1]: Abstractions, APIs, code patterns, libraries used, etc [2]: People new to the project, people less experienced, people who don't hold the big title (staff engineer, etc) [3]: It requires talking and explaining things to other people, often very busy people. The bigger the company the more teams need to be kept in sync when big things change, there might also be some inter-department drama or arbitrary deadlines from different teams and so on. [4]: A lot of the power of React is derived from ecosystem libraries. Where stuff you can do is technically possible with React alternatives, but not very practical.

phildenhoff 2y ago

On the other hand, while I really enjoyed using Svelte for a side project, I ended up rewriting it back in React. I’ve got years of experience with React and found the Svelte story just wasn’t as refined. Particularly, I was missing support in Biome and Storybook integration was essentially not there a year ago. I’m not sure what it’s like today! But that’s the joy of bleeding edge tech vs. a tool that’s been a market leader for a decade

gedy 2y ago

A more apples to apples comparison is NextJS and SvelteKit - you'll see they have similar levels of complexity when solving the same type of problems. (I like Svelte too, but NextJS is pretty convenient for what it does.)

carlgreene 2y ago
SvelteKit is what I used and I think they are both pretty reasonable in how they approach server vs. client side rendering, REST API's, etc... But strictly in dealing with client-side interactions and state, Svelte seems to just get out of my way, while React has so many foot-guns I have to conciously to avoid.

no_wizard 2y ago

IMO Next.js is overly complex for what it does. Look at something like Remix gets the job done with much the same features. Though I’d keep an eye on what Tanstack is doing in this space more than any project. They seem to understand the proper trade off between developer ergonomics and app complexity

freedomben 2y ago
I agree that it does feel overly complex, and generally speaking I loathe complexity, but Next.js does do a lot for you in exchange for that complexity. If you don't want/need the fancy client-side/SSR/SSG abilities to really optimize your app, then some of the hoops feel unnecessary, but if you really want that sweet edge, it's fantastic. That said, I rarely choose Next.js nowadays because even though it enables some real incredible performance/optimization, Phoenix (Elixir) is still great and uses a much simpler (IMHO) model. That could just be because I'm used to that model though from many, many years of Rails and MVC patterns in GUIs before that.
crooked-v 2y ago
Next is trying to be everything out of box in part to directly fight (for their own benefit) the whole "no two React projects look alike" issue, so of course it's complicated.

jitl 2y ago

I don’t think it’s React that’s responsible for complicated code. I’ve never seen a large GUI app written in any language or toolkit that isn’t super complicated. I’ve dealt with much worse horrors with “vanilla JS” (aka, a home grown framework that does everything a bit worse in every way) than with React or Svelte. I too have personal project code that is sunshine and roses compared to my Business React day job, but that could also be because my personal project app serves 2 users, is developed by 2 people over a year, and my Business React application serves 100 million users, is developed by ~300 people over 8 years.

torginus 2y ago
not sure - I've yet to see any React code that handles large or incomplete state cleanly (think very long lists not loaded into memory)
mikedelfino 2y ago
One advantage of vanilla JavaScript is its long-term stability. A developer can often revisit code written years ago, make a quick tweak to add a feature, and move on. It will probably feel as familiar and straightforward as it did back then, with new APIs and syntax improvements adoptable in small steps. By contrast, a project built on the framework of the moment might not age as gracefully; the build process can feel outdated or cumbersome as standards evolve. Of course, if you’re able to keep everything up-to-date, it’s less of an issue, but that’s not always feasible. And while vanilla JS may not be ideal for a project scaled to 100 million users, it’s a practical choice for many situations.
- _puk 2y ago
  Have you seen vanilla js lately? It's moved on massively as a language, picked up many, many new paradigms. Going back to code more than a few years old and your newer devs are going to be asking "what's all this var nonsense"?!
  - KronisLV 2y ago
    Not just that, but the tooling has also evolved and changed. Good luck trying to get an old project with old versions of Yarn and Gulp working well, where trying to update either breaks the build but using anything other than var confuses the tooling. Provided that you have a build step of any sort (e.g. minifying the assets) and people picked whatever was popular at the time of the project being made.

Tade0 2y ago

As someone who works mainly with Angular but dipped toes professionally in both React and Vue what bothered me the most in the former was the fact that no two React projects are the same, as you're expected to have a collection of libraries for all the things React doesn't provide out of the box. Angular is terrible in more ways than one, but I've never had to think or worse - argue with anyone what routing/form validation/http request/unit testing library to use or what selection of those is used in a project I'm about to join.

deleted 2y ago
[deleted]

phito 2y ago

Every time I have to use React, I'm astounded at how convoluted web app development still is in 2024. Am I out of touch or is it really that bad?

pjmlp 2y ago
You're right, I have to deal with that world instead of .NET and Java, because of many enterprises products now only offering React based SDKs.
crooked-v 2y ago
If you don't want the fancy stuff, just use react-redux and build an SPA. It gets complicated past that, but that's because trying to mix streamed server generated HTML and client rendered HTML (and often one and then the other in the same piece of UX) is hard to do.
deergomoo 2y ago
Everyone in JS-land seems to have an opinion about how tooling should work, and because the platform (well, Node at least) provides no opinions of its own, everyone goes ahead and implements it. So you end up with a thousand-and-one competing bundlers, linters, formatters, test runners, etc, with all the associated churn and cost in learning it all and getting a new project up and running. Compare that to something like Go which includes all of that stuff out of the box—by and large everyone has just said "yep that seems to work" and stuck with the defaults. I think the second problem is the browser still fundamentally wants to be a displayer of documents. Yes there has been continued additions of new APIs over the years that have made the SPA pattern much easier to work with, the fact of the matter is you can still save yourself about an order of magnitude of complexity if you can get away with your app being an "old school" multi-page affair.
- mirekrusin 2y ago
  Yet I wouldn't call gui ecosystem in go a success like js'es is.
  - 2y ago

DanielHB 2y ago

Any codebase that is worked on by a lot of people tends to become over-complicated unless there is very good technical leadership (and even then). When you are solo-dev in a project and run into some underlying problem[1] of your codebase you fix the problem. When you have a team the less-powerful[2] tend to work around it because fixing the underlying problem is not just a technical problem, but an organizational problem[3]. The same applies as a codebase gets older and bigger. The best I can explain is through a formula: real cost fixing underlying problem = size of team * size of codebase affected by problem * nominal cost of fixing problem Which makes this (in math terms) cubic (^3) while people scale linearly (*n). Which is why when people compare technologies it is very important to also think about the "Pit of Success": https://blog.codinghorror.com/falling-into-the-pit-of-success/ https://blog.codinghorror.com/falling-into-the-pit-of-succes... React and Svelte are very similar, but React it so much more powerful[4] people often misuses those powers causing them to become foot-gun. [1]: Abstractions, APIs, code patterns, libraries used, etc [2]: People new to the project, people less experienced, people who don't hold the big title (staff engineer, etc) [3]: It requires talking and explaining things to other people, often very busy people. The bigger the company the more teams need to be kept in sync when big things change, there might also be some inter-department drama or arbitrary deadlines from different teams and so on. [4]: A lot of the power of React is derived from ecosystem libraries. Where stuff you can do is technically possible with React alternatives, but not very practical.