4 ms·

I love it when people phrase this as a frontend problem. It's not a frontend problem. It's just a "it's a huge ecosystem with new players" problem. I've seen t

I love it when people phrase this as a frontend problem. It's not a frontend problem. It's just a "it's a huge ecosystem with new players" problem. I've seen this in Java 15 years ago when it was the front of innovation (I can name dozens of frameworks, and a half dozen build systems coming out in as many years). React 17-18 is quite a minor change then perl 5->6 or python 2->3 For backend instead of "let's use this new framework", I get the "let's use this new LANGUAGE" - the newest hottness is to rewrite something in Rust. It was Go before that, haskell, scala, F# (yes I got that too). You think migrating your frontend code from react to svelte or whatever is troublesome, trying rewriting that VB 6 app :) (Or god forbid something like RPC where your data is in the code) Not saying that the unstableness of engineering practices aren't a problem. It's a huge problem. Just that it's not a frontend problem.

dpcx 2y ago
React has been around for 11 years. The amount of stuff that's online that tells you to do something with it one way when the react devs tell you to do it another is _astonishing_. And that's just from the last few years. Or take webpack that's been around for 13 years. The way things are set up even within the last few years have changed dramatically. If Apache configs moved as much as these systems did, no one would use Apache.
- montag 2y ago
  imo, the Webpack situation is worse. React's evolution has been more incremental/cumulative. Best practices evolve, but not too much truly needs to be forgotten.
- theknarf 2y ago
  No one is using Apache... Almost everyone moved to Nginx years ago xD
  - le-mark 2y ago
    The configs are very similar though, the reasons for the move were technical and performance, for whatever that’s worth.
acjohnson55 2y ago
Scala, in and of itself, would have entire revolutions every year.
h4ny 2y ago
Anecdotal: I agree because everywhere I have worked were backend-senior heavy -- they think frontend is easy and not worth touching, and they are the ones who makes decisions on "the next shiny things" for backend things. In my last job, databse migrations happened twice in just two years and we spent a total of one year of engineering time on it -- every single table, not just some non-critical ones. When things broke or when upper management was asking why thigns were so slow, they just blamed the front-end learning engineers for not being experienced enough.
rufus_foreman 2y ago
>> It's not a frontend problem From my perspective as a Java developer, it's a frontend problem. I've been employed as a Java developer for over a quarter of a century. For a little over the first ten years of that, I did full stack development, and that was the norm at the companies I worked for. That has changed where it is now typical for there to be a separate team for frontend, and often three teams for frontend (web, iOS and Android). For me that change was around the time of AngularJS -> Angular. Yes, Java was changing rapidly in the first ten years or so, very rapidly in the first 3 years. But that is over. Java 5 was a huge change, and there were some major features in Java 8, but Java 8 was in 2014. My team only switched to Java 11 recently. Java 24 is out now. I haven't used any Java 11 features. I don't even know what they are. I haven't learned a single new language feature for a decade. Build tools are the same for the last 15 years. IDE is the same for the last 20 years. The main frameworks I use have been the same for 10 years. When I switched to my last job, the code base was structured exactly the way my previous team's was. Building web services in Java is a solved problem. It's completely boring, in a good way. It's COBOL. Frontend was changing rapidly in the late 90's/early 00's also, but it has kept changing rapidly the entire time since then. The pet UI project I build a few years ago is completely outdated. Any of the Java projects that I worked on in the post-EJB era, you could easily find a Java developer today who could step in and immediately be productive working on them, even if the developer wasn't born yet when they were created. There would be a few outdated libraries to learn, maybe.

dpcx 2y ago

React has been around for 11 years. The amount of stuff that's online that tells you to do something with it one way when the react devs tell you to do it another is _astonishing_. And that's just from the last few years. Or take webpack that's been around for 13 years. The way things are set up even within the last few years have changed dramatically. If Apache configs moved as much as these systems did, no one would use Apache.

montag 2y ago
imo, the Webpack situation is worse. React's evolution has been more incremental/cumulative. Best practices evolve, but not too much truly needs to be forgotten.
theknarf 2y ago
No one is using Apache... Almost everyone moved to Nginx years ago xD
- le-mark 2y ago
  The configs are very similar though, the reasons for the move were technical and performance, for whatever that’s worth.

acjohnson55 2y ago

Scala, in and of itself, would have entire revolutions every year.

h4ny 2y ago

Anecdotal: I agree because everywhere I have worked were backend-senior heavy -- they think frontend is easy and not worth touching, and they are the ones who makes decisions on "the next shiny things" for backend things. In my last job, databse migrations happened twice in just two years and we spent a total of one year of engineering time on it -- every single table, not just some non-critical ones. When things broke or when upper management was asking why thigns were so slow, they just blamed the front-end learning engineers for not being experienced enough.

rufus_foreman 2y ago

>> It's not a frontend problem From my perspective as a Java developer, it's a frontend problem. I've been employed as a Java developer for over a quarter of a century. For a little over the first ten years of that, I did full stack development, and that was the norm at the companies I worked for. That has changed where it is now typical for there to be a separate team for frontend, and often three teams for frontend (web, iOS and Android). For me that change was around the time of AngularJS -> Angular. Yes, Java was changing rapidly in the first ten years or so, very rapidly in the first 3 years. But that is over. Java 5 was a huge change, and there were some major features in Java 8, but Java 8 was in 2014. My team only switched to Java 11 recently. Java 24 is out now. I haven't used any Java 11 features. I don't even know what they are. I haven't learned a single new language feature for a decade. Build tools are the same for the last 15 years. IDE is the same for the last 20 years. The main frameworks I use have been the same for 10 years. When I switched to my last job, the code base was structured exactly the way my previous team's was. Building web services in Java is a solved problem. It's completely boring, in a good way. It's COBOL. Frontend was changing rapidly in the late 90's/early 00's also, but it has kept changing rapidly the entire time since then. The pet UI project I build a few years ago is completely outdated. Any of the Java projects that I worked on in the post-EJB era, you could easily find a Java developer today who could step in and immediately be productive working on them, even if the developer wasn't born yet when they were created. There would be a few outdated libraries to learn, maybe.