28 ms·

React is 10 years old

190 points by ggregoire 3y ago

MuffinFlavored 3y ago
I feel like there are 2 Reacts (at least 2 that I know of, if not more). I learned jQuery long ago, then how to get most of what I wanted done via document.querySelector/etc instead since it was more "lightweight", then I learned React "class components" with render() and componentWillMount() and it was a big leap forward. The "major breaking changes" (semantic versioning wise) to move components to functions (instead of implying it's just a class with render()) and then hooks on top, it almost invalidates most of what I learned about React initially. Which is fine. The community reserves the right to grow however they want. I was just surprised when I recently revisited it. The only common concept was basically JSX and "view/render state/props + actions on events". I don't think many would agree to this but I'd argue the changes are so radical that they almost should've called this new React something entirely different. It would help. Saying "I know React/I have React experience" is basically in need of nuance like "I have React in 2018 experience, and 0 React in 2023 experience, therefore I don't actively/actually know current React best practices or how to even do a small TODO hello world list example".
- shams93 3y ago
  This is a kind of career violence intentional radical constant change such that experience doesn't matter maybe those of us pushed out of industry over react should hit meta with a lawsuit.
  - SketchySeaBeast 3y ago
    I can't tell - is this satire? Good faithing it - this could only be (partially) valid if the old ways didn't work, which they still do. If you've been pushed out, you haven't been pushed out of the industry because of the change.
- baron816 3y ago
  > I was just surprised when I recently revisited it. You can STILL write React like you used to (with class components). There haven’t been any major breaking changes. The transition was very slow. It was only recently that they even changed the docs. You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was.
  - pier25 3y ago
    > You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was. Wouldn't you expect jQuery to keep using the same fundamental methodology a couple of years later?
    - bobthepanda 3y ago
      I mean, Java was the stereotype of boring enterprise language, and has certainly changed a lot in the last ten years in terms of its shift towards functional-friendly programming.
      - pier25 3y ago
        How is this even comparable? Not only React changed completely almost overnight, but the changes in the methodology were fundamental.
        baron816 3y ago
        This is just blatantly untrue. The changes were definitely not overnight. Not even close. You’re still free to write React in the old way. The docs were there for half a decade. If they had just made a different project, we’d still be talking about the same thing. You would still be complaining that things changed and you didn’t feel like bothering to learn a new thing.
        bobthepanda 3y ago
        So are the Java 8 changes? Java lambda functions, streams and futures look nothing at all like traditional Java methods and threads, yet you're still free to write them, but nearly every Java Stack Overflow question has a dedicated Java 8+ answer because it is so different.
- butterfi 3y ago
  This is such a common problem these days. I have almost 15 years of experience with another framework, but the latest iteration is almost a complete re-write and most of what I knew in the past isn't that helpful. To say I have "x" years of experience doesn't really acknowledge my current level of understanding.
- Capricorn2481 3y ago
  There are no breaking changes. Class components are still supported and used at Facebook
  - pier25 3y ago
    Class components are deprecated. They only appear in the legacy section of the reference. https://react.dev/reference/react/legacy https://react.dev/reference/react/legacy
    - rozenmd 3y ago
      > These APIs are exported from the react package You can still write React the old way.
      - trgn 3y ago
        Sure. But search anything about React, and you'll see examples in hooks. I don't even understand the reason why class-based is "legacy". Why are hooks inherently better? Code-reuse is a factoring concern, not a paradigm concern. And component-life-cycle bugs are now replaced with nearly impossible to understand callback stacktraces.
        Capricorn2481 3y ago
        That doesn't mean classes are deprecated, it means people prefer hooks, and I understand why, as someone that codes in both. It's like saying "All Javascript things I search are only in ES2020." It doesn't mean javascript is deprecating features.
    - andrewmcwatters 3y ago
      Oh also certain concepts and strategies are only written about in the legacy documentation. Good luck new devs!
      - zoover2020 3y ago
- devjab 3y ago
  I think it’s more a matter of how the JS community has grown in general. The whole “class” thing is something a lot of us brought into it when we came from other OOP languages, but in 2023 it is very rare that it is “better” to build a “class” than to simply build the functions you need. As far as I know you can still trundle on with some of the old react, but at the same time, things change. It’s not like you’re coding C# similar to how you were 10 years ago either. I know that having been away from it, it was interesting to see everyone using “var” instead of types as an example.
  - yamtaddle 3y ago
    I dunno... when you're building a hierarchical tree of nameable components and several, ahem, instances of each nameable component might exist, and these need to respond to signals, that seems like a case when it's non-crazy to use classes.
    - deleted 3y ago
      [deleted]
    - tshaddox 3y ago
      But that’s not ever what you had in React even when using JavaScript class components.
  - andrewmcwatters 3y ago
    Classes and types and methods exist for a reason. They're not "old" you don't "grow beyond them" anymore than you "grow beyond" functions, constants, threads, or files. Try stepping outside of JavaScript for a while, broaden your experience.
    - c-hendricks 3y ago
      So you're just gonna ignore that whole "the JS community" bit then, ok. Is this what $200/hour consultancy looks like?
      - 3y ago
- pier25 3y ago
  > I don't think many would agree to this but I'd argue the changes are so radical that they almost should've called this new React something entirely different. Absolutely and I've been saying the same thing for years. IMO it was an extremely irresponsible thing to do considering React is critical infrastructure at this point. And by completely changing the methodology they made obsolete A LOT of educational content (books, tutorials, videos, etc) in an instant. I'm sure people making money of React education were very happy with this. Don't get me wrong, I'm not against evolution. But if you're going to make such a drastic change just create a new project. Plus I wonder what other improvements/changes they could have made if they had started from scratch.
  - davedx 3y ago
    Nobody is forcing you to use it. The react devs made a bunch of code migration tools, used semantic versioning, slowly deprecated old APIs over multiple versions, maintained vids and documentation. Honestly compared with some projects they handled the changes and evolution of the API extremely responsibly.
    - andrewmcwatters 3y ago
      People are forcing you to use it. It's called employment. God forbid you're a principal running into some junior engineers and they don't understand that you've forgotten more than they know, and the migration to functional components is just another part of your extended career timeline.
      - plugin-baby 3y ago
        If you’re a principal, just ask your juniors to explain their useEffect()-based mess. When they can’t, mandate class components.
        ipaddr 3y ago
        Then you get a security audit that you are not using the latest whatever and c-suites panic
- nfRfqX5n 3y ago
  the core concepts are the same. the implementation details have changed, but I think it's a stretch to call it a radical change. you could probably learn how to convert a component from class -> functional in a few hours.
- frou_dh 3y ago
  Is it really that much of a crisis to have the "0 React in 2023 experience ... don't even know the modern hello world" when one can just spend some time on their (excellent) documentation site and get back up to speed?
- tunesmith 3y ago
  I sometimes feel like there are three. The class components way, the hooks way that everyone has been doing it up until a few months ago, and the hooks way that the beta docs say you should do it. Maybe those last two aren't different enough, but the clashing philosophies around useEffect are enough to require massive refactors. EDIT: I'm referring to how the proper use of useEffects is to almost never use them. They're for side effects, and they're not a tool to just "re-render when these dependencies change". But to do this right, it requires a re-wiring of the mental model of how to do React, at least for many people I've come across.
  - Apotheos 3y ago
    What's the new way as of a few months ago? The docs way?
    - rkuykendall-com 3y ago
      They may be referring to React 18 + Strict Mode meaning all useEffects can be called as many times as React wants. People before were writing code where useEffect on [] worked like onMount and was only called once.
      - andrewmcwatters 3y ago
        What's so infuriating about that is the documentation basically told people, hey instead of doing this, use useEffect the way you were using these methods. So are the users wrong, or did you screw up?
        deleted 3y ago
        [deleted]
        c-hendricks 3y ago
        If you're ignoring dependencies that should be on a call to `useEffect`, you're just making room for bugs. If you're not properly tearing down what you're doing in an effect, you're just making room for bugs. These have always been true of useEffect.
- kdrag0n 3y ago
  React Server Components (RSC) feels like the third React. https://nextjs.org/docs/getting-started/react-essentials https://nextjs.org/docs/getting-started/react-essentials
  - __float 3y ago
    I'm not sure I agree with this. It's "different" in that you don't need to learn the intricacies of some new data loading and state management library (we've seen _so many_ of these over the years!). But the concepts themselves are much closer to "just plain React".
    - kdrag0n 3y ago
      True, not as radical as the transition to hooks.
- nawgz 3y ago
  I fully disagree. It's the exact same internal mechanisms lending themselves identically to rerender semantics and so on. They were exposed with new names and access methods, but enabled you to perform virtually the same component update logics, except with a few antipatterns made more difficult. HOWEVER it is also fully backwards compatible, you can run these old versions. So, what stayed the same? * Could still use classes * Still had the same props & state semantics * Components still could own state and receive props * Some renamed code paths were used, a couple of the "componentShouldRender" style ones were dropped to prevent programmers making fatal errors * Still wrote the same markup * Still could use the same libraries I never really understand this complaint; React achieved gold standard backwards compat. Either that or my 2016 era tools building in 2023 on the newest React with old ass libraries would've caused a lot more pain points!
- paulddraper 3y ago
  Akin to JS replacing callbacks with async/await: 1. You can use both styles, even interchangeably. 2. The latter is superior. Async/await allows you to write asynchronous code in a synchronous style. Hooks allow you to write stateful code in a stateless style.
deleted 3y ago
[deleted]
epolanski 3y ago
Whatever one feels today about React, there is no doubt that it has given functional and declarative programming an important light. Not in the sense that React itself is functional or declarative (it isn't albeit its roots are in Ocaml), but the style of programming it introduced to many millions of web developers made a sizeable chunk of them interested in fp and many of those percolated to strictly typed FP in TS, Elm or Haskell. Pretty much every major fp language has tried to implement their own declarative UI after React's success, be it for terminal applications or native development.
- davedx 3y ago
  Yup! I actually discovered react via Om, which lead my down a delightful mind bending journey into ClojureScript and lisps. Awesome
- noman-land 3y ago
  I think these two are React's biggest lasting contributions. Describing UI in a declarative way, and introducing many functional programming concepts to the world's JS devs. I myself fell in love with functional programming in part because of many of the concepts I was introduced to by the likes of Dan Abramov and company. It led me down paths of research I wouldn't have known to go down, all the way back to the dawn of computer programming.
  - zuprau 3y ago
    > React's biggest lasting contributions. Describing UI in a declarative way I feel that AngularJS (v1) did that years before React, and maybe even other MVC frameworks before that. I can't think of anything React brought in that earlier frameworks didn't already have in a form or another. Maybe hooks? Arguably the worst and least performant part of React. It only popularized "HTML-in-JS" but that has always been possible via strings or file imports. Even template pre-compilation was part of Backbone or Ember (I don't remember which)
    - brundolf 3y ago
      > I feel that AngularJS (v1) did that years before React, and maybe even other MVC frameworks before that. Angular markup lives in templates which are used to generate and update the UI, while React markup lives in expressions which evaluate to values. This is a subtle but key difference. I would argue React isn't even an MVC framework (though it sorta pretended to be one for a while)
memonkey 3y ago
I have been using React for almost those 10 years. When I first started out, I was writing Java for Android. I then got a contract position writing AngularJS 1.2. A couple years later, Angular 2 would be released but by then I was already beginning to write small React apps. I also made a small app with React Native for an audio company. By 2016 I was working at a popular Fortune 100 company on the first team to migrate their existing JSPs to React. By the time I left that place, React Hooks were in beta and gaining steam. I was lucky enough to work with a Facebook Alumni who hated React, so we used Vue. It felt like a more opinionated React in some cases, but I really enjoyed the experience. Now I'm back to React and a lot of the same problems exist. Some things are just hard or extremely tedious to do. Some places rely heavily on external libraries which cause so much bloat to the system it can feel slow (even when it's not). Most places I have been to are extremely opinionated about how their app is built, despite it being the same thing (for example, there are 20 different ways to build an e-commerce site). But the places I have enjoyed the most had a hackerish culture, so people weren't insanely opinionated so long as you got the job done, which I feel like React is great for. I have unfortunately not used NextJS, but I have used Nuxt which has been wonderful. I'm semi in between jobs right now and have been looking at potential offerings, and I haven't seen a huge need for these frameworks yet. If NextJS is anything like Nuxt, I think I'd be happy to work in them. But I may also look for the places that offer a completely new experience.
- theironhammer 3y ago
  SolidJS? It uses Signals in its Reactivity system and there's no virtual DOM. It has some syntax similarities to React making it easier to transition. It uses JSX and is quite performant.
  - steve_adams_86 3y ago
    I love Solid. In the last month or so I went from curious to fairly certain I’d prefer to work with it over React. I’d used it before to trial it and explore differences, but never actually built something. I used it with XState (state charts) to build a version of Minesweeper which uses the receptionist pattern to orchestrate actors, which was pleasantly unnecessary, and I really loved it. Although I have around 8 years of experience with React, Solid somehow made the process easier in some regards. React — despite being excellent in many ways — has a few sneaky foot guns that I still manage to wander into when trying new tools and patterns. Solid on the other hand was quite friendly. Ironing out anticipated performance issues was mostly an idea and never became necessary. In React I did need to tidy up some redundant renders and fix state synchronization due to out of sync effects. I’m currently job searching and totally wouldn’t hesitate to work with a team that uses Solid. But, React is good too. At the end of the day I just love making things people enjoy using.
chilmers 3y ago
10 years, and yet any discussion on this site about front-end development will be filled with people complaining about how front-end development practices change too quickly.
- dlisboa 3y ago
  There's still truth to that. React has changed a lot in those 10 years. So much so that old code is unrecognizable and would be an anti-pattern today. And that's only React, the ecosystem around it also has changed significantly.
- karaterobot 3y ago
  To be fair, React itself has changed in fundamental ways multiple times throughout that period. And it's not like React is the only thing you need to worry about when building a React app: there's a whole ecosystem of tooling and libraries that you rely on which are constantly moving.
  - SenHeng 3y ago
    What common, popular and highly used technology hasn't radically changed in the last decade? Back in 2015, $JOB was evaluating upgrading Java 6 to Java 7 or 8. What is now? 20? I last touched php in 2012, which was 5.4 or 5.5 I think. People were still arguing that Laravel couldn't replace CodeIgnitor, or that we should stick with Symphony or Zend. Change is the only constant. In that respect, React has been relatively sane.
    - karaterobot 3y ago
      As you know, Java and PHP are languages. React is just a framework, and by design not a particularly robust one on its own. It just provides a front end, everything else has to be plugged in separately, learned, maintained, and ultimately cast aside and forgotten separately. If you're a React developer, you'll have noticed that Javascript itself has changed a lot in ten years. The state management library your company uses has probably changed too. Compared to ten years ago, you're now writing fully-typed JS with Typescript. The additional libraries for authentication and persistence, and so on, have all changed as well. You may be using a graph-based database now. You may have a different JS runtime on the server. All of your tooling has probably changed, as has your IDE. Whether React itself has or has not changed more than other frameworks, I can't say. But, I'd bet the stack used by the average front end developer has. Please recall that the original comment we're both talking about was referring to complaints about how much the front end has changed, with React only being the context of the comment, and not the sole cause of the complaint.
mkl95 3y ago
I once tried to learn what you would call "proper React", only for some Googler to tell me I wasn't even using React. Despite the fact I was using it back when hooks weren't a thing, and I had built multiple apps with it. There are many things I can stand in a community, but gatekeeping is not one of them.
TeffenEllis 3y ago
I think React really was revolutionary when your choices were jQuery, Backbone, or even Angular 1. I remember trying to convince my team that React was the next best thing when it first came out. Skepticism was everywhere — especially around JSX. So we compromised and wrote our components with CoffeeScript… The sheer number of flux frameworks were a testament to how underserved the state model was at the time. And without consistent support for async/await to make Promises work well in an app, data fetching and state was the worst part of React. I’ve always despised Redux and the circus that came with thunk generators. MobX made things a little bit easier. And Baobab was a fun concept to bring Clojure-style cursors to JavaScript. It wasn’t until React shipped the context API and hooks that I felt the problem of, “how do I get this state from up here to down there?” was truly solved. Personally, I’ve wished I could quit React for something like native Web components, but I feel like I’d be back at square one with state management and stringly-typed templates. Maybe Lit-HTML will get there one day!
- kypro 3y ago
  Out of interest why did you despise Redux and Redux Thunk? Imo Redux did solve the problem of state management and I always thought it was quite an elegant solution personally. Hooks and the context API are just different ways to manage state (and many would argue better). Do you disagree?
tambourine_man 3y ago
I was blown away when I learned the concept of the virtual DOM and how diffing it could be made fast. But as practical tool, React has been a regression for the web IMO.
- Kilenaitor 3y ago
  How has it been a regression for the web?
  - tambourine_man 3y ago
    I don’t think direct DOM manipulation was ever a problem, if done thoughtfully. If keeping track of state is so hard that requires a library to render it, perhaps you have too much state for a single view. It’s ultimately a UI/UX design problem, as it will be hard on your users as well. I find the way they mix markup with code distasteful, and lots more.
    - 5Qn8mNbc2FNCiVV 3y ago
      It's less keeping track of state is hard and more keeping state in a medium that isn't suitable for it (the DOM). The argument of too much state in a single view is nil by what applications are built nowadays (and also expected). Obviously it was already possible without the rise of declarative rendering frameworks but it made it more accessible to the majority of developers and thus raising the bar. If you do however find the way markup and code is mixed feels distateful, I'd suggest to not look at any templating engine in the last 20 years because that's what most of them already did.
      - tambourine_man 3y ago
        If you’re building a Gmail competitor, by all means, go with React, build your own solution, whatever. If you need to choose the color of a shirt with 3 sizes, perhaps it’s an overkill. Regarding templating engines, I use PHP :)
    - yazaddaruvala 3y ago
nfRfqX5n 3y ago
big milestone for the team, congrats to all of the contributors!
roschdal 3y ago
What will succeed React?
- FactualActuals 3y ago
  I don't think React will be replaced for a very long time. The only library that has somewhat similar adoption rates to early React is Vue. I personally prefer Vue over React and I use it at work. But I would be happy using React as well if the choice was given to me. Vue3 + Composition API just makes sense to me.
  - oblak 3y ago
    Vue 3 + pinia is simply an amazing experience. Nothing is shoved down your throat I tried getting back to React but Vue makes so much more sense. Feels like in the old days because all you do is write your code instead of dealing with a library and its ways.
    - bricss 3y ago
      Absolutely agree! Vue + Pinia = This is the way ©
- deleted 3y ago
  [deleted]
- kristopolous 3y ago
  Sanity hopefully
- elforce002 3y ago
  It'll be a long time before something comes along and dethrone react. React ecosystem is too vast and the community is large and engaged. Nothing comes closer to React atm. Other than that, prob. lit-dev (with time).
  - azangru 3y ago
    > Other than that, prob. lit-dev (with time). Yes. Nothing excites me more than web components and moving closer back to the browser. Somehow, it feels more exciting than server components, signals, compilers, resumability, etc. etc.
itsuka 3y ago
To celebrate React 10th anniversary, Next.js interviewed Andrew and Sebastian from React core team: https://www.youtube.com/watch?v=g5BGoLyGjY0 https://www.youtube.com/watch?v=g5BGoLyGjY0
kamaal 3y ago
As a backend developer who didn't 'get' web development for many years. Learning react changed all of it. React was revolutionary, and just clicked for me. Combine this with frameworks like Material UI, Patternfly and many others and its almost like you have some super power. These days I can build fairly big sites with lots of stateful components quickly. Most of my use cases is to build internal tools. But the pace with which once build things in react and its over intuitiveness just makes it special. React is one framework which Im sure will be available for long time to come! Thank you React dev team.
- plugin-baby 3y ago
  Similar feelings here. To me, React was one of the first approaches to web frontend development that really promoted good engineering practices.
- rchaud 3y ago
  As someone who started in front-end and was deluged with 2000s conventional wisdom like "don't use inline styles" and "keep scripts separate from your CSS and HTML markup", React made absolutely no sense.
  - june_twenty 3y ago
    Embrace it for awhile and it really is special. You've a function that returns JSX which is your HTML where you can use Javascript to reference functions/variables (e.g. the state variables) One of the key parts is that you can break it all down into different files/functions that return jsx so you can isolate complicated parts
  - Izkata 3y ago
    Even if people understand this at a conscious level, it's rarely explained: > and "keep scripts separate from your CSS and HTML markup" was for documents, not interactive applications, with the goal being that a document could be reformatted through CSS for multiple different displays. The earliest example I can recall was web vs print (as in, in the browser go File -> Print; you can specific different CSS rules so the page prints differently than it shows in the browser). Screen size / mobile displays are other examples that came later. React on the other hand is great for interactive applications, which have always worked component-style - a checkbox or a dropdown in a native GUI would be used multiple times and knows how to style itself, for example, which is the same as what a React checkbox or dropdown would do. > "don't use inline styles" This rule was broken simply because there wasn't a better way to do the component packaging at the time. Nowadays we have CSS Modules, which separates them again.
revskill 3y ago
10 years and state management is still a mess.
- latchkey 3y ago
  I'd say it is less about being a mess and more about the fact that there are 1000 projects that do state management in totally different ways and it is nearly impossible to figure out which one to use. Even if you pick one, you don't find out that it has some critical bug until you're half way through your project and it is too late to swap it out. So, you end up coming up with some hacky workaround that creates a lot of brittle code and breaks every time you upgrade some other non-related component of your application.
cloudyporpoise 3y ago
So now all those ridiculous job postings requiring 10 years experience with React finally make sense?
- revskill 3y ago
  It should be 15 years of experience now.
beders 3y ago
10 years and we are still building custom forms from the same primitive building blocks. And with react having to fudge with the state of DOM input components, it's been a messy ride. And yet, the idea of describing your UI and have a library figure out what needs to be repainted has been liberating. React certainly wasn't the first, but it certainly was the most elegant one at the time. I wish React would split up and go back to the roots: Have it deal with rendering - and nothing else. Have optional companion projects that deal with the various forms of state and side-fx.
- latchkey 3y ago
  I've been maintaining a project for 4 years now (~40k downloads/mo on NPM, 400+ stars) that is simply glue code between a React form management library and a React UI library. It was really hard to get right, still isn't perfect, and over the years has required several major upgrades to keep up with changes in all three. Luckily, I have very good unit tests and snapshots that ensure upgrades don't break things. You'd think it would be easier, but it isn't. I really wish React would just own the low level forms stuff and get rid of the need for a 3rd party form management library. That said, because it is frontend JS, there are 1000 different ways to bike shed this problem and because it is form stuff, there is no one solution that fits all use cases.
  - teetertater 3y ago
    Which one? This sounds like it could be useful for me
    - SCUSKU 3y ago
      After some digging I believe it's this one: https://github.com/lookfirst/mui-rff https://github.com/lookfirst/mui-rff
      - teetertater 3y ago
        Cheers
boredumb 3y ago
React is really good for helping create giant SPA apps for the web. Unfortunately 99% of things using react aren't or shouldn't be SPA apps and now otherwise trivial applications are orders of magnitude more complex in their implementation and much heavier on bandwidth than necessary.
adverbly 3y ago
Finally all those job postings asking for 10 years of React experience can be filled!
ggregoire 3y ago
As someone who worked with jQuery (15 years ago), then Backbone.js, then Angular 1, then React (for the last 6 years or so), I honestly feel like React is here to stay. It solved all the pain points I had with the previous frameworks when working on complex and massive code base. I have a level of productivity I never achieved before. I never have to check the docs, I can't remember last time I thought to myself "why is this not working" or "how am I going to do that" or "what's the syntax/arguments of X". It is amazingly simple, intuitive and powerful. Most of the time I'm just reusing components I coded years ago, gluing them together to develop a new app that would have taken me days with the previous frameworks.
- nailer 3y ago
  > As someone who worked with jQuery (15 years ago), then Backbone.js, then Angular 1, then React (for the last 6 years or so), I honestly feel like React is here to stay. That sentence didn't end how I expected it to. Personally - coming from a similar (jQuery -> Knockout > Backbone > Ember > Angular 1 > React > Svelte) background - I feel React has gone the same route as the others - rose quicky, dominated, and will never go away, but no longer has any influence. The same will happen to Svelte in future.
  - graftak 3y ago
    React still has some tricks up it’s sleeve with great potential that are (often) missing in comparable frameworks. Error boundaries, async (server) components, suspense, portals, dynamically imported components, concurrent mode. Just a shame it takes/took forever for suspense to resolve.
bricss 3y ago
The only good thing about it, it's JSX! \m/ The rest is abomination ¬_¬
brundolf 3y ago
Can we agree it's not a "framework du jour" anymore? 10 years is a pretty long day
ExtremisAndy 3y ago
I wanted to like React so bad. I tried. I loved JSX and really appreciated the way you could reuse components. That was all very cool, and I was initially quite enthusiastic about it. But for whatever reason, I just could not figure out state management/hooks. Drove me crazy. It just always felt so unnecessarily complicated compared to other languages and frameworks I've used (even vanilla JS). Now, don't get me wrong: I fully accept the blame here. I am mostly self-taught (and not even the best 'student' in that context, haha) so I'm sure I just lack the overall knowledge base/big-picture understanding to really appreciate what they've done here. I hope I'll give it another shot one day, and perhaps with fresh eyes (and maybe with the help of a patient tutor), it will all 'click'!
- fendy3002 3y ago
  Hooks are complicated, but state/props is just right. Both enables you to enforce boundary and make contained components. If props and state are mixed / diluted, the component won't know when to do re-render and there'll be too many things to track, and there'll be many classic issues such as cyclic dependency and sluggish performance of two-way data binding. Hopefully you'll click on it someday
- deleted 3y ago
  [deleted]
- qudat 3y ago
  view = func(state). That’s the magic of react. The problem is no longer manually managing transitions between state but state itself. That’s why state management is so critical in the react ecosystem. Further, react has delegated two key features to userland: side effect and state management. Personally, I don’t want react to solve either of these problems because it’ll just turn into the disaster that is react server components: feature development driven by corporate interests (eg vercel).
  - june_twenty 3y ago
    I think that view = func(state) is an unnecessary complicated way to describe frontend development.
garganzol 3y ago
React is a text-book example of what a well-designed component model can do to a development cycle: a literal 5-20x productivity boost compared to the old vanilla JavaScript with jQuery and manual HTML manipulation. I was somewhat skeptical in the early days of React, but once static websites with rehydration became a thing, I was fully in. So much power.
- petilon 3y ago
  > a literal 5-20x productivity boost Not really. See a better way here: https://github.com/wisercoder/eureka https://github.com/wisercoder/eureka
  - yazaddaruvala 3y ago
    Sorry, I don't understand. Why is this a relevant link? "Lucene based search" vs React ? Seems like comparing trees to tractors.
    - petilon 3y ago
      See the web app. It is a more productive style of coding. Simple, and no need to deal with hooks and useState and useContext and none of that nonsense.
      - yazaddaruvala 3y ago
        Got it thanks for the context. I've read the web app and it seems to me it is just https://backbonejs.org/ https://backbonejs.org/ re-written in Typescript and allows JSX. I'm very certain Typescript and JSX will have improved the DX for Backbone like apps, but it doesn't address all of the other issues that teams had with Backbone. e.g. Cyclical event propagation, state stored in the DOM (i.e. appendChild is error prone in large multi-person code bases), etc. FWIW, the reason this works for eureka is highlighted best on this page: https://github.com/wisercoder/eureka/graphs/contributors https://github.com/wisercoder/eureka/graphs/contributors there is only a single author!
belter 3y ago
This whole discussion is concerning. So can somebody please point me to what is considered the modern React way? Educational resources, Tutorials, Docs please? Or is this modern way based on Beta documents? Edit: Is this the place to start? - https://react.dev/ https://react.dev/ From what I see from the tutorials...Why the closeness to NodeJS?
- tracker1 3y ago
  That would be a good place to start. Node.js is the defacto standard for JS based tooling, along with npm (node package manager) as a public module repository. There has been some evolution in the space. If starting a project, I'd probably start with Parcel.js [1] and from there use typescript/tsx instead of JS as a core. But that's just me. I also tend to do Redux the "hard way" closer to the original structure instead of redux-toolkit, as I find it's more overhead to learn initially but avoids a lot of additional complexity over time. 1. https://parceljs.org/recipes/react/ https://parceljs.org/recipes/react/
  - acemarke 3y ago
    Hi, I'm a Redux maintainer and creator of Redux Toolkit. Can you clarify what your concerns are with RTK? We specifically created it to simplify standard Redux usage patterns and eliminate common mistakes and bugs (like accidental mutations): - https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today We'd _like_ everyone who is writing any kind of Redux code to write that using Redux Toolkit, and we teach RTK as the default approach for using Redux. FWIW, we've had plenty of beginners tell us they were able to get started and be productive after reading through the "Essentials" tutorial in our docs, which walks folks through how to use RTK to build apps.
    - tracker1 3y ago
      I just find that the original reducer pattern(s) are easier to deal with in practice, especially when a project is slightly larger. It's often better imho, to understand the original patterns and some of the RTK approaches kind of muddy that understanding. I'm not saying that RTK is necessarily bad, but feel that when you're using some of those kinds of slices, or merging the constraints of the actions, mutations and the abstractions, it's harder to reason with. You aren't thinking about state as a whole, or often even your fragment. I'll sometimes mix a few things as well... The React features for provider/consumer, etc are sometimes easier to deal with as well. YMMV based on your own needs.
outside1234 3y ago
Congrats Dan and everyone on the React team. Great framework and has been an extremely productive decade for me personally.
koinedad 3y ago
React - you have a special place in my heart
xwowsersx 3y ago
I understand some comments here are saying that they feel React is here to stay. I have no basis to judge that, but putting that side, a question: what is it about frontend web development that seems to lend itself to neverending development of new frameworks or ways of building apps? I'm genuinely curious. Is there something inherent in developing web apps that just isn't quite solved, some way in which each new framework doesn't quite solve the problems (whatever those are)? Or is it just that the web (unlike mobile) is so open and there's so much development interest that this leads to endless efforts to improve on what came before leading to new frameworks all the time? Appreciate any thoughts on this!
- paxys 3y ago
  Coming from the backend, I feel the exact opposite. For any kind of frontend development you have a choice of ~3 clients, one programming language, a handful of frameworks, 2-3 of which have any real traction. Compare that to literally hundreds of programming languages that can run server side code, dozens of database engines, servers, all kinds of operating systems, hosting platforms...the web of backend tech is pretty much endless, and growing every day.
  - ern 3y ago
    You are correct, there have been changes on the back-end as well: containers and Kubernetes vs serverless. The endless tension between microservices and monoliths. Multiple IaC options. Onprem vs cloud (which cloud?), and associated cycles of disillusionment. The difference may be that once a particular back-end approach/architecture/design is adopted by a dev shop it remains stable over multiple projects. I’ve seen this in both consulting and in LOB roles. Because of this, I can hire a competent .NET developer and be confident that I can get them to be productive relatively quickly, since the foundation on which we write our code is stable, and I can invest in enhancing the developer experience to support them. In fact, an explicit criterion for every project in my teams is that we make it easy enough for any competent C# developer to ideally be able to open a small, but meaningful PR by the end of their first day on a project (if needed, I don’t treat it as a retention gate or anything!). They do have to adapt to our infrastructure and our ways of working, they don’t need to relearn the fundamentals of how to produce code. Whereas every time a new front-end project starts, there’s a near-compulsion to use the latest and greatest techniques. Everyone has to catch up, because of their previous experience being somewhat redundant. No one can invest in improving things for other developers, because they don’t have the time, and because any investment would be wasted, since it would be redundant beyond the current project (or two, if we’re lucky). I can’t really hire an Angular developer for a React project that starts tomorrow, and expect them to be reasonably productive immediately, despite them being competent in Typescript, CSS, Node etc. Heck, I wouldn’t even be able to hire a React developer who last did it 5 years ago, and expect them to be immediately productive.

190 points by ggregoire 3y ago

I feel like there are 2 Reacts (at least 2 that I know of, if not more). I learned jQuery long ago, then how to get most of what I wanted done via document.querySelector/etc instead since it was more "lightweight", then I learned React "class components" with render() and componentWillMount() and it was a big leap forward. The "major breaking changes" (semantic versioning wise) to move components to functions (instead of implying it's just a class with render()) and then hooks on top, it almost invalidates most of what I learned about React initially. Which is fine. The community reserves the right to grow however they want. I was just surprised when I recently revisited it. The only common concept was basically JSX and "view/render state/props + actions on events". I don't think many would agree to this but I'd argue the changes are so radical that they almost should've called this new React something entirely different. It would help. Saying "I know React/I have React experience" is basically in need of nuance like "I have React in 2018 experience, and 0 React in 2023 experience, therefore I don't actively/actually know current React best practices or how to even do a small TODO hello world list example".

shams93 3y ago
This is a kind of career violence intentional radical constant change such that experience doesn't matter maybe those of us pushed out of industry over react should hit meta with a lawsuit.
- SketchySeaBeast 3y ago
  I can't tell - is this satire? Good faithing it - this could only be (partially) valid if the old ways didn't work, which they still do. If you've been pushed out, you haven't been pushed out of the industry because of the change.
baron816 3y ago
> I was just surprised when I recently revisited it. You can STILL write React like you used to (with class components). There haven’t been any major breaking changes. The transition was very slow. It was only recently that they even changed the docs. You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was.
- pier25 3y ago
  > You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was. Wouldn't you expect jQuery to keep using the same fundamental methodology a couple of years later?
  - bobthepanda 3y ago
    I mean, Java was the stereotype of boring enterprise language, and has certainly changed a lot in the last ten years in terms of its shift towards functional-friendly programming.
    - pier25 3y ago
      How is this even comparable? Not only React changed completely almost overnight, but the changes in the methodology were fundamental.
      - baron816 3y ago
        This is just blatantly untrue. The changes were definitely not overnight. Not even close. You’re still free to write React in the old way. The docs were there for half a decade. If they had just made a different project, we’d still be talking about the same thing. You would still be complaining that things changed and you didn’t feel like bothering to learn a new thing.
      - bobthepanda 3y ago
        So are the Java 8 changes? Java lambda functions, streams and futures look nothing at all like traditional Java methods and threads, yet you're still free to write them, but nearly every Java Stack Overflow question has a dedicated Java 8+ answer because it is so different.
butterfi 3y ago
This is such a common problem these days. I have almost 15 years of experience with another framework, but the latest iteration is almost a complete re-write and most of what I knew in the past isn't that helpful. To say I have "x" years of experience doesn't really acknowledge my current level of understanding.
Capricorn2481 3y ago
There are no breaking changes. Class components are still supported and used at Facebook
- pier25 3y ago
  Class components are deprecated. They only appear in the legacy section of the reference. https://react.dev/reference/react/legacy https://react.dev/reference/react/legacy
  - rozenmd 3y ago
    > These APIs are exported from the react package You can still write React the old way.
    - trgn 3y ago
      Sure. But search anything about React, and you'll see examples in hooks. I don't even understand the reason why class-based is "legacy". Why are hooks inherently better? Code-reuse is a factoring concern, not a paradigm concern. And component-life-cycle bugs are now replaced with nearly impossible to understand callback stacktraces.
      - Capricorn2481 3y ago
        That doesn't mean classes are deprecated, it means people prefer hooks, and I understand why, as someone that codes in both. It's like saying "All Javascript things I search are only in ES2020." It doesn't mean javascript is deprecating features.
  - andrewmcwatters 3y ago
    Oh also certain concepts and strategies are only written about in the legacy documentation. Good luck new devs!
    - zoover2020 3y ago
devjab 3y ago
I think it’s more a matter of how the JS community has grown in general. The whole “class” thing is something a lot of us brought into it when we came from other OOP languages, but in 2023 it is very rare that it is “better” to build a “class” than to simply build the functions you need. As far as I know you can still trundle on with some of the old react, but at the same time, things change. It’s not like you’re coding C# similar to how you were 10 years ago either. I know that having been away from it, it was interesting to see everyone using “var” instead of types as an example.
- yamtaddle 3y ago
  I dunno... when you're building a hierarchical tree of nameable components and several, ahem, instances of each nameable component might exist, and these need to respond to signals, that seems like a case when it's non-crazy to use classes.
  - deleted 3y ago
    [deleted]
  - tshaddox 3y ago
    But that’s not ever what you had in React even when using JavaScript class components.
- andrewmcwatters 3y ago
  Classes and types and methods exist for a reason. They're not "old" you don't "grow beyond them" anymore than you "grow beyond" functions, constants, threads, or files. Try stepping outside of JavaScript for a while, broaden your experience.
  - c-hendricks 3y ago
    So you're just gonna ignore that whole "the JS community" bit then, ok. Is this what $200/hour consultancy looks like?
    - 3y ago
pier25 3y ago
> I don't think many would agree to this but I'd argue the changes are so radical that they almost should've called this new React something entirely different. Absolutely and I've been saying the same thing for years. IMO it was an extremely irresponsible thing to do considering React is critical infrastructure at this point. And by completely changing the methodology they made obsolete A LOT of educational content (books, tutorials, videos, etc) in an instant. I'm sure people making money of React education were very happy with this. Don't get me wrong, I'm not against evolution. But if you're going to make such a drastic change just create a new project. Plus I wonder what other improvements/changes they could have made if they had started from scratch.
- davedx 3y ago
  Nobody is forcing you to use it. The react devs made a bunch of code migration tools, used semantic versioning, slowly deprecated old APIs over multiple versions, maintained vids and documentation. Honestly compared with some projects they handled the changes and evolution of the API extremely responsibly.
  - andrewmcwatters 3y ago
    People are forcing you to use it. It's called employment. God forbid you're a principal running into some junior engineers and they don't understand that you've forgotten more than they know, and the migration to functional components is just another part of your extended career timeline.
    - plugin-baby 3y ago
      If you’re a principal, just ask your juniors to explain their useEffect()-based mess. When they can’t, mandate class components.
      - ipaddr 3y ago
        Then you get a security audit that you are not using the latest whatever and c-suites panic
nfRfqX5n 3y ago
the core concepts are the same. the implementation details have changed, but I think it's a stretch to call it a radical change. you could probably learn how to convert a component from class -> functional in a few hours.
frou_dh 3y ago
Is it really that much of a crisis to have the "0 React in 2023 experience ... don't even know the modern hello world" when one can just spend some time on their (excellent) documentation site and get back up to speed?
tunesmith 3y ago
I sometimes feel like there are three. The class components way, the hooks way that everyone has been doing it up until a few months ago, and the hooks way that the beta docs say you should do it. Maybe those last two aren't different enough, but the clashing philosophies around useEffect are enough to require massive refactors. EDIT: I'm referring to how the proper use of useEffects is to almost never use them. They're for side effects, and they're not a tool to just "re-render when these dependencies change". But to do this right, it requires a re-wiring of the mental model of how to do React, at least for many people I've come across.
- Apotheos 3y ago
  What's the new way as of a few months ago? The docs way?
  - rkuykendall-com 3y ago
    They may be referring to React 18 + Strict Mode meaning all useEffects can be called as many times as React wants. People before were writing code where useEffect on [] worked like onMount and was only called once.
    - andrewmcwatters 3y ago
      What's so infuriating about that is the documentation basically told people, hey instead of doing this, use useEffect the way you were using these methods. So are the users wrong, or did you screw up?
      - deleted 3y ago
        [deleted]
      - c-hendricks 3y ago
        If you're ignoring dependencies that should be on a call to `useEffect`, you're just making room for bugs. If you're not properly tearing down what you're doing in an effect, you're just making room for bugs. These have always been true of useEffect.
kdrag0n 3y ago
React Server Components (RSC) feels like the third React. https://nextjs.org/docs/getting-started/react-essentials https://nextjs.org/docs/getting-started/react-essentials
- __float 3y ago
  I'm not sure I agree with this. It's "different" in that you don't need to learn the intricacies of some new data loading and state management library (we've seen _so many_ of these over the years!). But the concepts themselves are much closer to "just plain React".
  - kdrag0n 3y ago
    True, not as radical as the transition to hooks.
nawgz 3y ago
I fully disagree. It's the exact same internal mechanisms lending themselves identically to rerender semantics and so on. They were exposed with new names and access methods, but enabled you to perform virtually the same component update logics, except with a few antipatterns made more difficult. HOWEVER it is also fully backwards compatible, you can run these old versions. So, what stayed the same? * Could still use classes * Still had the same props & state semantics * Components still could own state and receive props * Some renamed code paths were used, a couple of the "componentShouldRender" style ones were dropped to prevent programmers making fatal errors * Still wrote the same markup * Still could use the same libraries I never really understand this complaint; React achieved gold standard backwards compat. Either that or my 2016 era tools building in 2023 on the newest React with old ass libraries would've caused a lot more pain points!
paulddraper 3y ago
Akin to JS replacing callbacks with async/await: 1. You can use both styles, even interchangeably. 2. The latter is superior. Async/await allows you to write asynchronous code in a synchronous style. Hooks allow you to write stateful code in a stateless style.

deleted 3y ago

[deleted]

epolanski 3y ago

Whatever one feels today about React, there is no doubt that it has given functional and declarative programming an important light. Not in the sense that React itself is functional or declarative (it isn't albeit its roots are in Ocaml), but the style of programming it introduced to many millions of web developers made a sizeable chunk of them interested in fp and many of those percolated to strictly typed FP in TS, Elm or Haskell. Pretty much every major fp language has tried to implement their own declarative UI after React's success, be it for terminal applications or native development.

davedx 3y ago
Yup! I actually discovered react via Om, which lead my down a delightful mind bending journey into ClojureScript and lisps. Awesome
noman-land 3y ago
I think these two are React's biggest lasting contributions. Describing UI in a declarative way, and introducing many functional programming concepts to the world's JS devs. I myself fell in love with functional programming in part because of many of the concepts I was introduced to by the likes of Dan Abramov and company. It led me down paths of research I wouldn't have known to go down, all the way back to the dawn of computer programming.
- zuprau 3y ago
  > React's biggest lasting contributions. Describing UI in a declarative way I feel that AngularJS (v1) did that years before React, and maybe even other MVC frameworks before that. I can't think of anything React brought in that earlier frameworks didn't already have in a form or another. Maybe hooks? Arguably the worst and least performant part of React. It only popularized "HTML-in-JS" but that has always been possible via strings or file imports. Even template pre-compilation was part of Backbone or Ember (I don't remember which)
  - brundolf 3y ago
    > I feel that AngularJS (v1) did that years before React, and maybe even other MVC frameworks before that. Angular markup lives in templates which are used to generate and update the UI, while React markup lives in expressions which evaluate to values. This is a subtle but key difference. I would argue React isn't even an MVC framework (though it sorta pretended to be one for a while)

memonkey 3y ago

I have been using React for almost those 10 years. When I first started out, I was writing Java for Android. I then got a contract position writing AngularJS 1.2. A couple years later, Angular 2 would be released but by then I was already beginning to write small React apps. I also made a small app with React Native for an audio company. By 2016 I was working at a popular Fortune 100 company on the first team to migrate their existing JSPs to React. By the time I left that place, React Hooks were in beta and gaining steam. I was lucky enough to work with a Facebook Alumni who hated React, so we used Vue. It felt like a more opinionated React in some cases, but I really enjoyed the experience. Now I'm back to React and a lot of the same problems exist. Some things are just hard or extremely tedious to do. Some places rely heavily on external libraries which cause so much bloat to the system it can feel slow (even when it's not). Most places I have been to are extremely opinionated about how their app is built, despite it being the same thing (for example, there are 20 different ways to build an e-commerce site). But the places I have enjoyed the most had a hackerish culture, so people weren't insanely opinionated so long as you got the job done, which I feel like React is great for. I have unfortunately not used NextJS, but I have used Nuxt which has been wonderful. I'm semi in between jobs right now and have been looking at potential offerings, and I haven't seen a huge need for these frameworks yet. If NextJS is anything like Nuxt, I think I'd be happy to work in them. But I may also look for the places that offer a completely new experience.

theironhammer 3y ago
SolidJS? It uses Signals in its Reactivity system and there's no virtual DOM. It has some syntax similarities to React making it easier to transition. It uses JSX and is quite performant.
- steve_adams_86 3y ago
  I love Solid. In the last month or so I went from curious to fairly certain I’d prefer to work with it over React. I’d used it before to trial it and explore differences, but never actually built something. I used it with XState (state charts) to build a version of Minesweeper which uses the receptionist pattern to orchestrate actors, which was pleasantly unnecessary, and I really loved it. Although I have around 8 years of experience with React, Solid somehow made the process easier in some regards. React — despite being excellent in many ways — has a few sneaky foot guns that I still manage to wander into when trying new tools and patterns. Solid on the other hand was quite friendly. Ironing out anticipated performance issues was mostly an idea and never became necessary. In React I did need to tidy up some redundant renders and fix state synchronization due to out of sync effects. I’m currently job searching and totally wouldn’t hesitate to work with a team that uses Solid. But, React is good too. At the end of the day I just love making things people enjoy using.

chilmers 3y ago

10 years, and yet any discussion on this site about front-end development will be filled with people complaining about how front-end development practices change too quickly.

dlisboa 3y ago
There's still truth to that. React has changed a lot in those 10 years. So much so that old code is unrecognizable and would be an anti-pattern today. And that's only React, the ecosystem around it also has changed significantly.
karaterobot 3y ago
To be fair, React itself has changed in fundamental ways multiple times throughout that period. And it's not like React is the only thing you need to worry about when building a React app: there's a whole ecosystem of tooling and libraries that you rely on which are constantly moving.
- SenHeng 3y ago
  What common, popular and highly used technology hasn't radically changed in the last decade? Back in 2015, $JOB was evaluating upgrading Java 6 to Java 7 or 8. What is now? 20? I last touched php in 2012, which was 5.4 or 5.5 I think. People were still arguing that Laravel couldn't replace CodeIgnitor, or that we should stick with Symphony or Zend. Change is the only constant. In that respect, React has been relatively sane.
  - karaterobot 3y ago
    As you know, Java and PHP are languages. React is just a framework, and by design not a particularly robust one on its own. It just provides a front end, everything else has to be plugged in separately, learned, maintained, and ultimately cast aside and forgotten separately. If you're a React developer, you'll have noticed that Javascript itself has changed a lot in ten years. The state management library your company uses has probably changed too. Compared to ten years ago, you're now writing fully-typed JS with Typescript. The additional libraries for authentication and persistence, and so on, have all changed as well. You may be using a graph-based database now. You may have a different JS runtime on the server. All of your tooling has probably changed, as has your IDE. Whether React itself has or has not changed more than other frameworks, I can't say. But, I'd bet the stack used by the average front end developer has. Please recall that the original comment we're both talking about was referring to complaints about how much the front end has changed, with React only being the context of the comment, and not the sole cause of the complaint.

mkl95 3y ago

I once tried to learn what you would call "proper React", only for some Googler to tell me I wasn't even using React. Despite the fact I was using it back when hooks weren't a thing, and I had built multiple apps with it. There are many things I can stand in a community, but gatekeeping is not one of them.

TeffenEllis 3y ago

I think React really was revolutionary when your choices were jQuery, Backbone, or even Angular 1. I remember trying to convince my team that React was the next best thing when it first came out. Skepticism was everywhere — especially around JSX. So we compromised and wrote our components with CoffeeScript… The sheer number of flux frameworks were a testament to how underserved the state model was at the time. And without consistent support for async/await to make Promises work well in an app, data fetching and state was the worst part of React. I’ve always despised Redux and the circus that came with thunk generators. MobX made things a little bit easier. And Baobab was a fun concept to bring Clojure-style cursors to JavaScript. It wasn’t until React shipped the context API and hooks that I felt the problem of, “how do I get this state from up here to down there?” was truly solved. Personally, I’ve wished I could quit React for something like native Web components, but I feel like I’d be back at square one with state management and stringly-typed templates. Maybe Lit-HTML will get there one day!

kypro 3y ago
Out of interest why did you despise Redux and Redux Thunk? Imo Redux did solve the problem of state management and I always thought it was quite an elegant solution personally. Hooks and the context API are just different ways to manage state (and many would argue better). Do you disagree?

tambourine_man 3y ago

I was blown away when I learned the concept of the virtual DOM and how diffing it could be made fast. But as practical tool, React has been a regression for the web IMO.

Kilenaitor 3y ago
How has it been a regression for the web?
- tambourine_man 3y ago
  I don’t think direct DOM manipulation was ever a problem, if done thoughtfully. If keeping track of state is so hard that requires a library to render it, perhaps you have too much state for a single view. It’s ultimately a UI/UX design problem, as it will be hard on your users as well. I find the way they mix markup with code distasteful, and lots more.
  - 5Qn8mNbc2FNCiVV 3y ago
    It's less keeping track of state is hard and more keeping state in a medium that isn't suitable for it (the DOM). The argument of too much state in a single view is nil by what applications are built nowadays (and also expected). Obviously it was already possible without the rise of declarative rendering frameworks but it made it more accessible to the majority of developers and thus raising the bar. If you do however find the way markup and code is mixed feels distateful, I'd suggest to not look at any templating engine in the last 20 years because that's what most of them already did.
    - tambourine_man 3y ago
      If you’re building a Gmail competitor, by all means, go with React, build your own solution, whatever. If you need to choose the color of a shirt with 3 sizes, perhaps it’s an overkill. Regarding templating engines, I use PHP :)
  - yazaddaruvala 3y ago

nfRfqX5n 3y ago

big milestone for the team, congrats to all of the contributors!

roschdal 3y ago

What will succeed React?

FactualActuals 3y ago
I don't think React will be replaced for a very long time. The only library that has somewhat similar adoption rates to early React is Vue. I personally prefer Vue over React and I use it at work. But I would be happy using React as well if the choice was given to me. Vue3 + Composition API just makes sense to me.
- oblak 3y ago
  Vue 3 + pinia is simply an amazing experience. Nothing is shoved down your throat I tried getting back to React but Vue makes so much more sense. Feels like in the old days because all you do is write your code instead of dealing with a library and its ways.
  - bricss 3y ago
    Absolutely agree! Vue + Pinia = This is the way ©
deleted 3y ago
[deleted]
kristopolous 3y ago
Sanity hopefully
elforce002 3y ago
It'll be a long time before something comes along and dethrone react. React ecosystem is too vast and the community is large and engaged. Nothing comes closer to React atm. Other than that, prob. lit-dev (with time).
- azangru 3y ago
  > Other than that, prob. lit-dev (with time). Yes. Nothing excites me more than web components and moving closer back to the browser. Somehow, it feels more exciting than server components, signals, compilers, resumability, etc. etc.

itsuka 3y ago

To celebrate React 10th anniversary, Next.js interviewed Andrew and Sebastian from React core team: https://www.youtube.com/watch?v=g5BGoLyGjY0 https://www.youtube.com/watch?v=g5BGoLyGjY0

kamaal 3y ago

As a backend developer who didn't 'get' web development for many years. Learning react changed all of it. React was revolutionary, and just clicked for me. Combine this with frameworks like Material UI, Patternfly and many others and its almost like you have some super power. These days I can build fairly big sites with lots of stateful components quickly. Most of my use cases is to build internal tools. But the pace with which once build things in react and its over intuitiveness just makes it special. React is one framework which Im sure will be available for long time to come! Thank you React dev team.

plugin-baby 3y ago
Similar feelings here. To me, React was one of the first approaches to web frontend development that really promoted good engineering practices.
rchaud 3y ago
As someone who started in front-end and was deluged with 2000s conventional wisdom like "don't use inline styles" and "keep scripts separate from your CSS and HTML markup", React made absolutely no sense.
- june_twenty 3y ago
  Embrace it for awhile and it really is special. You've a function that returns JSX which is your HTML where you can use Javascript to reference functions/variables (e.g. the state variables) One of the key parts is that you can break it all down into different files/functions that return jsx so you can isolate complicated parts
- Izkata 3y ago
  Even if people understand this at a conscious level, it's rarely explained: > and "keep scripts separate from your CSS and HTML markup" was for documents, not interactive applications, with the goal being that a document could be reformatted through CSS for multiple different displays. The earliest example I can recall was web vs print (as in, in the browser go File -> Print; you can specific different CSS rules so the page prints differently than it shows in the browser). Screen size / mobile displays are other examples that came later. React on the other hand is great for interactive applications, which have always worked component-style - a checkbox or a dropdown in a native GUI would be used multiple times and knows how to style itself, for example, which is the same as what a React checkbox or dropdown would do. > "don't use inline styles" This rule was broken simply because there wasn't a better way to do the component packaging at the time. Nowadays we have CSS Modules, which separates them again.

revskill 3y ago

10 years and state management is still a mess.

latchkey 3y ago
I'd say it is less about being a mess and more about the fact that there are 1000 projects that do state management in totally different ways and it is nearly impossible to figure out which one to use. Even if you pick one, you don't find out that it has some critical bug until you're half way through your project and it is too late to swap it out. So, you end up coming up with some hacky workaround that creates a lot of brittle code and breaks every time you upgrade some other non-related component of your application.

cloudyporpoise 3y ago

So now all those ridiculous job postings requiring 10 years experience with React finally make sense?

revskill 3y ago
It should be 15 years of experience now.

beders 3y ago

10 years and we are still building custom forms from the same primitive building blocks. And with react having to fudge with the state of DOM input components, it's been a messy ride. And yet, the idea of describing your UI and have a library figure out what needs to be repainted has been liberating. React certainly wasn't the first, but it certainly was the most elegant one at the time. I wish React would split up and go back to the roots: Have it deal with rendering - and nothing else. Have optional companion projects that deal with the various forms of state and side-fx.

latchkey 3y ago
I've been maintaining a project for 4 years now (~40k downloads/mo on NPM, 400+ stars) that is simply glue code between a React form management library and a React UI library. It was really hard to get right, still isn't perfect, and over the years has required several major upgrades to keep up with changes in all three. Luckily, I have very good unit tests and snapshots that ensure upgrades don't break things. You'd think it would be easier, but it isn't. I really wish React would just own the low level forms stuff and get rid of the need for a 3rd party form management library. That said, because it is frontend JS, there are 1000 different ways to bike shed this problem and because it is form stuff, there is no one solution that fits all use cases.
- teetertater 3y ago
  Which one? This sounds like it could be useful for me
  - SCUSKU 3y ago
    After some digging I believe it's this one: https://github.com/lookfirst/mui-rff https://github.com/lookfirst/mui-rff
    - teetertater 3y ago
      Cheers

boredumb 3y ago

React is really good for helping create giant SPA apps for the web. Unfortunately 99% of things using react aren't or shouldn't be SPA apps and now otherwise trivial applications are orders of magnitude more complex in their implementation and much heavier on bandwidth than necessary.

adverbly 3y ago

Finally all those job postings asking for 10 years of React experience can be filled!

ggregoire 3y ago

As someone who worked with jQuery (15 years ago), then Backbone.js, then Angular 1, then React (for the last 6 years or so), I honestly feel like React is here to stay. It solved all the pain points I had with the previous frameworks when working on complex and massive code base. I have a level of productivity I never achieved before. I never have to check the docs, I can't remember last time I thought to myself "why is this not working" or "how am I going to do that" or "what's the syntax/arguments of X". It is amazingly simple, intuitive and powerful. Most of the time I'm just reusing components I coded years ago, gluing them together to develop a new app that would have taken me days with the previous frameworks.

nailer 3y ago
> As someone who worked with jQuery (15 years ago), then Backbone.js, then Angular 1, then React (for the last 6 years or so), I honestly feel like React is here to stay. That sentence didn't end how I expected it to. Personally - coming from a similar (jQuery -> Knockout > Backbone > Ember > Angular 1 > React > Svelte) background - I feel React has gone the same route as the others - rose quicky, dominated, and will never go away, but no longer has any influence. The same will happen to Svelte in future.
- graftak 3y ago
  React still has some tricks up it’s sleeve with great potential that are (often) missing in comparable frameworks. Error boundaries, async (server) components, suspense, portals, dynamically imported components, concurrent mode. Just a shame it takes/took forever for suspense to resolve.

bricss 3y ago

The only good thing about it, it's JSX! \m/ The rest is abomination ¬_¬

brundolf 3y ago

Can we agree it's not a "framework du jour" anymore? 10 years is a pretty long day

ExtremisAndy 3y ago

I wanted to like React so bad. I tried. I loved JSX and really appreciated the way you could reuse components. That was all very cool, and I was initially quite enthusiastic about it. But for whatever reason, I just could not figure out state management/hooks. Drove me crazy. It just always felt so unnecessarily complicated compared to other languages and frameworks I've used (even vanilla JS). Now, don't get me wrong: I fully accept the blame here. I am mostly self-taught (and not even the best 'student' in that context, haha) so I'm sure I just lack the overall knowledge base/big-picture understanding to really appreciate what they've done here. I hope I'll give it another shot one day, and perhaps with fresh eyes (and maybe with the help of a patient tutor), it will all 'click'!

fendy3002 3y ago
Hooks are complicated, but state/props is just right. Both enables you to enforce boundary and make contained components. If props and state are mixed / diluted, the component won't know when to do re-render and there'll be too many things to track, and there'll be many classic issues such as cyclic dependency and sluggish performance of two-way data binding. Hopefully you'll click on it someday
deleted 3y ago
[deleted]
qudat 3y ago
view = func(state). That’s the magic of react. The problem is no longer manually managing transitions between state but state itself. That’s why state management is so critical in the react ecosystem. Further, react has delegated two key features to userland: side effect and state management. Personally, I don’t want react to solve either of these problems because it’ll just turn into the disaster that is react server components: feature development driven by corporate interests (eg vercel).
- june_twenty 3y ago
  I think that view = func(state) is an unnecessary complicated way to describe frontend development.

garganzol 3y ago

React is a text-book example of what a well-designed component model can do to a development cycle: a literal 5-20x productivity boost compared to the old vanilla JavaScript with jQuery and manual HTML manipulation. I was somewhat skeptical in the early days of React, but once static websites with rehydration became a thing, I was fully in. So much power.

petilon 3y ago
> a literal 5-20x productivity boost Not really. See a better way here: https://github.com/wisercoder/eureka https://github.com/wisercoder/eureka
- yazaddaruvala 3y ago
  Sorry, I don't understand. Why is this a relevant link? "Lucene based search" vs React ? Seems like comparing trees to tractors.
  - petilon 3y ago
    See the web app. It is a more productive style of coding. Simple, and no need to deal with hooks and useState and useContext and none of that nonsense.
    - yazaddaruvala 3y ago
      Got it thanks for the context. I've read the web app and it seems to me it is just https://backbonejs.org/ https://backbonejs.org/ re-written in Typescript and allows JSX. I'm very certain Typescript and JSX will have improved the DX for Backbone like apps, but it doesn't address all of the other issues that teams had with Backbone. e.g. Cyclical event propagation, state stored in the DOM (i.e. appendChild is error prone in large multi-person code bases), etc. FWIW, the reason this works for eureka is highlighted best on this page: https://github.com/wisercoder/eureka/graphs/contributors https://github.com/wisercoder/eureka/graphs/contributors there is only a single author!

belter 3y ago

This whole discussion is concerning. So can somebody please point me to what is considered the modern React way? Educational resources, Tutorials, Docs please? Or is this modern way based on Beta documents? Edit: Is this the place to start? - https://react.dev/ https://react.dev/ From what I see from the tutorials...Why the closeness to NodeJS?

tracker1 3y ago
That would be a good place to start. Node.js is the defacto standard for JS based tooling, along with npm (node package manager) as a public module repository. There has been some evolution in the space. If starting a project, I'd probably start with Parcel.js [1] and from there use typescript/tsx instead of JS as a core. But that's just me. I also tend to do Redux the "hard way" closer to the original structure instead of redux-toolkit, as I find it's more overhead to learn initially but avoids a lot of additional complexity over time. 1. https://parceljs.org/recipes/react/ https://parceljs.org/recipes/react/
- acemarke 3y ago
  Hi, I'm a Redux maintainer and creator of Redux Toolkit. Can you clarify what your concerns are with RTK? We specifically created it to simplify standard Redux usage patterns and eliminate common mistakes and bugs (like accidental mutations): - https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today We'd _like_ everyone who is writing any kind of Redux code to write that using Redux Toolkit, and we teach RTK as the default approach for using Redux. FWIW, we've had plenty of beginners tell us they were able to get started and be productive after reading through the "Essentials" tutorial in our docs, which walks folks through how to use RTK to build apps.
  - tracker1 3y ago
    I just find that the original reducer pattern(s) are easier to deal with in practice, especially when a project is slightly larger. It's often better imho, to understand the original patterns and some of the RTK approaches kind of muddy that understanding. I'm not saying that RTK is necessarily bad, but feel that when you're using some of those kinds of slices, or merging the constraints of the actions, mutations and the abstractions, it's harder to reason with. You aren't thinking about state as a whole, or often even your fragment. I'll sometimes mix a few things as well... The React features for provider/consumer, etc are sometimes easier to deal with as well. YMMV based on your own needs.

outside1234 3y ago

Congrats Dan and everyone on the React team. Great framework and has been an extremely productive decade for me personally.

koinedad 3y ago

React - you have a special place in my heart

xwowsersx 3y ago

I understand some comments here are saying that they feel React is here to stay. I have no basis to judge that, but putting that side, a question: what is it about frontend web development that seems to lend itself to neverending development of new frameworks or ways of building apps? I'm genuinely curious. Is there something inherent in developing web apps that just isn't quite solved, some way in which each new framework doesn't quite solve the problems (whatever those are)? Or is it just that the web (unlike mobile) is so open and there's so much development interest that this leads to endless efforts to improve on what came before leading to new frameworks all the time? Appreciate any thoughts on this!

paxys 3y ago
Coming from the backend, I feel the exact opposite. For any kind of frontend development you have a choice of ~3 clients, one programming language, a handful of frameworks, 2-3 of which have any real traction. Compare that to literally hundreds of programming languages that can run server side code, dozens of database engines, servers, all kinds of operating systems, hosting platforms...the web of backend tech is pretty much endless, and growing every day.
- ern 3y ago
  You are correct, there have been changes on the back-end as well: containers and Kubernetes vs serverless. The endless tension between microservices and monoliths. Multiple IaC options. Onprem vs cloud (which cloud?), and associated cycles of disillusionment. The difference may be that once a particular back-end approach/architecture/design is adopted by a dev shop it remains stable over multiple projects. I’ve seen this in both consulting and in LOB roles. Because of this, I can hire a competent .NET developer and be confident that I can get them to be productive relatively quickly, since the foundation on which we write our code is stable, and I can invest in enhancing the developer experience to support them. In fact, an explicit criterion for every project in my teams is that we make it easy enough for any competent C# developer to ideally be able to open a small, but meaningful PR by the end of their first day on a project (if needed, I don’t treat it as a retention gate or anything!). They do have to adapt to our infrastructure and our ways of working, they don’t need to relearn the fundamentals of how to produce code. Whereas every time a new front-end project starts, there’s a near-compulsion to use the latest and greatest techniques. Everyone has to catch up, because of their previous experience being somewhat redundant. No one can invest in improving things for other developers, because they don’t have the time, and because any investment would be wasted, since it would be redundant beyond the current project (or two, if we’re lucky). I can’t really hire an Angular developer for a React project that starts tomorrow, and expect them to be reasonably productive immediately, despite them being competent in Typescript, CSS, Node etc. Heck, I wouldn’t even be able to hire a React developer who last did it 5 years ago, and expect them to be immediately productive.