The small dependency thing is a sad artifact of the days when most JavaScript libraries were built to run on the browser. In that context, prior to the days of mature tools to do things like tree-shaking to remove unused code, the easiest way to make things smaller was to make JS modules as small as possible so code could opt-in to subsets of a library it wanted to use.

Fast forward 5 or 8 years and we have a very fragmented ecosystem of NPM modules—some built to be used on the web, some not—built on a legacy of tiny modules and deep dependency trees.

Add on to all that the pace at which the JS and browser ecosystem moves and it’s not too surprising that things have ended up the way they are.

Teams don’t need to build projects with deep dependency trees, but it’s pretty hard to avoid them with the NPM registry in the shape it’s in.

> the easiest way to make things smaller was to make JS modules as small as possible so code could opt-in to subsets of a library it wanted to use

Also due to JS having a very small stdlib. Compare built-in functions to eg Kotlin, its a different world.

If you can have a Java backend that's more or less totally decoupled from the frontend, great. Java and it's tooling are fine, and it's easy to be productive writing in Java. However, my only experience as a frontend dev with Java backend system has been truly nightmarish, because the backend processed all the frontend assets and rendered them. If anything, this is what helped me burnout, because everyone on my team writing Java was super productive and delivered on time, while I couldn't test my JS, CSS, or HTML changes without restarting Tomcat on my fucking useless 10lb HP laptop that the corp required me to use most of the time, because that's what all the Java developers used to get their Java working.

Yeah so the dev machine shit specs is something we fight SO HARD against in my bank. There s not many thing we can fight, but our 10 core SMT xeon with 128G of RAM for everyone in the team was a fight worth fighting. Yes, it took 2 years of them putting us on a new VM cloud systems after another before they gave up, us spamming them every say "intellij freezes", "I cant build in less than 10 minutes and the traders are getting nervous we spend our time daydreaming while it compiles" and other such trolls making the budget monkeys sweat.

Other than that, there s probably a way for you to propose a change, ive worked on the same nightmare you describe and, well, I was lucky enough I guess I could make enough changes to both stack it was possible to get either a light java subset running just the frontend to test, or make the js independent for testing, yes with a yarn soup lol, which is how I learned it in the first place I guess.

I remember 6 years ago working on financial company. We have to deploy our app into weblogic and everytime we have to change something, we have to recompile it again and restart the app server. It took almost 5 - 10 minutes from start to ready to test. I thought that's because of the code but turns out all of our notebooks are using shit HDD. When I use my own PC with SSD, it flies with less than 3 minutes and after that I proposed something like hot reload which make the dev experience a lot nicer (in some cases, you do need to restart)

I don't know about them right now but before I resign, I told them "have you ever calculate how much time and money wasted by just restarting our app server for local dev? you probably should be worry about that because I believe you pay us to wait for app server comes online more than we develop a feature"

In retrospect, I hadn't thought of that but it makes perfect sense. I believe I ended up accessing my laptop's local server from my personal mac, so it would have still been the bottleneck. I may have asked a similar question on my way out lol

If you are using IntelliJ, do not use the JBR JDK 11 as the boot JDK for the IDE. Since I switched to Azul Zulu 15, IntelliJ flies.

I'm glad you won the fight you were fighting. I lost most of mine, and this was 5 years ago.

A few things worth elaborating on.

> 10 core SMT xeon with 128G of RAM for everyone in the team In our case, most frontend web devs realistically use macOS or some other unix env. Not only did our bunk-ass windows machines suck spec-wise, and in terms of physical dimensions, they also sucked because they were windows based. This was shortly before WSL, so it was a pain. The DevOps guy did have a crazy machine with tons of ram and so on.

> I cant build in less than 10 minutes This was literally the case for me every time I made a change. Sometimes the previous result would be cached and I'd need to do it again. I was constantly fighting a stupid battle, and nobody really understood why things were the way they were or how to change them, including the java devs that had been working on it for years.

I kind of won the dev machine battle, because the VPN wasn't really sophisticated and I just set up some system on my personal mac, against the wishes of management. When a designer came in, they got a mac, and had to ask me how to connect it to the VPN.

> it was possible to get either a light java subset running just the frontend to test, or make the js independent for testing, yes with a yarn soup lol

Someone had set up a node instance that attempted to replicate the output of the java system, but without some bits that I can't recall atm. The inconsistencies and trying to maintain a one-for-one replica was just as much of pain. If I remember correctly, that was in part because there would really have had to have been a deliberate time investment in creating a sustainable replica that involved communication when any data changed server side. It was a crap-shoot, and I should give myself more credit for lasting as long as I did, but less credit for not jumping ship way earlier.

I ended up literally burning out, getting fired, and didn't find employment again for years. I have it on my resume that I did a few things successfully while I was there, but quite honestly I don't completely remember what those were, and am just guessing at this point.

> I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need)

Using Java 6 is major red flag. Even Java 8 should be red flag nowadays, if it weren't so extremely common. Both versions no longer receive any security updates or bug fixes. If an organisation doesn't care to put a system on a platform with active security updates that tells me one of three things:

1. The system is unimportant and is basically value-less. I don't want to work on systems like that. 2. The engineers are incompetent and lack even the most rudimentary learning skills (or will) to follow even the most basic updates on the tech they use every day. I don't want to work with people like that. 3. Engineering management is too incompetent to listen to very important messages from their team. The system likely has major issues and a fear of fixing even minor technical debt. I don't want to work in an environment like that.

It's not seldomly more than one of these.

Java 8, if you use corretto, is supported until 2026. It's totally fine to use and support. And java being java and jumping to 11 won't be that bumpy either.

> Java 8, if you use corretto, is supported until 2026.

Interesting, I was not aware of this. I've not seen people use Corretto either, but it seems OpenJDK has a separate project just to maintain Java 8. So that's indeed still fine to use.

> And java being java and jumping to 11 won't be that bumpy either.

The update from 8 to 9 was rather painful in the beginning, mostly due to libraries not working well with the module system. I'm not sure how it is nowadays, it could have gotten better.

9→10→11→12→13→14→15→16→17 were very painless. I don't foresee a lot of companies getting stuck on those, though it's too early to tell.

Yes, we held off on upgrading from 8 to 9 originally because a lot of our dependencies didn't work with 9's module system. A few months ago we jumped straight from 8 to 11, and it was easy, because all of those dependencies have since fixed their module system problems. (What finally pushed us to move to 11 was that some of our dependencies stopped supporting 8!)

If you can't get reproducible builds the team doesn't know how to use lock files properly. Don't go blaming it on the stack.

What's your workflow with lock files? Do you force them in CI/prod only or also in dev?

I'm tempted to enforce lockfiles at every stage of the product cycle, making upgrades an explicit action, rather than the side-effect/byproduct of another action. Does it make sense? What do you think?

Lockfiles get commited to the repo and used everywhere to avoid version differences. Upgrade dependencies as needed and have everyone reinstall when they change.

I'm amazed anyone wouldn't do this, it's the only sensible course of action.

Some things go without saying, yet go better with saying.

Basically what TheAceOfHearts said. Always use them everywhere, except when explicitly upgrading dependencies. It's also much faster to do a 'npm ci' than an 'npm i'

> I cannot understand what idiot thought it d be fancy cutting everything into mini dependencies that update every day without you knowing made by amateurish hipsters who transitive depend on each other like their life depended on it.

I'm not sure you're thought things through in your comment, and that you are being fair or reasonable.

No one cuts "everything into mini dependendencies". You have dependencies you reuse. That's it. When one of those dependencies gets updated, say to fix a bug or a security issue, your package manager of choice handles it for you without any issue. Still, if you do not want to fix bugs or vulnerabilities in your code then you are free to pin them all and move on with your life.

At most, the JavaScript or NodeJS crowd needs to have a serious talk about standard libraries and third party lackages, such as whether using packages such as rimraf is desirable.

> and yarn/npm frontend projects that cant be even rebuilt two weeks later

You only experience that sort of problem if you're incompetent in how you manage your dependencies.

With npm you can a) pin major/minor/patch versions of specific packages, b) save your package-lock.json file which specifies exactly which dependencies you use. If you free-float any dependency then that's something you chose to do.

With JavaScript/NodeJS + npm you only shoot yourself in the foot that way if you purposely aim at your foot, remove the safety, and press the trigger really hard.

> And I m very against transpilers and linters which I try to avoid for sanity (...)

Complaining about linters because they test your sanity is a major red flag on your approach to mundane coding tasks. This, and your casual criticism on everyone else's code, leads me to suspect that you really need to do some introspection.

> I kid you not we have an entire team in charge of one small frontent management tool for a pretrade backend, they literally spend 99% of their time justifying why they wont change it, and 1% begging me to join for a week to reorder their column or put a new button...

Based on your comment and on my experience with similar projects, I suspect you're either oblivious and/or leaving out important bits of the story just to continue plowing with your humblebrag, or you're succumbing the need to be hyperbolic.

Frontend development has to deal with far more details and constraints and requirements than any backend task. Frontend is what both clients and PMs and executives look at, and the tiniest changes like resizing a button has deep implications on the business side of things. Furthermore, it's both harder to automate tests and their tests need to be more extensive.

Thus any change, no matter how small, is a uphill battle.

It's beyond me how someone who is so hard on their entire team ends up showing such weak understanding and insight of the problem domain. I know that on the internet no one knows you're a dog, but let's not get silly here.

> With JavaScript/NodeJS + npm you only shoot yourself in the foot that way if you purposely aim at your foot, remove the safety, and press the trigger really hard.

Eh, no. You'll get shot no matter what, even if you have no gun.

For example, let's imagine you now have your version locked down codebase and after a month you want to install a new package. This one is only compatible with XYZ V1 while what you have is V2. No worries, npm will just handle that right? Well, you'll have both versions, but the prototype constructor name changed from V1 to V2, so the versions won't work together, so now you need to upgrade XYZ V1 everywhere anyways. And when XYZ did the V1->V2 upgrade, they also upgraded to GKS V53, so now you need to also do that upgrade.

Continue ad-infinitum or simply stay away from a broken ecosystem.

This is a far bigger problem in the Java world. Maven will just pick at sort of random (it's deterministic but hard to predict and mostly invisible).

On the JS side there's a way deal with that if people use modules. Good dependencies don't clobber the global namespace. Multiple versions can exist side by side. It'll just make your build bigger.

Since the number of dependencies is way less then in the JS world, its possible to pin them down manually.

If you absolutely need to have multiple versions of the same dependency, you probably need to use OSGi.

> (...) after a month you want to install a new package.

What's your point? If you want to update a dependency then you also need to go through all their dependencies. This is not a javascript/npm problem; it's a software development problem. Dependencies don't get magically updated, even with semver. You experience the exact same problem with other tech stacks. I'm fact, I've experienced this problem far more with C++ projects than with JavaScript/typescript ones.

Why are we expecting and demanding random updates to work with JavaScript/npm when that belief and expectation was always totally unrealistic with any other stack?

The point is, that in a moderately complex Java project that might be something on the order of 150-200 dependencies, and updating just one of those usually doesn't lead to a big change in the transitive dependencies (it is a different thing for a major update, Java 8 -> 11, or from the pre jakarta JEE to jakarta), but its possible for a single person to track whats happened. But with 1500+ dependencies, so an order of magnitude bigger, its just not possible.