Hacker News Reader

Comment by nlnn | Hacker News Reader

As a primarily backend person, it's always interesting to read about this sort of thing as an outsider with little appreciation for the nuances/challenges people face using these frameworks.

I keep hoping things will settle a bit more so that I can someday pick one to learn in depth without worrying about it being replaced by the next hotness.

Am I right in thinking the state of major players is roughly:

React - incumbent, slow, vast, but widely used Vue - main challenger to React, aimed to fix many issues, but 2->3 migration tricky Svelte - lighter compiled alternative for smaller projects, faster, but more niche Solid - even faster, more similar to React, but too new/small for bigger projects

View on HN

I keep hoping things will settle a bit more so that I can someday pick one

You are in the wrong industry, to think this will happen any time soon.

Change has been fast in computing, for decades. Stand still, and you are overrun and eventually your knowledge moves towards irrelevance.

Doctors need to keep up to date with new medical information, new drugs, new warnings about drugs, new techniques.

Lawyers need to read caselaw, keep up to date on new legislation.

Both are arduous tasks for those professions.

Yet there is more to keep up to date in computing, in a year, than any doctor or lawyer must keep pace with in their lifetime.

So either dive in and learn, learn, learn! Learn for the joy of it, for the fun!

Because there is nothing to wait for.

Because change will never stop here.

Frontend changes seem to be the changes for the sake of the changes.

Last time there was a meaningful major improvement is when React devs came up with practical implementation of view=f(model) idea.

This is a common rebuttal against any dissent against the insane flux of the front end space and I genuinely don’t believe that anyone with significant experience in software actually believes it.

The front end space is really quite unique in its fragmentation and pace of change. Things are…maybe starting to cool down a touch, but not really. We can talk til the cows come home about how this or that have caused things to be how they are, but simply chalking this up to “things change fast in tech” - beyond just being a thought-terminating ‘shrug your shoulders’ platitude that I’d probably hear from a non-tech family member over Christmas lunch - is really missing most of what’s going on here.

Front end doesn't change that much from an implementation and coding perspective.

To that I mean, if you could code 5 years ago, and deploy a front end of any sort 5 years ago, you won't have many issues today.

People still use redis/memcached, mysql, php, apache2, with laravel for example.

And solutions such as docker, with unvetted builds snagged from random people, are no different, functionally, than a VM or even a bare metal cluster.

I will agree that the absurd node ecosystem, with its unsecure, unauditable packages, composer and its insane web of just stupid dependancies are ridiculous.

But that's not rapid change of method or coding language, just because behind the scenes it's all just language such as php.

So sure, the cruft is just that, but the meat is what drives change, and a lot of it.

As a backend person that used to be a front end person, there has never been a better time for using VanillaJS (or TypeScript), HTML, and CSS?

> someday pick one to learn in depth without worrying about it being replaced by the next hotness

So maybe the trick is to not use a framework. Like, I don't need a "framework" for backend dev, just a toolbox of good libraries.

The tooling around TypeScript is similar to a backend language like Go, a very different experience from writing JavaScript a decade ago

There's always one.

If you’re working on a reasonably sized project “without a framework”, and haven’t effectively built your own, I’m very skeptical of the engineering practices at play.

Not using a framework doesn't automatically imply everything is built from scratch. Maybe I prefer calling libraries, instead of plugging my code into a framework. I could also implement patterns using the batteries included features of the platform. For example Web Components on the frontend, or a REST API on the backend built using the standard Go "net/http" package

Maybe Vue and Svelte are different. But something like react is "just a library", right? So they must be greenspunning their own framework as well, by their own admission.

So then ask yourself the question - which underlying tech of your in house framework is going to be more stable, supported, have better tooling, and be easier to reason about. I'd pick the DOM every time.

Reply on news.ycombinator.com