10 ms·

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point Reac

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to build on React are doing it largely out of habit. I'm going to withhold my own thoughts about that quote, cause I'm curious what everyone else thinks. Wrt. Web Components, I played around with Web Components about half a decade ago and they felt promising but not ready for prime time yet. They were pretty messy and felt like they did a poor job of encapsulation. (At least at the time.) I haven't looked at them recently, but the code examples in these articles look much better (and cleaner) than what I remember. [1] https://adactio.com/journal/20618 https://adactio.com/journal/20618

troupo 3y ago
> They were pretty messy and felt like they did a poor job of encapsulation, ultimately. (At least at the time.) They are still messy. https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html
wayfinder 3y ago
As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do that in JS and every custom way you invent looks like trash. Doing something like this.shadow.innerHTML = `your HTML` with web components is terrible. document.createElement() is terrible. $('div').appendChild() is terrible. <script language="html" name="my-template"></script> is terrible. HTML(Div(Strong(text))) is terrible*. Storing templates as JSON and writing a one-off loader is terrible. <div style="display:none">template</div> is terrible. I've done it every possible way and they are all terrible. JSX fixed all that. The biggest previous attempt at something like JSX was E4X where you could embed XML straight into JS, which was kinda nice except it added the entirety of XML and its complexity. I creamed when it came out but then I tried it and it was not it. (E4X ended up surviving a little longer in Adobe Flash though.) E4X: https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML *This is what JSX compiles to behind the scenes.
- breadwinner 3y ago
  What if you could have the best of both worlds? What if you could use JSX templates and use standards-based web components? You can. Here's an example of using a web component in a JSX template (look for zx-listeditor): https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/Views/DemoPage.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo... Here's how the web component is implemented, also using JSX: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
  - wayfinder 3y ago
    Not saying that you can't. I'm just explaining why React won and how it was blatantly obvious that it was going to win when it came out (that is, if you were there in the before-times).
    - breadwinner 3y ago
      Agree with you on that. React was a breath of fresh air compared to what we had in the before-times, such as Angular, Ember and so on. The canonical demo of Ember.js was two-way data binding. React did away with two-way data binding and introduced JSX syntax. This was a major step forward. Code suddenly looked sane and readable. Then they took two steps backward when they introduced hooks. Code went back to being unreadable.
  - chatmasta 3y ago
    Also, the entire OP article is demonstrating this... I'm not sure many of the comments here actually read it...
- zelphirkalt 3y ago
  Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in separate files, or making use of a DSL, that treats HTML as structured data, say for example SXML. Also there are issues with that custom HTML-look-alike preprocessor, because you cannot write class="...", because then somehow it gets syntactically confused, because "class" is now a keyword in JS. This all feels rather half-baked. Why can't the parser/prprocessor distinguish between that "class" and "class" in JS source code? We can have reusable HTML snippets (some may call components) with normal templating engines easily. Look at something like Jinja2 and how to reuse blocks and macros. Yes, some React component can encapsulate its own interactive behavior. That is only because we are already writing JS though, so we can already write frontend logic. But do we actually want that? Coupling state and behavior? I think we might not. Writing a script that gets served only on those rendered templates, where it is needed is not so hard either, when using a normal templating engine.
deleted 3y ago
[deleted]
gustavus 3y ago
It sounds like the common thing that someone in the Frontend space would say, that a technology less than 5 years old says the technology is old. I prefer the terms stable, mature, or hardened. People use React/Angular because large products are forced to have a way to organize things across multiple developers and time. Now don't get me wrong I think these JS bloated websites are an abomination that have largely made the web worse and not better, especially since UX "engineers" feel a compulsive need to change the layout every 6 months and now even simply scrolling through a page involves 50 web requests, and takes a full 3 minutes to load the next page... but I digress.
tshaddox 3y ago
Fascinating that React simultaneously receives criticism as being 1) boring, old technology that has been around for so long that no one even remember why it was chosen in the first place, and 2) extremely fast-churning, bleeding edge software that is constantly changing and breaking because the JS community is more interested in chasing trends than building robust stuff.
- pwdisswordfishc 3y ago
  React has merely aged, not matured.
- paulddraper 3y ago
  Same people who say: 1) the ecosystem keeps chasing shiny tech that is constantly changing, not boring solutions 2) everything should be written in Rust
robin_reala 3y ago
React “won” because Facebook spent three years flying devrel to every web conference on earth to persuade other people that Facebook’s problem space was applicable to small agencies. Back in reality, React is slow and massively overbuilt for the majority of stuff that most people are building. If you played around with Web Components a long time ago then you probably played with the v0 spec, which was somewhat different to the current version.
- troupo 3y ago
  > React “won” because Facebook spent three years flying devrel to every web conference You do know that Google sponsored and ran things like Polymer conf? That it builds lit? That Google's devs have literally overrun and overruled most web specs committees? That Google has spend hundreds of millions of dollars promoting Web Components? And yet here we are.
  - robin_reala 3y ago
    Polymer was incredibly even slower that React and even more overbuilt, and it had the added negative that it tried to enforce a visual style as well, which was too much for most people. Google couldn’t spend its way out of that hole. As for Web Component specs, we got v1 because of Apple and Mozilla: Google would happily have stayed with v0.
  - pseudosavant 3y ago
    I'm glad to have read this today. I'm going to look into how I could use web components in my next side project. I'd really like something that worked easily with SSR and client-side, maybe using htmx. In retrospect, I think I avoided web components because of Google and their aggressive dev relations pushing Polymer. It felt so one-sided that it didn't seem like a web standard. It felt more like a Google "standard" like NaCL. Having to ship Polymer to support non-Google browsers felt even more heavy weight than React.
    - troupo 3y ago
      > I'd really like something that worked easily with SSR and client-side Then you should skip Web Components :)
menssen 3y ago
"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the application state.* I kind of feel like people get tripped up by the fact that "virtual DOM" and "shadow DOM" sort of sound similar. They have literally nothing to do with each other. The React "virtual DOM" allows you to *completely re-output the entire user interface* on every state change, which is not possible with any other design pattern, and is not possible without a framework, because actually re-rendering the entire tree on every state change isn't performative (or usable). Anybody who is advocating an alternative to React needs to do one of two things: (A) Make a convincing argument that a different design pattern is better. Some things we've tried, which most people think are worse: 1. Using the DOM as your data model (jQuery) 2. Manually writing virtual representations of every view (Backbone) 3. Auto-magically two-way binding some data structure with the DOM (Angular 1) 4. Observables (Ember, maybe Angular 2+?) (B) Advocate a framework other than React that uses the same pattern as React, but improves the usability. I think the two places there is the most room for improvements are: 1. Animations 2. useEffect() in general I have not seen anybody successfully do either A or B. Recommended reading: https://acko.net/blog/get-in-zoomer-we-re-saving-react/ https://acko.net/blog/get-in-zoomer-we-re-saving-react/
- techpression 3y ago
  I would say SolidJS does everything better than React while keeping with the same general mindset. React spent way too much time worrying about DX to the point that now DX is really bad. Fine grained granularity is such a breath of fresh air to work with after the very large and very heavy brush that is the React “render the world every time anything changes” method (yes they try to be smart about it, but so far haven’t succeeded, the next compiler might solve it, but then we’re back to a black box of incomprehensible code soup to debug).
  - vmfunction 3y ago
    Thank you. Finally someone mentions Solid, it got all the good part of React, and none of the bloated parts. Personally, JSX is the mainly thing that makes React attractive. As JSX is just modern E4X. It really ought to be put into the ES standard again instead of this Web Component stuff. Another good JSX implementation (SSR) is: https://nanojsx.io https://nanojsx.io If you just want something light JSX, then this seems the way to go for now.
mustaflex 3y ago
Web components are a bit verbose by themselves but used with a library like lit.js you can build a framework agnostic component library. Angular and Vue support WC out of the box and they have a wrapper for React. I think the only thing missing(or not mature enough right) now is SSR. There are probably libraries other than lit.js that take the pain out of writing WC. I was skeptical at first but I've seen in production a lit.js/WC component library used with React and Angular successfully in the banking sector and it works surprisingly well.
austin-cheney 3y ago
As a full time JavaScript developer of 15 years it boils down to 2 reasons. 1. Eases candidate selection. There is no uniform baseline of competence in software generally and certainly nothing exists for web development. Its often the blind leading the blind, so outsource everything to a tool. At the very least, people that cannot use that tool are then not qualified to be there if you discount absolutely everything else. After all, it isn't as though employers are willing to train new developers to perform as required, so they need to turn this into a commodity as much as possible. 2. Composition. Most of the people who do web development cannot write original software, plan, or organize at the level required by modern applications. Employers still need people to do trivial things to get text to appear on screen. As the demand for these trivial tasks still exists employers still need to hire people to do this work, and so they attempt to outsource the parts that require higher intelligence. These beg the obvious question: What will happen when employers realize they don't need to overpay developers to do this work when half of it can be pushed into content management systems and the other half can be pushed into AI?
djrenren 3y ago
As someone who just had to answer this for my startup, the value of React is that it's robust and immensely hire-able. If you're looking for frontend developers, the one thing you can always expect is at least passable React knowledge. Everything else, even if it has a better technical fit for your project, is likely riskier for your organization.
- pseudosavant 3y ago
  Some of the most productive teams I've worked with (not as a dev) have been for tech stacks I personally don't enjoy using. Java, .NET/C#, React, etc. In practice, I'd rather quickly hire a local senior Java/C# dev for 1X than scour the interwebs to hire a Golang dev that requires relocation for 1.5-2X. If I was going to learn a language though, I'd probably learn Golang. Their rate is so much higher.
- Draiken 3y ago
  I find this argument so absurd. If you know JavaScript and basic programming, you can use any front-end framework. We're hyper-specializing people in a specific framework that then don't even understand the basics of JavaScript itself. I already find the divide between frontend and backend developers unnecessary the majority of the time. This takes it a step further and in turn creates monstrosities like the leftpad debacle. Can we stop with this nonsense? Hire good developers and let them spend 5 minutes to learn the god damn framework of the week. If your hire can't learn React in a week, I have some bad news for you.
mattlondon 3y ago
Would anyone pick react these days, if they did not already use it/know it/think-it-is-what-they-should-use-because-everyone-else-does? I think that is the point. The original "pitch" for react in my mind was that it was lightweight and simple. I don't think you can say that any more, and I think a lot of rough edges have been identified (e.g. hooks fiasco, app state management, dependency-hell etc to name just 3) after years of use. It's the same cycle that always happens. Old thing ossifies and grows fat overtime trying to be all things to all people. Then some new thing appears that starts with a clean slate and no prior expectations that proves popular as a result
- JacobThreeThree 3y ago
  It's as you describe, but also the spec and browser support landscape has changed.
davedx 3y ago
React isn't legacy technology. What a perfidious statement. I can easily justify the reasons I still use React, but I can't be bothered writing it out every time some gimmicky front-end tech hits HN.
- sesm 3y ago
  Every alternative to React roughly fall into one of 3 categories: 1. Go back to reactive templates. 2. Sprinkle directives over plain HTML a-la early Angular 1. 3. HTML over the wire. All those ideas pre-date React and React won against them back in 2014.
  - nicoburns 3y ago
    There is also 4. The React model but with compiler support to improve the ergonomics (and with better static checks).
meiraleal 3y ago
Yes, I agree with him. What's the reason to use React? It is over-engineered and too complicated for no clear benefit. It takes longer to build an app using react just because you have to deal with things that are exclusive to react
- octagon2023 3y ago
  Try next.js. We have seen massive improvements in code quality and development velocity using v13/14. Our codebase is a mix of typical server rendered crud web and client only logic (web3). It feels like php without the bad parts. In particular react actions proved to be a major quality of life improvement.

troupo 3y ago

> They were pretty messy and felt like they did a poor job of encapsulation, ultimately. (At least at the time.) They are still messy. https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html

wayfinder 3y ago

As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do that in JS and every custom way you invent looks like trash. Doing something like this.shadow.innerHTML = `your HTML` with web components is terrible. document.createElement() is terrible. $('div').appendChild() is terrible. <script language="html" name="my-template"></script> is terrible. HTML(Div(Strong(text))) is terrible*. Storing templates as JSON and writing a one-off loader is terrible. <div style="display:none">template</div> is terrible. I've done it every possible way and they are all terrible. JSX fixed all that. The biggest previous attempt at something like JSX was E4X where you could embed XML straight into JS, which was kinda nice except it added the entirety of XML and its complexity. I creamed when it came out but then I tried it and it was not it. (E4X ended up surviving a little longer in Adobe Flash though.) E4X: https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML *This is what JSX compiles to behind the scenes.

breadwinner 3y ago
What if you could have the best of both worlds? What if you could use JSX templates and use standards-based web components? You can. Here's an example of using a web component in a JSX template (look for zx-listeditor): https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/Views/DemoPage.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo... Here's how the web component is implemented, also using JSX: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
- wayfinder 3y ago
  Not saying that you can't. I'm just explaining why React won and how it was blatantly obvious that it was going to win when it came out (that is, if you were there in the before-times).
  - breadwinner 3y ago
    Agree with you on that. React was a breath of fresh air compared to what we had in the before-times, such as Angular, Ember and so on. The canonical demo of Ember.js was two-way data binding. React did away with two-way data binding and introduced JSX syntax. This was a major step forward. Code suddenly looked sane and readable. Then they took two steps backward when they introduced hooks. Code went back to being unreadable.
- chatmasta 3y ago
  Also, the entire OP article is demonstrating this... I'm not sure many of the comments here actually read it...
zelphirkalt 3y ago
Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in separate files, or making use of a DSL, that treats HTML as structured data, say for example SXML. Also there are issues with that custom HTML-look-alike preprocessor, because you cannot write class="...", because then somehow it gets syntactically confused, because "class" is now a keyword in JS. This all feels rather half-baked. Why can't the parser/prprocessor distinguish between that "class" and "class" in JS source code? We can have reusable HTML snippets (some may call components) with normal templating engines easily. Look at something like Jinja2 and how to reuse blocks and macros. Yes, some React component can encapsulate its own interactive behavior. That is only because we are already writing JS though, so we can already write frontend logic. But do we actually want that? Coupling state and behavior? I think we might not. Writing a script that gets served only on those rendered templates, where it is needed is not so hard either, when using a normal templating engine.

deleted 3y ago

[deleted]

gustavus 3y ago

It sounds like the common thing that someone in the Frontend space would say, that a technology less than 5 years old says the technology is old. I prefer the terms stable, mature, or hardened. People use React/Angular because large products are forced to have a way to organize things across multiple developers and time. Now don't get me wrong I think these JS bloated websites are an abomination that have largely made the web worse and not better, especially since UX "engineers" feel a compulsive need to change the layout every 6 months and now even simply scrolling through a page involves 50 web requests, and takes a full 3 minutes to load the next page... but I digress.

tshaddox 3y ago

Fascinating that React simultaneously receives criticism as being 1) boring, old technology that has been around for so long that no one even remember why it was chosen in the first place, and 2) extremely fast-churning, bleeding edge software that is constantly changing and breaking because the JS community is more interested in chasing trends than building robust stuff.

pwdisswordfishc 3y ago
React has merely aged, not matured.
paulddraper 3y ago
Same people who say: 1) the ecosystem keeps chasing shiny tech that is constantly changing, not boring solutions 2) everything should be written in Rust

robin_reala 3y ago

React “won” because Facebook spent three years flying devrel to every web conference on earth to persuade other people that Facebook’s problem space was applicable to small agencies. Back in reality, React is slow and massively overbuilt for the majority of stuff that most people are building. If you played around with Web Components a long time ago then you probably played with the v0 spec, which was somewhat different to the current version.

troupo 3y ago
> React “won” because Facebook spent three years flying devrel to every web conference You do know that Google sponsored and ran things like Polymer conf? That it builds lit? That Google's devs have literally overrun and overruled most web specs committees? That Google has spend hundreds of millions of dollars promoting Web Components? And yet here we are.
- robin_reala 3y ago
  Polymer was incredibly even slower that React and even more overbuilt, and it had the added negative that it tried to enforce a visual style as well, which was too much for most people. Google couldn’t spend its way out of that hole. As for Web Component specs, we got v1 because of Apple and Mozilla: Google would happily have stayed with v0.
- pseudosavant 3y ago
  I'm glad to have read this today. I'm going to look into how I could use web components in my next side project. I'd really like something that worked easily with SSR and client-side, maybe using htmx. In retrospect, I think I avoided web components because of Google and their aggressive dev relations pushing Polymer. It felt so one-sided that it didn't seem like a web standard. It felt more like a Google "standard" like NaCL. Having to ship Polymer to support non-Google browsers felt even more heavy weight than React.
  - troupo 3y ago
    > I'd really like something that worked easily with SSR and client-side Then you should skip Web Components :)

menssen 3y ago

"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the application state.* I kind of feel like people get tripped up by the fact that "virtual DOM" and "shadow DOM" sort of sound similar. They have literally nothing to do with each other. The React "virtual DOM" allows you to *completely re-output the entire user interface* on every state change, which is not possible with any other design pattern, and is not possible without a framework, because actually re-rendering the entire tree on every state change isn't performative (or usable). Anybody who is advocating an alternative to React needs to do one of two things: (A) Make a convincing argument that a different design pattern is better. Some things we've tried, which most people think are worse: 1. Using the DOM as your data model (jQuery) 2. Manually writing virtual representations of every view (Backbone) 3. Auto-magically two-way binding some data structure with the DOM (Angular 1) 4. Observables (Ember, maybe Angular 2+?) (B) Advocate a framework other than React that uses the same pattern as React, but improves the usability. I think the two places there is the most room for improvements are: 1. Animations 2. useEffect() in general I have not seen anybody successfully do either A or B. Recommended reading: https://acko.net/blog/get-in-zoomer-we-re-saving-react/ https://acko.net/blog/get-in-zoomer-we-re-saving-react/

techpression 3y ago
I would say SolidJS does everything better than React while keeping with the same general mindset. React spent way too much time worrying about DX to the point that now DX is really bad. Fine grained granularity is such a breath of fresh air to work with after the very large and very heavy brush that is the React “render the world every time anything changes” method (yes they try to be smart about it, but so far haven’t succeeded, the next compiler might solve it, but then we’re back to a black box of incomprehensible code soup to debug).
- vmfunction 3y ago
  Thank you. Finally someone mentions Solid, it got all the good part of React, and none of the bloated parts. Personally, JSX is the mainly thing that makes React attractive. As JSX is just modern E4X. It really ought to be put into the ES standard again instead of this Web Component stuff. Another good JSX implementation (SSR) is: https://nanojsx.io https://nanojsx.io If you just want something light JSX, then this seems the way to go for now.

mustaflex 3y ago

Web components are a bit verbose by themselves but used with a library like lit.js you can build a framework agnostic component library. Angular and Vue support WC out of the box and they have a wrapper for React. I think the only thing missing(or not mature enough right) now is SSR. There are probably libraries other than lit.js that take the pain out of writing WC. I was skeptical at first but I've seen in production a lit.js/WC component library used with React and Angular successfully in the banking sector and it works surprisingly well.

austin-cheney 3y ago

As a full time JavaScript developer of 15 years it boils down to 2 reasons. 1. Eases candidate selection. There is no uniform baseline of competence in software generally and certainly nothing exists for web development. Its often the blind leading the blind, so outsource everything to a tool. At the very least, people that cannot use that tool are then not qualified to be there if you discount absolutely everything else. After all, it isn't as though employers are willing to train new developers to perform as required, so they need to turn this into a commodity as much as possible. 2. Composition. Most of the people who do web development cannot write original software, plan, or organize at the level required by modern applications. Employers still need people to do trivial things to get text to appear on screen. As the demand for these trivial tasks still exists employers still need to hire people to do this work, and so they attempt to outsource the parts that require higher intelligence. These beg the obvious question: What will happen when employers realize they don't need to overpay developers to do this work when half of it can be pushed into content management systems and the other half can be pushed into AI?

djrenren 3y ago

As someone who just had to answer this for my startup, the value of React is that it's robust and immensely hire-able. If you're looking for frontend developers, the one thing you can always expect is at least passable React knowledge. Everything else, even if it has a better technical fit for your project, is likely riskier for your organization.

pseudosavant 3y ago
Some of the most productive teams I've worked with (not as a dev) have been for tech stacks I personally don't enjoy using. Java, .NET/C#, React, etc. In practice, I'd rather quickly hire a local senior Java/C# dev for 1X than scour the interwebs to hire a Golang dev that requires relocation for 1.5-2X. If I was going to learn a language though, I'd probably learn Golang. Their rate is so much higher.
Draiken 3y ago
I find this argument so absurd. If you know JavaScript and basic programming, you can use any front-end framework. We're hyper-specializing people in a specific framework that then don't even understand the basics of JavaScript itself. I already find the divide between frontend and backend developers unnecessary the majority of the time. This takes it a step further and in turn creates monstrosities like the leftpad debacle. Can we stop with this nonsense? Hire good developers and let them spend 5 minutes to learn the god damn framework of the week. If your hire can't learn React in a week, I have some bad news for you.

mattlondon 3y ago

Would anyone pick react these days, if they did not already use it/know it/think-it-is-what-they-should-use-because-everyone-else-does? I think that is the point. The original "pitch" for react in my mind was that it was lightweight and simple. I don't think you can say that any more, and I think a lot of rough edges have been identified (e.g. hooks fiasco, app state management, dependency-hell etc to name just 3) after years of use. It's the same cycle that always happens. Old thing ossifies and grows fat overtime trying to be all things to all people. Then some new thing appears that starts with a clean slate and no prior expectations that proves popular as a result

JacobThreeThree 3y ago
It's as you describe, but also the spec and browser support landscape has changed.

davedx 3y ago

React isn't legacy technology. What a perfidious statement. I can easily justify the reasons I still use React, but I can't be bothered writing it out every time some gimmicky front-end tech hits HN.

sesm 3y ago
Every alternative to React roughly fall into one of 3 categories: 1. Go back to reactive templates. 2. Sprinkle directives over plain HTML a-la early Angular 1. 3. HTML over the wire. All those ideas pre-date React and React won against them back in 2014.
- nicoburns 3y ago
  There is also 4. The React model but with compiler support to improve the ergonomics (and with better static checks).

meiraleal 3y ago

Yes, I agree with him. What's the reason to use React? It is over-engineered and too complicated for no clear benefit. It takes longer to build an app using react just because you have to deal with things that are exclusive to react

octagon2023 3y ago
Try next.js. We have seen massive improvements in code quality and development velocity using v13/14. Our codebase is a mix of typical server rendered crud web and client only logic (web3). It feels like php without the bad parts. In particular react actions proved to be a major quality of life improvement.