Live data from Hacker News

The JavaScript ecosystem is a hot mess and so is software development

nadh.in

71–80 of 94 posts

Re: The JavaScript ecosystem is a hot mess and so is software development

#71
I like how the giant monorepos (like Google's) serve as a forcing function against these problems.

When all of your dependencies are developed on the same repo and are part of the same CI they just won't break you (at least not your tests). And when you'll come back to the project 6 months later you'll find it building and passing tests against the latest versions of all dependencies.

This forces you to have a decent test coverage (otherwise they'll break you).

It makes library authors feel the pain of their downstream dependents and carefully consider breaking changes (otherwise they will need to spend time fixing downstream).

It makes people hesitant to bring in third party libraries that aren't very stable compatibility-wise (as the "internal owner" of the third party becomes responsible for updating it and unbreaking the world).

Re: The JavaScript ecosystem is a hot mess and so is software development

#72
post #16

So, `yarn upgrade` broke something, probably because some package down the road didn't respect SemVer. I guess failing to respect SemVer can happen in any ecosystem, now in other ecosystem you could have sealed dependencies that an upgrade can't break, but then it makes the whole upgrade action moot. In summary, you either, not upgrade, go deep in your lock-file and fix it manually, our you update your main depenency…

Upgrading dependencies is never a safe operation regardless of what semver tells you. The version number is a suggestion and not a promise. I have had minor patches break things because it turns out that my app is depending on a behaviour which is a bug. But it’s no big deal, upgrading is something you plan out and spend the time on. Upgrade them all at once and spend the time testing everything and reading change logs.

Re: The JavaScript ecosystem is a hot mess and so is software development

#73
post #11

Out of curiosity what is the best counter argument to the general thesis, eg either what positives come entangled in the hot mess or reasons it’s not a hot mess?

High tool churn creates an ecosystem where you get paid well for knowing the new hotness.

Currently getting paid in the 4th percentile in Australia as a ruby/js dev with no formal education. Who cares what the js ecosystem is like if companies are willing to shell out whatever it costs to get devs to work on their web app.

Having JavaScript app devs is basically a license for companies to print money right now.

Re: The JavaScript ecosystem is a hot mess and so is software development

#74
post #61
post #59

Earlier quoted context omitted.

That's a myth. I've been in a lot of tech interviews, no one gives a shit about what tools you use. Maybe things like terraform or docker, but not the libraries or tools inside the projects, no. You get a pat in the back maybe.

Getting to the interview often means your resume making it past a recruiter that doesn't know much other than keyword matching. And there's plenty of job listings with granular things like redux, eslint, webpack, and so on in them.

I'd put them on the CV and add a line saying many of these are for SEO. No need to actually try to master them. Find more interesting things to learn that can enrich your software engineer mind.

Re: The JavaScript ecosystem is a hot mess and so is software development

#75
post #22

Despite the bandwagoning here, I'm going to say it's the authors fault. They updated dependencies blindly upping the version of packages a leading digit. Of course things will break! That's what the leading digit is for! Yes, there are problems with too many dependencies, but upgrading packages just because you feel like it is a recipe for disaster even with very mature dependencies with good governance.

Exactly. The real "problem" is how easy it is to install and upgrade packages.

They took the painful part out of library management, and now they expect breaking changes should magically be resolved.

The funny part is that there is no comparison to other development ecosystems. "Oh yeah, in C++ we don't have this problem, since everything is even more painful"

Re: The JavaScript ecosystem is a hot mess and so is software development

#76

Out of curiosity what is the best counter argument to the general thesis, eg either what positives come entangled in the hot mess or reasons it’s not a hot mess?

Either you move slow and keep things stable, or you move fast and break things.

Pick one.

Re: The JavaScript ecosystem is a hot mess and so is software development

#77
post #11

Earlier quoted context omitted.

High tool churn creates an ecosystem where you get paid well for knowing the new hotness.

Currently getting paid in the 4th percentile in Australia as a ruby/js dev with no formal education. Who cares what the js ecosystem is like if companies are willing to shell out whatever it costs to get devs to work on their web app. Having JavaScript app devs is basically a license for companies to print money right now.

how do I find out what percentile I'm in?

Re: The JavaScript ecosystem is a hot mess and so is software development

#79
post #77

Earlier quoted context omitted.

Currently getting paid in the 4th percentile in Australia as a ruby/js dev with no formal education. Who cares what the js ecosystem is like if companies are willing to shell out whatever it costs to get devs to work on their web app. Having JavaScript app devs is basically a license for companies to print money right now.

how do I find out what percentile I'm in?

I used this Australia specific page https://mobile.abc.net.au/news/2019-05-21/income-calculator-...

Re: The JavaScript ecosystem is a hot mess and so is software development

#80
post #22

Despite the bandwagoning here, I'm going to say it's the authors fault. They updated dependencies blindly upping the version of packages a leading digit. Of course things will break! That's what the leading digit is for! Yes, there are problems with too many dependencies, but upgrading packages just because you feel like it is a recipe for disaster even with very mature dependencies with good governance.

I agree. I also think the author blindly followed up on some automatic GitHub bot suggestions only to find out you can't just upgrade everything.

My experience is actually the opposite: it's never been easier to develop at scale in frontend. People forget how hard frontend is. You need to ship everything and it needs to work everywhere. You have zero control over the code execution environment. The fact that build tools like Webpack and frameworks like Vue/React exist made it a breeze to quickly develop high-quality web applications, and that is actually a triumph of the JavaScript ecosystem.

Ofcourse it's difficult to understand the entire build chain, but often it's not necessary to understand every detail. If you use vue-cli/create-react-app you get a perfect bootstrapped environment that works out of the box. If you really need to upgrade, I would suggest creating a new empty project and migrate all the code to the new project, instead of changing dependency version numbers in package.json.

My personal experience is that I've run into quite some issues, but not necessarily more than when doing anything backend related. I've spent weeks trying to understand the Python module system. And worse, Python doesn't even have declarative dependency management built-in. Also it's very difficult to find high quality packages because there's hardly anything like npmjs.com for the Python ecosystem.

That being said, I love both JS and Python, but I don't think of the quirks of both languages and their ecosystems as a "mess", but rather an understandable reality we have to deal with it that is definitely worth the trade-off. Innovating and backwards compatibility are often orthogonal direction so it's definitely not easy facilitating both.

Post reply on HN