Anecdata from a JS developer who has been in this ecosystem for 14 years.

I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks.

Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration.

Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts.

Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.

Make sure you have a run of govulncheck [1] somewhere in your stack. It works OK as a commit hook, it runs quickly enough, but it can be put anywhere else as well, of course.

Go isn't immune to supply chain attacks, but it has built in a variety of ways of resisting them, including just generally shorter dependency chains that incorporate fewer whacky packages unless you go searching for them. I still recommend a periodic skim over go.mod files just to make sure nothing snuck in that you don't know what it is. If you go up to "Kubernetes" size projects it might be hard to know what every dependency is but for many Go projects it's quite practical to know what most of them are and get a sense they're probably dependable.

[1]: https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck - note this is official from the Go project, not just a 3rd party dependency.

I'm going almost the same direction, for the same reasons. Golang seems very interesting. Rewriting some hobby projects to get an understanding of the language and ecosystem. I'm on Node/webpack now and don't love where things are going.

Frontend: eh - you could pick something that targets wasm. Definitely a tradeoff with its own headaches.

Rust wasm ecosystem also needs a lot of crates to do anything useful, a lot of them unmaintained.

Now I imagining it like being outside a concert or other ticketed event: "Crates, who's selling? Who's buying?"

Try Scala? You only need one 0-dependency library for UI (Laminar), and you're good to go.

> React happily also has 0 dependencies,

Ok, but it has 112 devDependencies, I'm not really sure "0 dependencies" best describes React.

Dev dependencies are not installed when you install the package into your project.

Also I checked how many deps vuejs has, also 0.

Those are not installed.

I think we've pulled way too much towards "software must be a constantly maintained, living item, and users should update often", thus the recklessness with dependencies. This has also exacerbated the other aspects of dependency hell. But not only does this not match reality, it makes projects very vulnerable to this supply chain hijacking stuff.

I think maybe the pendulum needs to swing back a little to being very selective about adding dependencies and expecting releases to be stable for the long term. Users shouldn't have to worry about needing to hack around code that was written just 3-4 years ago.

From a purely aesthetic point of view, this is what I enjoy so much about C and Fortran. You look up a Rust crate and it hasn't been touched in 5 years. That means it's unmaintained and unusable, don't add it to your project or you will have a bad time.

You find a C or fortran library that hasn't been touched in 20 years and (sometimes) it's just because it's complete and there hasn't been any reason to update any parts of it. You can just add it to your project and it will build and be usable immediately. I wish we had more of those.

Clojure and Go are similar to this from my experience.

That won't happen, because time to market is the biggest obstacle between the developers and the monies.

If leftpad, electron, Anthropic, Zed, $shady_library$ gonna help developers beat that obstacle, they'll do it instantly, without thinking, without regret.

Because an app is not built to help you. It's built to make them monies. It's not about the user, never.

Note: I'm completely on the same page with you, with a strict personal policy of "don't import anything unless it's absolutely necessary and check the footprint first".

It’s not always about money. It’s also about the time of the developer. Even for a hobby project you may burn out before to actually deliver it.

I'll say depends. Personally, my hobby projects are about me, just shared with the world because I believe in Free Software.

Yet, I'm not obliged to deliver anything to anyone. I'll develop the tool up to the point of my own needs and standards. I'm not on a time budget, I don't care.

Yes, I personally try to reach to the level of best ones out there, but I don't have a time budget. It's a best effort thing.

In reality I think you are always on a time budget. If you don’t deliver in a timely manner you burn out(worst case scenario) or just loose interest. The time it takes to get at these points depends by the project and your time/expectations. I’ve found out that the most important thing is to get feedback early even from yourself using whatever software you develop. If you just develop a small library/ utility you can ship it before other stuff is starting to compete for your time. But if it takes a year or more before even you can make any use of it I guarantee you that the chances of shipping it diminishes significantly. Because you are on a time budget. Other stuff competes for your time(I.e family, other hobbies etc).

I think we tackle the same problem in different ways. For me, if something is not urgent, I do it in a best effort way, and the shipping time doesn't matter.

I generally judge whether I allocate time for something or not depending on the utility and general longevity of the tool. I hack high utility / short life tools, but give proper effort to long life tools I need. As a side-effect, a long life tool can start very crude and can develop over time to something more polished, making its development time pretty elastic and effort almost negligible on the long run.

For me shipping time is both very long (I tend to take notes and design a tool before writing it), yet almost instant: when I decide that the design is enough for V1, I just pull my template and fill in the blanks, getting a MVP for myself. Then I can add missing features one at a time, and polish the code step by step.

Currently I'm contemplating another tool which is simple in idea, but a bit messy in execution (low level / system programming is always like that), but when it's design is over, the only thing I'll do it is to implement it piece by piece, without no time crunch, because I know it'll be long-living tool.

I can time-share my other hobbies, but I have a few of them. I do this for fun. No need to torture myself. And, I can't realize my all ideas. Some doesn't make sense, some doesn't worth it, some will be eclipsed by other things.

That's life, that's fine.

Times are monies though

This is wild shift that AI allows now. I am building stuff, but not all of it is for public consumption. Monies matter, but, so does my peace of mind. Maybe even more so these days.

i guess it's a market thing? because when i build stuff in a B2B scenario for customers, it is about the customer's users. Because the customer's users are the money.

at least, that's my attitude on it :shrugs:

> Because the customer's users are the money.

That's exactly what I'm talking about. The end desire is money, not something else. Not users' comfort, for example. That B2B platform is present because everyone wants money.

Most tools (if not all) charge for services not merely for costs and R&D, but also for profit. Profit rules everything. Users' gained utility (or with the hip term "value") is provided just for money.

Yes, we need money to survive, but the aim is not to survive or earn a "living wage". The target is to earn money to be able to earn more monies. Trying to own all.

This is why enshittification is a thing.

The customer is the money. If the customer cares about its users then they are the money.

Then you have the user is the product the customer is the advertiser situation. You please the customer enough to have a product to sell to advertiser.

And this before we even touch deceipt. E.g. lying to the customer to make more money.

companies work for their shareholders

kinda

they work for where the power lies. even shareholders get fucked too.

> but there must be a healthy middle ground between that and a library that lets you pick font color.

When I was doing Perl more I actually highly liked the Mojolicious module for precisely this reason. It had very few external dependencies beyond Perl standard libs and because of this it was possible to use it without needing to be plugged into all of CPAN.

But with the libraries it provided on its own, it was extremely full featured, and it was otherwise very consistent with how you'd build a standard Web app in basically any modern language, so there was less of an issue with lockin if you did end up deciding you needed to migrate away.

My opinion on "don't re-invent the wheel" has really shifted with these supply chain attacks and the ease of rolling your own with AI.

I agree that I wouldn't roll my own crypto, but virtually anything else? I'm pretty open.

I would say the solution is to make it small and ugly, back to the way it was in the pre-Web-2.0 era, but SQL injections were a thing back then, and they're still a thing today, it's just now there are frameworks of frameworks built on top of frameworks that make fully understanding a seemingly-simple one liner impossible.

I agree.

I don't know many people who have shit on Java more than I have, but I have been using it for a lot of stuff in the last year primarily because it has a gigantic standard library, to a point where I often don't even need to pull in any external dependencies. I don't love Oracle, but I suspect that at least if there's a security vulnerability in the JVM or GraalVM, they will likely want to fix it else they risk losing those cushy support contracts that no one actually uses.

I've even gotten to a point where I will write my own HTTP server with NIO (likely to be open sourced once I properly "genericize" it). Admittedly, this is more for pissy "I prefer my own shit" reasons, but there is an advantage of not pulling in a billion dependencies that I am not realistically going to actually audit. I know this is a hot take, but I genuinely really like NIO. For reasons unclear to me, I picked it up and understood it and was able to be pretty productive with it almost immediately.

I think a large standard library is a good middle ground. There's built in crypto stuff for the JVM, for example.

Obviously, a lot of projects do eventually require pulling in dependencies because I only have a finite amount of time, but I do try and minimize this now.

Do you really need to roll your own NIO HTTP server? You could just use Jetty with virtual threads (still uses NIO under the hood though) and enjoy the synchronous code style (same as Go)

I mean, define "need" :)

The answer is no, obviously I could use Jetty or Netty or Vert.x and have done all of those plenty of times; of course any of those would require pulling in a third party dependency.

And it's not like the stuff I write performs significantly better; usually I get roughly the same speed as Vert.x when I write it.

I just like having and building my own framework for this stuff. I have opinions on how things should be done, and I am decidedly not a luddite with this stuff. I abuse pretty much every Java 21 feature, and if I control every single aspect of the HTTP server then I'm able to use every single new feature that I want.

The only time I would agree with that is crypto. Don't roll your own crypto. Otherwise there's minimal downside to rewriting basic things directly, and often its unnecessary if your language has a complete standard library. The only place I feel differently is with something like C, where the standard library is far from complete, in that case it makes perfect sense to rely on many third-party libraries, however you should assess them for robustness and security.