> Prior to that, there was a different approach and philosophy
I don't really agree. Context and Provider have existed forever. Hooks really just expose the underlying setState calls with a different API and a more graceful backing engine which allows this more granular access. It's part of why they made hooks
> I remember when higher order components were all the rage till suddenly they weren't
I almost never used these, but what was their main point? You wrap something in a HOC to inject some variable, like a router or something? No kidding we moved on, no need for this to be so heavy. Again, you're kind of understanding why they made hooks, this type of functionality can be and is written more concisely with them
> everything in JS land feels experimental, and the entire community keeps marching along as things keep changing
UI engineering and the web as an application platform isi young compared to "pretty much any other software engineering field", don't you think? JavaScript was kind of a shit language 7 years ago too, so a lot of this churn is because first JS improved a lot and then still needed types so we played with a few type systems.
Now we have TypeScript making beautiful, readable, maintainable code, and battle-hardened yet concise libraries like React, because we were willing to say "hey this could be better, let's try a new way". Seems weird that everyone criticizes that so harshly, don't you think?
> I personally could not stand redux
I also don't understand its popularity. I avoided it from the start and opted for MobX
> large, enterprise app in React
> I would place a much higher emphasis on a more stable development environment/language/framework
I mean, no offense, but React is about the most stable UI framework there is. If you don't like JS and you're going to do this by generating HTML reports from some other language, I think whatever you build is going to feel behind the times.
> Let's take Pytorch as a comparison
> the core API has stayed the same
> I ported 3 year old code to the latest version with pretty much 0 effort
Right, how is this not comparable to React? I can run and build my 3 year old code against the newest version with no porting required. Porting from class-based to functional with hooks is also quite easy; I moved my entire component library (25+ components including graph + charts) in a few weeks, and it came out smaller and more performant.
> Similarly with Python
I actually don't think I would try and cite the Python 3 transition favorably if I were you; it was not smooth.
> On the other hand, porting a 2+ year old React app to the latest version of React would be a very painful process
!? It runs against the latest version of React!! Why do you need to port it?
Also, I'm imagining your app has significantly more complexity than your PyTorch app - otherwise this claim seems even more absurd.
> Finally, I should state that I actually love javascript
Yes, ES6+ JS is strong, with TypeScript it's actually a top language overall. I also work on a small team, and am responsible for UIs, APIs, database design, DevOps, and more. Each of these fields undergoes this massive churn as well; databases tried to go NoSQL on us, APIs are low-code now for CRUD and you're a sucker if you manually write your CRUD apps, DevOps has completely changed from rsyncing bundles to container orchestration deployments running on Kubernetes, ML and data science have reinvented themselves to use new features and more powerful toolsets.
UI development is a complex and young topic and so while you might feel it has churn, all software is constantly undergoing churn to match the community's desire for how expressive and powerful it should be. The fact that people constantly rag on UI toolkits being updated over time makes me think they fail to recognize UI as complex or young. I feel like you fell for it too, because each domain you listed yourself as working in has undergone similarly drastic changes in the last 5 years as React has.
I don't really agree. Context and Provider have existed forever. Hooks really just expose the underlying setState calls with a different API and a more graceful backing engine which allows this more granular access. It's part of why they made hooks
> I remember when higher order components were all the rage till suddenly they weren't
I almost never used these, but what was their main point? You wrap something in a HOC to inject some variable, like a router or something? No kidding we moved on, no need for this to be so heavy. Again, you're kind of understanding why they made hooks, this type of functionality can be and is written more concisely with them
> everything in JS land feels experimental, and the entire community keeps marching along as things keep changing
UI engineering and the web as an application platform isi young compared to "pretty much any other software engineering field", don't you think? JavaScript was kind of a shit language 7 years ago too, so a lot of this churn is because first JS improved a lot and then still needed types so we played with a few type systems.
Now we have TypeScript making beautiful, readable, maintainable code, and battle-hardened yet concise libraries like React, because we were willing to say "hey this could be better, let's try a new way". Seems weird that everyone criticizes that so harshly, don't you think?
> I personally could not stand redux
I also don't understand its popularity. I avoided it from the start and opted for MobX
> large, enterprise app in React
> I would place a much higher emphasis on a more stable development environment/language/framework
I mean, no offense, but React is about the most stable UI framework there is. If you don't like JS and you're going to do this by generating HTML reports from some other language, I think whatever you build is going to feel behind the times.
> Let's take Pytorch as a comparison
> the core API has stayed the same
> I ported 3 year old code to the latest version with pretty much 0 effort
Right, how is this not comparable to React? I can run and build my 3 year old code against the newest version with no porting required. Porting from class-based to functional with hooks is also quite easy; I moved my entire component library (25+ components including graph + charts) in a few weeks, and it came out smaller and more performant.
> Similarly with Python
I actually don't think I would try and cite the Python 3 transition favorably if I were you; it was not smooth.
> On the other hand, porting a 2+ year old React app to the latest version of React would be a very painful process
!? It runs against the latest version of React!! Why do you need to port it?
Also, I'm imagining your app has significantly more complexity than your PyTorch app - otherwise this claim seems even more absurd.
> Finally, I should state that I actually love javascript
Yes, ES6+ JS is strong, with TypeScript it's actually a top language overall. I also work on a small team, and am responsible for UIs, APIs, database design, DevOps, and more. Each of these fields undergoes this massive churn as well; databases tried to go NoSQL on us, APIs are low-code now for CRUD and you're a sucker if you manually write your CRUD apps, DevOps has completely changed from rsyncing bundles to container orchestration deployments running on Kubernetes, ML and data science have reinvented themselves to use new features and more powerful toolsets.
UI development is a complex and young topic and so while you might feel it has churn, all software is constantly undergoing churn to match the community's desire for how expressive and powerful it should be. The fact that people constantly rag on UI toolkits being updated over time makes me think they fail to recognize UI as complex or young. I feel like you fell for it too, because each domain you listed yourself as working in has undergone similarly drastic changes in the last 5 years as React has.