Comment by apotheon | Hacker News Reader

Comment by apotheon | Hacker News Reader

Parent Full thread

I enjoyed the hell out of writing application plumbing, but the moment it started turning into an actual application that interacted with the outside world I was dealing with the hell of the Node ecosystem of "compiling" and packing for the browser, framework crap, buggy testing libraries, and all the rest of that nonsense, with an acutely clear understanding that all of it would change in five years and I would have almost zero useful knowledge from the tooling and ecosystem experience of the preceding half-decade.

In the mainstream professional JavaScript world, my advice is to escape as quickly as you can, and pursue things where the learning focus is on more interesting things than the arbitrary whims of the authors of half-baked (because they never have time to mature before they die) frameworks. If you can just live on the fringes and write JavaScript your way and not worry about constantly impending obsolescence of your entire technology stack (from Linux all the way up to your JavaScripty CSS framework), though, I'm sure you can have a great time doing it.

I'm writing a lot of C and Ruby these days, and I love it. I get to learn more about myself as a programmer, instead of more about other programmers as fly-by-night framework developers.

I'm not really sure what you mean by "constantly impending obsolescence", but as one anecdote in the face of that: I have plenty of core JS code in production that was written 3-4 years ago. I've gradually improved or changed parts of this codebase but that had absolutely nothing to do with external libraries of which I use very few... this feels very unchanging to me, my code is not about to implode due to any external reasons.

I write my own UI/MVC type code from scratch just because that's the way I roll and my requirements there are a combination of minimal, extremely performance sensitive and in many cases esoteric where I have to write the UI anway so it's not much work compared to forcing existing libraries to do what i want... but if had to I could replace it with some hip and upcoming UI + MVC library and still keep 95% of my core code completely independent and intact.

I think JS world feels like massive churn if 90% of what you are doing is UI UX etc, because that's the interface that can never sit still in the name of progress... either that or you (not you necessarily) are doing it wrong and not separating UI code from your application code (I've seen this happen quite a bit in ye olden angular days where everything becomes attached to angular for no apparent reason, and angular itself is the worst of OOP + MVC where everything is convoluted and difficult to follow).

If you're basically building everything from scratch, of course you aren't going to see the churn as much.

If you build on others' frameworks, and those frameworks drop out of maintenance because the maintainers moved on to shiny new things, any security vulnerabilities or emerging incompatibilities with browsers can quickly prove ruinous for people who used those frameworks.

I wrote a SPA while working at a consultancy. It was actually pretty churn-proof the way I wrote it, but during one vacation day and the following weekend a couple people (including the boss) just rewrote the whole thing to use more faddish framework stuff. I don't work there any longer, but since then (about 2016) they've probably had to effectively rewrite it twice if they kept up with that approach.

That's what I mean by "constantly impending obsolescence".

Reply on news.ycombinator.com