6 ms·

Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools" t

• 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 ago
    This. 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 ago
      i 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 ago
        I 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 ago
      Thank you, glad to hear RTK is working well for you!
  • croes 4y ago
    FOMO?
  • monkey_monkey 4y ago
    Because 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 ago
      This 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 ago
    Unfortunately 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 ago
      But 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 ago
        But 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 ago
      In 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 ago
        But 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 ago
        The 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 ago
    And 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 ago
    Because being “behind” on front end technologies is a sure fire way of ending up jobless and irrelevant.
  • verisimilidude 4y ago
    If 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 ago
    Because 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.
• devxpy 4y ago
  Try flutter, its a breath of fresh air!
  • finfinfin 4y ago
    Does Flutter still render everything in a canvas? This has been a huge turn off for me.
    • cercatrova 4y ago
      Yes, and that's the main reason why I like it. You can do advanced UIs and animations that would otherwise be very annoying in other frameworks like React Native. Plus, a canvas makes it easy to port to other platforms like desktop and web because all you need is the ability to draw pixels on a screen.
      • noduerme 4y ago
        aaand we're all the way back to Flash.
        • boobsbr 4y ago
          Adobe (now Apache) Flex.
      • leodriesch 4y ago
        To be fair web content can also be ported easily pretty much everywhere because browsers run almost everywhere.
        • noduerme 4y ago
          But it's more fun to rebuild the DOM inside a canvas. Then you can run it in another DOM inside a canvas inside a DOM, and stream the whole thing from a server into a thin client and call it a native app.
      • martpie 4y ago
• somenewaccount1 4y ago
  I can't wait for deno.js to really skyrocket. It solves all of this garbage packaging dependency nonsense.
  • cto_official 4y ago
    was just reading about them, the were trending on github today.. if we want to port an existing typescript project to deno any ideas how complex it would be ?
    • GiorgioG 4y ago
      I'd guess it would not be trivial. NPM packages are not compatible out of the box. There are workarounds, but generally speaking it's still (relatively) early days in Deno-land. Having said that, I've been playing around with the Deno Fresh framework and it's been a refreshing experience compared to typical TS based web app development.
    • simlevesque 4y ago
      At this point it would almost require a full rewrite. I use it for a new projects. But things like using Vue is really hard, some packages help but they are also buggy.
  • hobofan 4y ago
    No, it doesn't. All Deno does by ignoring dependency management is creating a breeding ground for worse dependency management.
• deleted 4y ago
  [deleted]
• vultour 4y ago
  It's hilarious listening to my friends who do frontend rave about the the incredible framework of the month, every month there's a new one that's supposed to be the last, ultimate, final stop for developing frontends. Lately it's all about server-side rendering... they managed to reinvent PHP 25 years later with 100x the complexity.
  • wonnage 4y ago
    I don't really understand these sorts of low-effort comments. You're probably referencing the React Server Components that were recently proposed. React has supported server side rendering basically since its inception. The problem with most existing SSR implementations in any language is that it's a one-shot synchronous process which doesn't allow for out of order streaming. For example, you might want to render a loading state and replace it with content once some network call returns. This used to take multiple requests; you get the initial page, some JS makes the network call, then you might need to download even more JS to render the result. Now you can do it all in one shot with (almost) no JS; the server can stream this entire sequence of HTML chunks in one response. That's pretty useful and it's not "PHP 25 years later with 100x the complexity"
  • selfmodruntime 4y ago
    This is really untrue. The complexity of large PHP projects could get insanely high. The advantage of using SSR in JavaScript is that your entire application speaks the same language as the browser does, so sharing code between server and client becomes incredibly easy.
  • dimgl 4y ago
    It's not PHP. It's not even close to being PHP... SSR frameworks are truly impressive pieces of technology that might impress you too if you weren't raging uncontrollably.
  • deleted 4y ago
    [deleted]
  • woojoo666 4y ago
    This gets repeated in every thread about front-end tech, and every time people have to repeat the same explanation. SSR is not PHP. SSR allows you to run the same code on client and server. You get to use client-side frameworks, but the page is rendered before it even reaches the client. If people could try to understand SSR before diminishing it, we could have much more productive discussions. But as of now the frequency of these uninformed comments makes me feel like people who are ignorant about front-end, are somehow proud of their ignorance.
• martini333 4y ago
  • dang 4y ago
    Whoa - we ban accounts that attack others like this, regardless of how dense other commenters are or you feel they are. I'm afraid you've been breaking the site guidelines in other places too (e.g. with unsubstantive and/or flamebait and/or name-calling comments). I'm not going to ban you just now but if you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
• wonnage 4y ago
  The saving grace of frontend is that debugging is really easy. You can inspect the actual code of all your dependencies in node_modules, and they're almost always on github too (in case they bundled/minified code). The programs are mostly single-process and single-threaded. The same Chrome devtools you use to debug in the browser are used to debug NodeJS code. Yes, it's stupid that sometimes you have to set a breakpoint inside a webpack plugin to figure out what's going on, but at least it's an option. And as other commenters have echoed - you don't have to use any of this stuff. Most of it is short-lived and low-quality anyway. Half the time it's just an excuse for someone to write a blog post for clout. Expertise is as much about filtering out noise as it is digging deep into things. People complain a lot about bundlers in particular. Bundlers are "just" string concatenation. It's an easily understandable problem with a lot of weird edge cases. So you wind up with bikeshedding and a lot of bundlers and what looks like unnecessary complexity. But there's little payoff to really "learn" a particular bundler. It's more important to learn why bundling is necessary (the Vite FAQ does a decent job of this) and then some of the features that can make it complicated (e.g code transformation). Then you become an expert on the underlying problem of shipping the minimal amount of code to the browser, which isn't going anywhere. You can then understand what differentiates bundler A from B. It's usually not much beyond a simpler config file. Despite all the new hotness that exists today, the outdated Webpack 4 has feature parity with pretty much any bundler out there.
• darksaints 4y ago
  I too find this exhausting. However, to be completely fair, front end was a 100% no-go for me before 2015, and improvements to the language and improvements to the ecosystem have turned it into something that I can deal with occasionally without wanting to murder anybody. ES2016+, better build systems, better package management, typescript, etc., have all made huge strides in front end development. It could still do without the framework of the month trendiness, but eventually dumb ideas die and good ideas succeed.
• Nu-biscuit 4y ago
  I had the exact opposite experience with Vite. We had built a web application and had an existing rollup build process configured for all the obvious things you can think of (including SVG and JSON files, path aliases, development server with watch, typescript support, etc). One week I got approval to try migrate to Vite and it was pretty much: delete the existing config, use the default Vite one, and remove all your rollup plugins from package.json (since Vite does all the obvious stuff out of the box). I was using Rider and had no issues at all. It was automatically using my path aliases. It understood importing SVG and JSON files. I got intellisense for all Vite APIs. Maybe I had some plugins installed or settings enabled from when I was using rollup, but there's nothing obscure as my IDE setup is pretty vanilla.
• qudat 4y ago
  > Working with front end for 5+ years have nearly made me switch careers. There's an absolute onslaught of languages, frameworks, patterns and now also "tools" Don't get into devops/infra if JS fatigue is an issue: https://landscape.cncf.io/ https://landscape.cncf.io/
• intellix 4y ago
  Since Angular CLI I've probably not thought about tooling in about 6 years now. It just works, it gets better and it essentially upgrades itself