311–320 of 722 posts
Earlier quoted context omitted.
I've been writing React professionally for over a decade and React from 5 years ago is obsolete. Like, literally won't build with current tools. To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. EDIT: Forgot about component lifecycle methods... Even a…
> To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. That's a problem with your build system then, not React. There is (or was) indeed a lot of churn in build systems, but you wouldn't have been spared unless you had chosen to not use a build system -…
Did you read the sentence that you're "correcting"?
> My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.
Your optimism is admirable.
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.
Earlier quoted context omitted.
Not sure it's fair to characterize a repo with 6k + commits and the last being 10 hours ago as "pure grift".
E.g. react-router was ready 5990 commits ago. It is a grift, they keep rewriting it and reengineering the API over and over and over again just to be able to sell more training. Look at wouter for what is possible if your motivation isn't selling training material. It was written and left alone, it works just as well, it's stable and doesn't change for no reason.
> Whatever framework you choose will be obsolete in 5 years. I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam…
I think this is true but also misses some aspects. Take Angular as an example. Angular1 and 2 cannot be compared at all, they were basically nothing alike except for the name. This burned many developers. But Angular itself is also changing quite drastically. Not as severe as with the shift from v1 to Angular2, but still severely enough that it would require some major re-adjusting. Everything is moving to standalone components, new template syntax, signals, etc.
Similar things can be said about React. React hat a major paradigm shift with the advent of functional components and hooks. They were compatible, but very different from another.
And the same thing kind of applies for less specific paradigms. First everything was SSR, then we went full steam into Single Page Apps only to return back to SSR but only partial SSR with Hydration, etc.
Earlier quoted context omitted.
I've been writing React professionally for over a decade and React from 5 years ago is obsolete. Like, literally won't build with current tools. To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. EDIT: Forgot about component lifecycle methods... Even a…
If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools. You need to pin your dependencies and use the same versions of the tools as before. It'd be the same thing with libraries if you didn't have a lockfile. Your development tools need one too.
Bold of you to assume I have worked in React for this long and somehow didn't know about this brittle solution to a problem which shouldn't have existed in the first place.
How does your solution handle packages that no longer exist? Let me guess, we back up the packages? Okay, so these packages don't run on new versions of relevant binaries--do we back up the binaries as well? How bad does it have to get before you admit it's a tire fire?