5 ms·
> ...and you never really grasp before moving on to the next thing. Then why do you move on to the next thing? Not a frontend dev, but I notice that a lot of
by rvdginste 4y ago
> ...and you never really grasp before moving on to the next thing.
Then why do you move on to the next thing?
Not a frontend dev, but I notice that a lot of frontend devs seem to be really eager to jump to the next hot thing when it becomes available, even though the thing they are using is still well maintained.
- nikodunk 4y agoThis. As someone who's hung back and not switched to the hot new thing in frontend - I've learned the "old" stuff seems to mature and tends to get better. Look at React, CRA, or Redux Toolkit - they're all so much better (performant, more concise) than the original few releases now!
- 5350-uiop-1130 4y agoi dont think you find words like "deprecated" or "sunsetted" in any field as much as front end websh*t. react has changed a lot. i mean hooks pretty much is a rewrite or rethink of core concepts. nothing wrong with that per se, just that things just move to fast, there is no respect for long term stability and web seems to have a greater share of shiny new thing contrarian hipsters.
- ketzo 4y agoI mean, for one thing, Hooks are more than three years old at this point. And for another, you can use React without writing a single useEffect(). Class components are still very much a thing!
- acemarke 4y agoThank you, glad to hear RTK is working well for you!
- croes 4y agoFOMO?
- monkey_monkey 4y agoBecause all the upkeep happens on the new shiny toy, leaving the old ones to fester and rot away. Heaven help you if you need to go back to a site you built for a client 4 years ago and try to make changes now. 90% chance that your build toolchain will be completely broken and fail to work.
- noduerme 4y agoThis is why I just roll my own and don't use frameworks like React. I've been building and rebuilding apps for clients for 15 years, so basically have my own ways to spin up an app within hours. Yeah, I still use jQuery for some things, who cares if it works?
- francisofascii 4y agoUnfortunately it is necessary to stay employable. I hope I am wrong, but a react novice might get more interviews than a JQuery expert.
- matt89 4y agoBut React is now probably about 7-8 years old. Is it really this shiny new technology that "everyone must jump to"? Yes jQuery devs probably don't get a lot of work right now, and yes you probably should keep up with React itself. But I don't think that it is necessary to literally switch technology every 1-2 years to keep up, if we can use React (or Vue) which has been stable for a while and is still wildly popular.
- simlevesque 4y agoBut aren't the React devs of today the jQuery devs of tomorrow ? Meaning that if you keep that same technology forever you will lose relevance in the market.
- skeeter2020 4y ago>> even though the thing they are using is still well maintained. I think you mean "even IF the thing is still maintained". This is a big IF. Something as ubiquitous as a React app may still work fine after a few years, but try updating or fixing something and you're in for a world of hurt.
- leodriesch 4y agoIn my experience dealing with the tooling is fine for ongoing projects by just checking for updates every week. But it is very stressful to update from Webpack 2 to 5 for example. So taking an old project from a couple of years ago and updating the dependencies is not that easy, especially if you were using a lot of the build tools features.
- CaptArmchair 4y agoBut that's where you have to balance the gain updating the old toolchain against the benefits in your specific situation. Are you going to spend a lot of time on the project, or is it just a few bug fixes? Can you revive the old toolchain? Is the old toolchain churning out good enough production ready assets? Upgrading dependencies can be a trap. Like, in the past, I've delegated a bugfix that shouldn't take more then an hour or two to a co-worker, only to see them waste an entire day in dependency / NPM hell. To my mind, there needs to be a compelling case or argument that justifies sinking time in an upgrading exercise.
- jchw 4y agoThe biggest problems come in when your apps are doing hacky things they shouldn't be doing. This is a common issue with things like Electron, or React Router, and of course, Webpack. If you are fairly careful and conservative, and lucky enough to be using software after it has matured, I think most upgrades will wind up being pretty uneventful for you. I'm saying it explicitly: your exception project probably sucked. That's probably why it was tricky to upgrade. It may not have been your fault or even the fault of the people who wrote it. But for example, it was never architecturally a good idea to have Webpack automatically import browserify Node stubs. It was never a good idea to load Node modules from within an Electron renderer thread. Not always your fault. A reasonably well-archirected app usually refactors decently into changes that fix these issues. A poorly architecture app is so fragile it's hard to imagine refactoring anything without something breaking a few miles away. If you have the latter, then no shit that upgrading dependencies sucks... I mean, changing anything else sucks too. This isn't the root cause of every horror story... But it's a lot of them
- nazka 4y agoAnd then you have someone down the comment telling him to try the next thing Flutter or whatever. It's a never ending. HN and tech is both full of people like you say and want stable stacks but also full of people wanting to try the new thing. For me React have been doing all and beyond for me on a dev and business pov and will continues for a log time hopefully a decade. But it's frontend so it's already weird that it stayed that long.
- dclowd9901 4y agoBecause being “behind” on front end technologies is a sure fire way of ending up jobless and irrelevant.
- verisimilidude 4y agoIf we're being really honest, I switch to the next thing because it's fun. The more official reason to move to the next thing is because browsers are a moving target. Browsers are constantly releasing new capabilities. And the overall population of users is always moving onto newer versions of those browsers; even if that migration lags a bit, it happens. When we can use those newer browser features, we can provide better services to users. Vite is exciting because it's built on top of the native ES6 features that are now ubiquitously supported by most browsers. It's such a smooth ride compared to older tools. The dev experience is great, and the end-user bundles are light. I've been very impressed with it. I sympathize with your sentiment when it comes to the back-end. I want stable tools there. But until the front-end platform (browsers) is similarly stable, some churn will be welcome to support emerging possibilities.
- mrisoli 4y agoBecause it's easy money(and as others said, to stay employable). If someone created a framework yesterday there are few experts, and they won't judge experts by years of experience, if you're a relatively new FE in the job market would you go compete with people with 15+ years of jQuery and 8+ years of React or just take on the next new thing? If you pickup the latest tooling today by the time it's widespread(like React is now) you're way ahead of the crop and it's quite easy to get some nice pay out of that.