9 ms·

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Decorators vs not using them, and now Hooks. These were mostly cosmetic choices, and if your team picked the wrong side they could migrate over relatively painlessly or straight up ignore the issues for years. On the other side of spectrum we have Ember that maintained backward compatibility and ease of upgrades since ~2013, Angular 2+ is doing the same for many years, too. The whole "JavaScript fatigue" meme has to go.

strangescript 6y ago
100%. Normally these articles are thinly veiled attacks on something that has changed in the author's coding ecosystem that has angered them. When I saw hooks in the first few paragraphs I assumed it was going to be a "hooks are bad, mkay" article. It isn't, but still some what vague on actionable points or ideas. Ultimately no one likes rewriting code and is typically under-estimated since developers mentally trivialize previous work rather than a greenfield affair.
Softcadbury 6y ago
I agree for frameworks, but building tools and package management are still nightmares for me
draw_down 6y ago
Blessed sanity. Great post, thank you.
dlbucci 6y ago
I have to chime in as someone who created an Angular.js app in 2017. I suppose it happens. Not that I actually wanted to, I was just working with a dumbass who overruled me. I don't really have anything it say, I just have a really strong negative association with this specific topic, I guess...
- desireco42 6y ago
  You are not the only one. It is just a question of personality, some people feel comfortable in Angular world, most people are like you and me.
  - iaml 6y ago
    It's probably not that angular is dumb - using angularjs 1.x in 2017 is dumb. And I do concur as someone who also wrote angularjs app at that time and eventually left the company over it.
tarsinge 6y ago
You are overly optimistic with the timeline. No, React had not "won" by 2015, not even by 2016[0]. Also the burn of more than half a decade is very real, both on developers and in codebases. [0]http://2016.stateofjs.com/2016/frontend/ http://2016.stateofjs.com/2016/frontend/. From that link: > What's more, there's just so many options: Do you use React or Angular 2? Do you really need Webpack? And what's this month's recommended way of dealing with CSS? > Like you, I spent far too many hours reading about all this, and at the end I still wasn't sure. So I decided to create a survey to see what everybody else thought. It seems like I must've hit a nerve, because I got over 9000 answers in just over two weeks!
- strbean 6y ago
  From that survey, is you look at positive (would like to learn + would use again) vs. negative responses (not interested + would not use again), it looks like React is crushing everything outright. 85% positive / 15% negative. Amongst the other frameworks, the only one without at least 50% negative response is Vue at 43% positive / 35% negative, with a heart "never heard of it" segment as well.
  - mercer 6y ago
    Who cares what developers 'like to learn/use' when in practice they often don't get to, or get lucky and their preferred approach/tech is considered 'safe' a few years later?
wegs 6y ago
Rewrites only make sense if you get a multi-fold improvement. In the history of computing, that's rare. So they rarely make sense. Well, JavaScript was really horrible when it came out. It was just about the worst major programming language ever made. It sort of reminds me of an interpreter I threw together for a programming language I invented when I was in high school, when I really didn't get any aspect of programming language design, and I based it on a misunderstanding of Lisp. Given its central role, lots of people used JavaScript, and lots of smart people tried to fix it. Every few years, it'd get a lot better. It actually made sense to rewrite everything -- you got that multi-fold improvement in productivity going 1995 JS to 2000 JS, 2005 JS to 2010 JS, and so on. I mean, with each iteration, it was still obnoxiously bad, but it was that much less bad. It looked like an exponential growth curve for a while, but you always knew it was an S-curve -- you hit an inflection point when you reach the level of competently-designed programming languages. At some point in the past five years, JavaScript stopped being really bad. I mean, it's no Python, but it's at least within spitting range. Heck, it's better than Java. I won't even lose 2x productivity writing in JavaScript over best-of-breed languages, at least core language (ecosystem aside -- there is no numpy/scipy/pylab -- but that will come too). With that, rewrites every five years no longer make sense. Unless there's some fundamental progress in computing, I expect JavaScript code I write today may still be used in 20 years. That's not something I would have said in 2010 or 2000.
- mettamage 6y ago
  How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important). I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.
  - gfodor 6y ago
    Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.
wnevets 6y ago
What do you mean, everyone is now updating their codebases to remove redux, HoF and switch to hooks.
- cameronfraser 6y ago
  No, people are realizing that they were just using redux as a caching layer and the boilerplate associated with it wasn't worth it when there are better approaches to caching local data now.
  - ccmcarey 6y ago
    Out of curiosity what are the better approaches to caching local data? The only thing I'm aware of is something like Apollo client but .. that only works for graphql.
    - cameronfraser 6y ago
      react-query, swr
  - aero142 6y ago
    What do you believe people are replacing it with? Hooks?
  - dynamite-ready 6y ago
    I disagree. Redux has a lot of icky boilerplate, but the Flux pattern, and variations of it, are useful. You're either using Redux, something like Redux (context hooks, possibly), or you are passing single variables through 3 or more layers of spaghetti.
    - acemarke 6y ago
      There's truth to both these statements. If the only thing you're doing with Redux is just fetching and caching data, and nothing further, there are other tools that are likely going to be more ergonomic for that (Apollo, react-query, SWR). However, if you're actually _manipulating_ that data after it's been fetched, or working with more complex client-side state, the Flux architecture really becomes useful. As the Redux docs FAQ entry on "When should I use Redux?" says [0]: > In general, use Redux when you have reasonable amounts of data changing over time, you need a single source of truth, and you find that approaches like keeping everything in a top-level React component's state are no longer sufficient. (We also have additional guidance on when it makes sense to put any given piece of state into Redux [1], and I'm adding more guidance on this sort of topic as I work on rewriting our docs.) Beyond that, our new Redux Toolkit package [2] has been specifically designed to eliminate most or all of that "boilerplate" concern, and provides a set of utilities that simplify most common Redux use cases. We now recommend it as the default approach for writing Redux logic, and I'm currently working on a new "Quick Start" docs section [3] that will teach it as the right way to use Redux for beginners (alongside the existing tutorial sequence that teaches how Redux works from the ground up). Related to this, while I've been very reluctant to try to build any type of official Redux-based query/caching solution, we _did_ recently release a new `createAsyncThunk` API [4] that simplifies the process of dispatching actions while fetching and a `createEntityAdapter` API that handles some normalization [5], and I _am_ considering trying to add some more involved abstraction to RTK in the near future [6]. [0] https://redux.js.org/faq/general#when-should-i-use-redux https://redux.js.org/faq/general#when-should-i-use-redux [1] https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... [2] https://redux-toolkit.js.org https://redux-toolkit.js.org [3] https://deploy-preview-3740--redux-docs.netlify.app/tutorials/quick-start/quick-start-part-1 https://deploy-preview-3740--redux-docs.netlify.app/tutorial... [4] https://redux-toolkit.js.org/api/createAsyncThunk https://redux-toolkit.js.org/api/createAsyncThunk [5] https://redux-toolkit.js.org/api/createEntityAdapter https://redux-toolkit.js.org/api/createEntityAdapter [6] https://github.com/reduxjs/redux-toolkit/issues/603 https://github.com/reduxjs/redux-toolkit/issues/603
torb-xyz 6y ago
Yeah I have to say I agree. I think there was valid reasons for some of the framework churn early on (basically no proper standard way to do client side GUI). When the MVC-oriented stuff started to stabilise we all discovered that functional reactive programming UI was a good thing and that drove stuff like React and Angular 2. But there simply hasn't been a paradigm shift in UI after that (and I doubt there will anytime soon, it's not often a whole new UI paradigm that changes stuff the way MVC and FRP have done is popularised). Stuff like Vue and Svelte are simply attempts at optimising or improving the reactive approach, but is basically still fundamentally the same idea. Someone versed in React would easily move over.
throwaway286 6y ago
I don't think hooks are a superficial change. If react stayed with class based components, I'd agree with you.
013a 6y ago
Yeah; I think your timeline is off. I don't remember React being the very clear choice until probably 2017. It was still up in the air in 2016, and certainly moreso in 2015. > by 2015 React "won" the framework battle. Things have calmed down now. Its better, and has been for a couple years (not 5+ years). But, this isn't a battle. Its not a war. Just because things are calm now, doesn't mean they won't go crazy again. The core of the issue has nothing to do with technology, or the frameworks, or programming languages. It has everything to do with how you, I, and Dave, who's reading this right now, respond when these new technologies come out. Just. Say. No. Play with them. Build toy projects. Give feedback. But for the love of God, at the end of the day, you Say No. No, we will not be integrating this. Looks cool though, we'll circle back in a year and see what progress you've made.
- phponpcp 6y ago
  "I don't remember React being the very clear choice until probably 2017." Maybe you werent paying attention then.
  - Izkata 6y ago
    CSS Modules didn't become the default way to go until sometime in 2016. Before that point people were still stumbling over how to manage their CSS in a component-oriented fashion, and it was only once that happened did React "win".
    - CraftThatBlock 6y ago
      CS Modules are still not the "default", this space is still up in the air. There's CSS-in-JS (like styled-components or Emotion), Sass, plain CSS, etc.
      - gitgud 6y ago
        Even utility CSS like Tailwind is gaining popularity...
      - Izkata 6y ago
ehnto 6y ago
You make it sound like we're all using React and that's all there is to it. That's not quite true, and it's just one of the choices you have to make. So you've decided on React, but what about state management, transpilation, do you use GraphQL? What am I doing for styles, should I write them in Javascript too now? Oh no! Webpack isn't for me! Can I use modules yet? Ah bugger, we need SSR, suppose I should have managed state the "Right Way (v28.6)", doh!
- wzy 6y ago
  I even got fatigued reading your list of choices and you even missed critical choice such as flavor of SSR.
  - deleted 6y ago
    [deleted]
- flowardnut 6y ago
  Excuse me, it isn't a real frontend without a service worker and offline capabilities.
- mercer 6y ago
  Just use Next! I mean Nuxt! I mean really just give up and go for Phoenix LiveView or TurboLinks or Blazor...
simple_phrases 6y ago
People were still writing CoffeeScript in 2015.
bernawil 6y ago
Agreed, but I wouldn't put 2015 as the year React "won". It did "win" the SPA frameworks war, but back then the default for webdev was still non-SPA and React was competing with jquery/"no framework" and the rest of not-quite-spa frameworks like backbone, ember, etc. Nowadays React is the standard, I dare say even for SSR sites! The javascript framework fatigue meme was born during the early days of ember, backbone, angular 1, knockoutjs and meteor. Sometime between 2016 and 2017 was when it should have been put to rest.
throw_m239339 6y ago
Angular(1) wasn't simple but knowing basic stuff made it possible to do complicated things quickly. Angular lost a lot of momentum when they decided Angular had to look like JEE and become a framework trying to justify its existence with complexity. React had the right idea, just make view management simple, don't force some bullshit IoC container on Javascript and that's it. If you want IoC that's your problem. Ultimately the problem is that nothing replaces React natively in web API. A tool such as React shouldn't be useful anymore and Web Components isn't as ubiquitous as it was envisioned to be. In fact, I've never worked in any business that used Web Components. But the biggest issues are on the node.js side and all the complex pipelines put in place in order to fix front-end development. In fine, the tools that will be successful are the ones that will still be actively maintained 5 years from now, and most of the libs/projects will not.
- kls 6y ago
  I see it a little differently, Angular 1 lost momentum because it was a bad framework. It was clearly written by people that did not have a lot of experience productionalizing code. Further they choose new and convoluted naming for concepts that already had names. The came up with a creative new way to introduce globals thru rootscope and performance was abysmal. Their component model was leaky at best and the whole framework encouraged writing monolithic controllers that where in the same vain of Backbone.js. There where actually good frameworks at that time such as Dojo they just did not get the mindshare that Angular got and a lot of that was due to it being incubated at Google. The second part of the issue is there where not many people doing hardcore Javascript programming and so there was not a depth of deep CS knowledge in the front end space. It took more and more of them reluctantly converting over, getting one look at Angular and going look guys this is bad because of X,Y and Z. Angular 1 actually set the state of the art back compared to some of the other offerings at the time. The absolute tell, was when the team had to admit it, admit they where going to scrap it for a total rewrite that was to become Angular 2 and on. The reason React has done so well, is that core team members had deeper CS experience, understood other paradigms for UI development and understood that the best state of the art for UI right now, is a render loop. If you converted it to C, squinted at it long enough you would see the very old, very tried and very true Windows render loop in it. They took a proven pattern, bolted it to the virtual DOM and brought it to the web. They did not perform miracles, they stuck to what has been proven to work. Well the virtual DOM was a pretty clever hack, but the rest is UI dev 101. The problem was most the JS developers at the time, never had that back experience of desktop UI development and a good deal of them had come to development by way of learning HTML, CSS and then bits and pieces of JS as they needed to.
knolax 6y ago
But how long was Angular in vogue before React? If it was also ~5 years then a shift in frameworks every 5 years of calm + 2 years of chaos still isn't ideal.

strangescript 6y ago

100%. Normally these articles are thinly veiled attacks on something that has changed in the author's coding ecosystem that has angered them. When I saw hooks in the first few paragraphs I assumed it was going to be a "hooks are bad, mkay" article. It isn't, but still some what vague on actionable points or ideas. Ultimately no one likes rewriting code and is typically under-estimated since developers mentally trivialize previous work rather than a greenfield affair.

Softcadbury 6y ago

I agree for frameworks, but building tools and package management are still nightmares for me

draw_down 6y ago

Blessed sanity. Great post, thank you.

dlbucci 6y ago

I have to chime in as someone who created an Angular.js app in 2017. I suppose it happens. Not that I actually wanted to, I was just working with a dumbass who overruled me. I don't really have anything it say, I just have a really strong negative association with this specific topic, I guess...

desireco42 6y ago
You are not the only one. It is just a question of personality, some people feel comfortable in Angular world, most people are like you and me.
- iaml 6y ago
  It's probably not that angular is dumb - using angularjs 1.x in 2017 is dumb. And I do concur as someone who also wrote angularjs app at that time and eventually left the company over it.

tarsinge 6y ago

You are overly optimistic with the timeline. No, React had not "won" by 2015, not even by 2016[0]. Also the burn of more than half a decade is very real, both on developers and in codebases. [0]http://2016.stateofjs.com/2016/frontend/ http://2016.stateofjs.com/2016/frontend/. From that link: > What's more, there's just so many options: Do you use React or Angular 2? Do you really need Webpack? And what's this month's recommended way of dealing with CSS? > Like you, I spent far too many hours reading about all this, and at the end I still wasn't sure. So I decided to create a survey to see what everybody else thought. It seems like I must've hit a nerve, because I got over 9000 answers in just over two weeks!

strbean 6y ago
From that survey, is you look at positive (would like to learn + would use again) vs. negative responses (not interested + would not use again), it looks like React is crushing everything outright. 85% positive / 15% negative. Amongst the other frameworks, the only one without at least 50% negative response is Vue at 43% positive / 35% negative, with a heart "never heard of it" segment as well.
- mercer 6y ago
  Who cares what developers 'like to learn/use' when in practice they often don't get to, or get lucky and their preferred approach/tech is considered 'safe' a few years later?

wegs 6y ago

Rewrites only make sense if you get a multi-fold improvement. In the history of computing, that's rare. So they rarely make sense. Well, JavaScript was really horrible when it came out. It was just about the worst major programming language ever made. It sort of reminds me of an interpreter I threw together for a programming language I invented when I was in high school, when I really didn't get any aspect of programming language design, and I based it on a misunderstanding of Lisp. Given its central role, lots of people used JavaScript, and lots of smart people tried to fix it. Every few years, it'd get a lot better. It actually made sense to rewrite everything -- you got that multi-fold improvement in productivity going 1995 JS to 2000 JS, 2005 JS to 2010 JS, and so on. I mean, with each iteration, it was still obnoxiously bad, but it was that much less bad. It looked like an exponential growth curve for a while, but you always knew it was an S-curve -- you hit an inflection point when you reach the level of competently-designed programming languages. At some point in the past five years, JavaScript stopped being really bad. I mean, it's no Python, but it's at least within spitting range. Heck, it's better than Java. I won't even lose 2x productivity writing in JavaScript over best-of-breed languages, at least core language (ecosystem aside -- there is no numpy/scipy/pylab -- but that will come too). With that, rewrites every five years no longer make sense. Unless there's some fundamental progress in computing, I expect JavaScript code I write today may still be used in 20 years. That's not something I would have said in 2010 or 2000.

mettamage 6y ago
How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important). I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.
- gfodor 6y ago
  Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.

wnevets 6y ago

What do you mean, everyone is now updating their codebases to remove redux, HoF and switch to hooks.

cameronfraser 6y ago
No, people are realizing that they were just using redux as a caching layer and the boilerplate associated with it wasn't worth it when there are better approaches to caching local data now.
- ccmcarey 6y ago
  Out of curiosity what are the better approaches to caching local data? The only thing I'm aware of is something like Apollo client but .. that only works for graphql.
  - cameronfraser 6y ago
    react-query, swr
- aero142 6y ago
  What do you believe people are replacing it with? Hooks?
- dynamite-ready 6y ago
  I disagree. Redux has a lot of icky boilerplate, but the Flux pattern, and variations of it, are useful. You're either using Redux, something like Redux (context hooks, possibly), or you are passing single variables through 3 or more layers of spaghetti.
  - acemarke 6y ago
    There's truth to both these statements. If the only thing you're doing with Redux is just fetching and caching data, and nothing further, there are other tools that are likely going to be more ergonomic for that (Apollo, react-query, SWR). However, if you're actually _manipulating_ that data after it's been fetched, or working with more complex client-side state, the Flux architecture really becomes useful. As the Redux docs FAQ entry on "When should I use Redux?" says [0]: > In general, use Redux when you have reasonable amounts of data changing over time, you need a single source of truth, and you find that approaches like keeping everything in a top-level React component's state are no longer sufficient. (We also have additional guidance on when it makes sense to put any given piece of state into Redux [1], and I'm adding more guidance on this sort of topic as I work on rewriting our docs.) Beyond that, our new Redux Toolkit package [2] has been specifically designed to eliminate most or all of that "boilerplate" concern, and provides a set of utilities that simplify most common Redux use cases. We now recommend it as the default approach for writing Redux logic, and I'm currently working on a new "Quick Start" docs section [3] that will teach it as the right way to use Redux for beginners (alongside the existing tutorial sequence that teaches how Redux works from the ground up). Related to this, while I've been very reluctant to try to build any type of official Redux-based query/caching solution, we _did_ recently release a new `createAsyncThunk` API [4] that simplifies the process of dispatching actions while fetching and a `createEntityAdapter` API that handles some normalization [5], and I _am_ considering trying to add some more involved abstraction to RTK in the near future [6]. [0] https://redux.js.org/faq/general#when-should-i-use-redux https://redux.js.org/faq/general#when-should-i-use-redux [1] https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... [2] https://redux-toolkit.js.org https://redux-toolkit.js.org [3] https://deploy-preview-3740--redux-docs.netlify.app/tutorials/quick-start/quick-start-part-1 https://deploy-preview-3740--redux-docs.netlify.app/tutorial... [4] https://redux-toolkit.js.org/api/createAsyncThunk https://redux-toolkit.js.org/api/createAsyncThunk [5] https://redux-toolkit.js.org/api/createEntityAdapter https://redux-toolkit.js.org/api/createEntityAdapter [6] https://github.com/reduxjs/redux-toolkit/issues/603 https://github.com/reduxjs/redux-toolkit/issues/603

torb-xyz 6y ago

Yeah I have to say I agree. I think there was valid reasons for some of the framework churn early on (basically no proper standard way to do client side GUI). When the MVC-oriented stuff started to stabilise we all discovered that functional reactive programming UI was a good thing and that drove stuff like React and Angular 2. But there simply hasn't been a paradigm shift in UI after that (and I doubt there will anytime soon, it's not often a whole new UI paradigm that changes stuff the way MVC and FRP have done is popularised). Stuff like Vue and Svelte are simply attempts at optimising or improving the reactive approach, but is basically still fundamentally the same idea. Someone versed in React would easily move over.

throwaway286 6y ago

I don't think hooks are a superficial change. If react stayed with class based components, I'd agree with you.

013a 6y ago

Yeah; I think your timeline is off. I don't remember React being the very clear choice until probably 2017. It was still up in the air in 2016, and certainly moreso in 2015. > by 2015 React "won" the framework battle. Things have calmed down now. Its better, and has been for a couple years (not 5+ years). But, this isn't a battle. Its not a war. Just because things are calm now, doesn't mean they won't go crazy again. The core of the issue has nothing to do with technology, or the frameworks, or programming languages. It has everything to do with how you, I, and Dave, who's reading this right now, respond when these new technologies come out. Just. Say. No. Play with them. Build toy projects. Give feedback. But for the love of God, at the end of the day, you Say No. No, we will not be integrating this. Looks cool though, we'll circle back in a year and see what progress you've made.

phponpcp 6y ago
"I don't remember React being the very clear choice until probably 2017." Maybe you werent paying attention then.
- Izkata 6y ago
  CSS Modules didn't become the default way to go until sometime in 2016. Before that point people were still stumbling over how to manage their CSS in a component-oriented fashion, and it was only once that happened did React "win".
  - CraftThatBlock 6y ago
    CS Modules are still not the "default", this space is still up in the air. There's CSS-in-JS (like styled-components or Emotion), Sass, plain CSS, etc.
    - gitgud 6y ago
      Even utility CSS like Tailwind is gaining popularity...
    - Izkata 6y ago

ehnto 6y ago

You make it sound like we're all using React and that's all there is to it. That's not quite true, and it's just one of the choices you have to make. So you've decided on React, but what about state management, transpilation, do you use GraphQL? What am I doing for styles, should I write them in Javascript too now? Oh no! Webpack isn't for me! Can I use modules yet? Ah bugger, we need SSR, suppose I should have managed state the "Right Way (v28.6)", doh!

wzy 6y ago
I even got fatigued reading your list of choices and you even missed critical choice such as flavor of SSR.
- deleted 6y ago
  [deleted]
flowardnut 6y ago
Excuse me, it isn't a real frontend without a service worker and offline capabilities.
mercer 6y ago
Just use Next! I mean Nuxt! I mean really just give up and go for Phoenix LiveView or TurboLinks or Blazor...

simple_phrases 6y ago

People were still writing CoffeeScript in 2015.

bernawil 6y ago

Agreed, but I wouldn't put 2015 as the year React "won". It did "win" the SPA frameworks war, but back then the default for webdev was still non-SPA and React was competing with jquery/"no framework" and the rest of not-quite-spa frameworks like backbone, ember, etc. Nowadays React is the standard, I dare say even for SSR sites! The javascript framework fatigue meme was born during the early days of ember, backbone, angular 1, knockoutjs and meteor. Sometime between 2016 and 2017 was when it should have been put to rest.

throw_m239339 6y ago

Angular(1) wasn't simple but knowing basic stuff made it possible to do complicated things quickly. Angular lost a lot of momentum when they decided Angular had to look like JEE and become a framework trying to justify its existence with complexity. React had the right idea, just make view management simple, don't force some bullshit IoC container on Javascript and that's it. If you want IoC that's your problem. Ultimately the problem is that nothing replaces React natively in web API. A tool such as React shouldn't be useful anymore and Web Components isn't as ubiquitous as it was envisioned to be. In fact, I've never worked in any business that used Web Components. But the biggest issues are on the node.js side and all the complex pipelines put in place in order to fix front-end development. In fine, the tools that will be successful are the ones that will still be actively maintained 5 years from now, and most of the libs/projects will not.

kls 6y ago
I see it a little differently, Angular 1 lost momentum because it was a bad framework. It was clearly written by people that did not have a lot of experience productionalizing code. Further they choose new and convoluted naming for concepts that already had names. The came up with a creative new way to introduce globals thru rootscope and performance was abysmal. Their component model was leaky at best and the whole framework encouraged writing monolithic controllers that where in the same vain of Backbone.js. There where actually good frameworks at that time such as Dojo they just did not get the mindshare that Angular got and a lot of that was due to it being incubated at Google. The second part of the issue is there where not many people doing hardcore Javascript programming and so there was not a depth of deep CS knowledge in the front end space. It took more and more of them reluctantly converting over, getting one look at Angular and going look guys this is bad because of X,Y and Z. Angular 1 actually set the state of the art back compared to some of the other offerings at the time. The absolute tell, was when the team had to admit it, admit they where going to scrap it for a total rewrite that was to become Angular 2 and on. The reason React has done so well, is that core team members had deeper CS experience, understood other paradigms for UI development and understood that the best state of the art for UI right now, is a render loop. If you converted it to C, squinted at it long enough you would see the very old, very tried and very true Windows render loop in it. They took a proven pattern, bolted it to the virtual DOM and brought it to the web. They did not perform miracles, they stuck to what has been proven to work. Well the virtual DOM was a pretty clever hack, but the rest is UI dev 101. The problem was most the JS developers at the time, never had that back experience of desktop UI development and a good deal of them had come to development by way of learning HTML, CSS and then bits and pieces of JS as they needed to.

knolax 6y ago

But how long was Angular in vogue before React? If it was also ~5 years then a shift in frameworks every 5 years of calm + 2 years of chaos still isn't ideal.