Ask HN: Riding the Roller Coaster of Development Tooling | Hacker News Reader

Ask HN: Riding the Roller Coaster of Development Tooling

9 pointsbronlund27 comments

There are so much happening these days that I feel I have to make an effort in order to not fall behind. And when I stumble upon a new tool, framework or platform or whatever which seems to make a difference, I think; this sounds real neat, let's check it out.

Then, when I try to figure out how, there it comes: "npm blah blah blah", and my heart just sinks. And I regret not being more vocal about how stupid this whole node thing was when it startet. And I wonder how many years we are going to have to deal with this stuff.

My question is this: Is it just me? Am I just being an old fart? Or do the HN community feel the same way?

View on HN

Fashion hunting and window shopping are things script kiddies look for. People actually building products and solving read world problems dont stress over that stuff because their attention is consumed elsewhere.

My suggestion is to just build what you want to build. If the thing you build is slow refactor it to be faster. If that thing misses some new cool kid feature then write the new feature. Never does tool fashion come up.

Thank you. And yes, I agree. My theory is that when node became all that and all the young people went all-in, they learned how to solve everything with that mindset. And now, when they all grew up and went corporate, they took with them this way of solving problems and now, we are kind of stuck with it.

I love Node. It does a good job of exposing an OS level API of just about everything at kernel level, except file system which has an OS API for kernel level file management operations. It’s nice because of that API and it’s fast, but has its limitations.

If you need to do large recursive operations Node will likely fail. If you need memory conservation for device specific operations Node is not the tool. If you want to go faster than a garbage collected language allows Node is not the tool.

I think the bigger problem with Node id that most people writing JavaScript struggle to write JavaScript.

Yeah, I think I'm in that category - I do struggle with JavaScript. The reason why though, is not just about how to do stuff in it, but the fact that I think it's an awful language for so many reasons.

I kind of figured that some people have to love it for it to be so popular, but that makes me curious about what other languages you have used and how you think they compare?

You describe FOMO -- fear of missing out.

A lot of what gets announced and contributes to the illusion of constant change and "so much happening these days" amounts to fad and fashion, mostly short-lived and niche. You don't have to jump on every new shiny thing. Ask yourself, would you want to work for a company or client who constantly chased fads?

If some new thing gets traction, last for a few years, grows a developer base, and has successful products that use it, take a look and see if it fits your work. If it just "sounds real neat" maybe play with it but don't change course or waste a lot of time -- wait to see if it goes anywhere.

No one can learn all of the actually useful tools, languages, frameworks, much less the niche and ephemeral, so don't stress over it. Truly useful and innovative things prove themselves over time.

I focus my time and attention on tools that seem to have staying power, make me more effective delivering value, and that I can get paid for.

Thank you for answering. It's not just FOMO, I guess it's some of that, but what saddens me really, is the fact that so much of the new stuff is node-based.

Specially with all this new AI stuff. I do want to try out things, but as soon as I see that npm command, it's kind of a dealbreaker for me. I just don't want to be bothered with that :)

I know it's kind of biased, I don't really have this issue with other stacks. I have preferences of course, but not the kind of dislike I have for JavaScript on the server-side.

I have the same reaction to node and npm. I just don’t use it. Plenty of other tools I can make a living with. I ignore so-called AI too. I tried Copilot and ChatGPT, not a big time savings for me. If I have to carefully audit and debug code I’d rather mentor a junior human programmer than a corporate parasite LLM.

Maybe I will miss out, who can tell. I have survived and stayed employable for over four decades. I get the most work from Unix/Linux and SQL expertise.

Thank you. Good to know I'm not alone. On the other hand, we may both be old farts :D

There's a lot. But you don't need it all. Just choose well and keep it simple.

These days I find it very easy to recommend Astro for instance. It is batteries included enough you really don't need anything else.

Bun, deno and Hono are other projects that simplify a lot of the tooling by including most of what you need out of the box.

I'd argue that if you choose any of the options above web dev is easier than ever.

Seriously? Bun has over 500 open issues with the label "crash". https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

The socket implementation is broken too https://github.com/oven-sh/bun/issues/5627

In earlier days, it may have been more commercially viable to create polished developer tooling -- Turbo Pascal was a great example. Unfortunately, the world has become more complex, as everything is now interconnected, and processing power has increased. Open source, while great, probably diminished competition.

We now live in a world where complex sociological patterns dictate which tools get the most traction. It is easier for a tool to gain more popularity if it has company backing, if you are good at presenting, or if you make only small incremental changes. Technical merit is often less relevant. There is also "first-mover advantage" and countless other processes at play.

All this to say that, indeed, from a technological perspective, the world is totally crazy. But from a sociological perspective it is fascinating, and it is a great time to be alive.

If you don't like the Node ecosystem, then perhaps you may consider doing Java back-end development, as many people in that space adhere to the Lindy effect [1].

[1] https://en.wikipedia.org/wiki/Lindy_effect

Thank you! Interesting take, I feel a little bit smarter after reading that :) When it comes to Java though, I must respectfully decline :D

You shouldn't worry too much about the FOMO (fear of missing out).

I was contributing to node.js and v8's JIT back in 2010-2012 and I loved the NPM ecosystem at that time. To me, node.js was at its peak when express.js and koa.js were the fast way to write a backend. It took minutes to do the things that took hours or days in other programming languages.

But eversince the babel transpilation epidemic infected pretty much every package and bundler that doesn't want to deprecate legacy node.js versions, I kind of switched ecosystems.

I still think that typescript was a mistake, as it embraces language paradigms that come from C# and aren't fitting the ES language as well as e.g. the AS3/AS4 approaches back then. From a compiler perspective, it doesn't generate code that validates types, so it's useless for providing a typesafe API/SDK to third parties without the type definitions (in typescript).

I then kinda switched to Rust, as I liked the neon-bindings a lot for building better integrations with node.js at the time. But during the last years I feel that Rust gradually falls for the same feature fatigue, and I think that the upstream language maintainers should be more stubborn and take more time to think more thoroughly about feature/syntax implementations. A huge part of the Rust community is just for the sake of hype, though - and a lot of packages and bindings are just incomplete weekend-hacks.

Thank you for answering. I do appreciate it coming for someone actually involved, and it's an interesting perspective you give.

And in some ways, I do have the same perspective. I also wish for more long term thinking, and it's not really the FOMO that bothers me, but more the, as you so eloquently put it, the "incomplete weekend-hacks" :)

You haven't lived until you had to upgrade the CoffeeScript compiler to fix bugs revealed when you were upgrading to JQuery 1.9 in a panic to fix a Safari-only carousel glitch.

There was a time when Hacker News linked to blog posts where people bragged about being first to solve just these sorts of problems. "Get Lucky" by Daft Punk on headphones, and hitting refresh a lot, and watching the new guy slowly figure out why ActiveRecord was hitting the backend 1,285 times to generate a ten item to-do list.

I can imagine :) It kind of reminds me of #css on Freenode, in another life a long long time ago. When you got kudos for making one stylesheet work both in IE6 as well as all the other browsers :D

I absolutely feel the same way. For me Node/NPM is the stuff of nightmares. It is freaking impossible to maintain any decent sized project (even side project) in this eco system within a reasonable time investment.

Then there is Go + SQLite + HTMX + AlpineJS + <enter your current flavor of CSS library> and you are done. No complex build / transpile / whatever steps, just go build and done. Deploying consists of copying one binary and one database file to your server and you're done. Building and running stuff is easy and fun again. The JS community can go kick rocks...

Yeah, I have dabbled a little bit with Go and I like it, it seems promising. I have also looked into Elixir and the Phoenix framework, and both of those do concurrent programming in a neat and understanding way in my opinion. Go has a little bit more weight behind it though.

Pick your tools and use them. If your company or team requires a tool not in your toolbelt, learn it and use it when required, but always have your preferred stack in your pocket.

When the opportunity arises to sway your team towards new tooling, demo your choices.

There are new tools all the time, and it's worth it to not get too attached to any one stack. Letting yourself get too attached to one tool is a surefire way to box yourself in. Most of them do similar things, but in different ways. My thoughts on this are that the code is what matters, not the tooling.

Thanks. Good advice!

I don't know if there's a term for this, but never updating your tooling also keeps a potential door closed.

During my first internship, we never changed the stack. When I ran in a problem, it was because either - we needed to bump major vers - it's too new of a feature and the library isn't actively maintained

In my current job, worst case it's just not a stable feature yet and we need to wait. Both situations need a workaround, but I get a lot more motivated if I get the feeling we're "on-edge" of a tool.

Yes, It's kind of the same with me. We are stuck in a lot of legacy code and trying to upgrade a package more often than not, results in us having to roll it back because it breaks so much other stuff.

We know we have to start from scratch at some time, but we want to make it as future proof as possible - seeing what a huge codebase looks like after a decade of fixes :)

You will one day realize that they are all the same with only minor variation. you will lern to pick and choose what is important to you. You will pick something and only look back once a decade - long enough to you what works and have intelligent conversations about pros and cons with others with a decade in something else. Sometimes you will switch but there will be no hurry

Thank you. I trust the guidance of someone who’s walked this path before :)

Remember it takes a decade to really know if something is good. Sometimes you can tell something is bad in a few hours, but sometimes what looks bad after few hours is actually a good thing. Sometimes things seem bad because they are different from what you are used to - few people have the guts to admit change is hard and so most (including you unless you are on guard!) will reject different as bad. Sometimes things really are bad, but they are the best of a bad set of compromises and so better cannot exist (though a different set of compromises can results in a different set of bad)

Remember, there are frameworks/languages/... that everyone complains about; and frameworks/languages/... that nobody uses.

Working with Node and Python made me want to pivot towards a batteries-included ecosystem like .NET, but I'm somewhat stuck with what I'm getting paid to do for now.

In my current employment, I work primarily with .NET and it's not all fun and games either - but for different reasons. It's a different kind of complexity, a more corporate kind. Specially with legacy code - but still, I prefer it to node by a long shot.

Reply on news.ycombinator.com