Hacker News Reader

> ...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.

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!

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.

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!

Thank you, glad to hear RTK is working well for you!

FOMO?

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.

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?

Unfortunately it is necessary to stay employable. I hope I am wrong, but a react novice might get more interviews than a JQuery expert.

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.

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.

>> 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.

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.

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.

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

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.

Because being “behind” on front end technologies is a sure fire way of ending up jobless and irrelevant.

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.

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.

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.

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"

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.

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.

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.

> but the page is rendered before it even reaches the client

Which is what PHP was built for.

> If people could try to understand SSR before diminishing it, we could have much more productive discussions.

If new generation of frontend people could try to understand PHP before diminishing it, we could have much more productive discussions.

You can't just crop out half the sentence and make an equivalency. The full sentence was

> You get to use client-side frameworks, but the page is rendered before it even reaches the client

Does PHP run in the client? No? Then it's not the same as SSR. You have it completely backwards. I understand PHP but you clearly don't understand SSR

To clear up some confusion, I believe people are using the terms SSR and hydration interchangeably. Hydration is a new technology that uses SSR and then adds reactivity: https://en.wikipedia.org/wiki/Hydration_(web_development)

The server code will use the framework to handle SSR and hydration. Meaning that all you have to do is write the frontend and you get SSR for free.

If I'm not mistaken, GWT did hydration way back in 2010.

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.

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.

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.

> 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/

Try flutter, its a breath of fresh air!

Does Flutter still render everything in a canvas? This has been a huge turn off for me.

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.

aaand we're all the way back to Flash.

Adobe (now Apache) Flex.

To be fair web content can also be ported easily pretty much everywhere because browsers run almost everywhere.

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.

Until a blind person contacts your support team to tell them your website/webapp is not working with their screen reader.

Flutter has accessibility FYI. It creates a parallel accessibility tree in the DOM that screen readers can read.

https://docs.flutter.dev/development/accessibility-and-local...

hah. I remember having to build HTML-only fallback versions of fancy Flash UI sites back in... 2002 to around 2008. We marketed this as an add-on for improved SEO. Allegedly Google used to manually check if the content matched what was in the Flash version and knock you down if it wasn't. That was probably just a rumor.

The lack of native scrolling kills it for me. It's painfully obvious using a flutter app on iOS, since the scrolling momentum is way off.

You never really think this stuff matters until you're exposed to it.

I can't wait for deno.js to really skyrocket. It solves all of this garbage packaging dependency nonsense.

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 ?

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.

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.

No, it doesn't. All Deno does by ignoring dependency management is creating a breeding ground for worse dependency management.

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