Hacker News Reader

Comment by dnomad | Hacker News Reader

Watching the Javascript poorly reinvent the wheel has been very disappointing. Very simple mistakes like immutable, never changing build releases that Java developers understood 15 years ago are become recent front page news in this community. Ironically, even though all the code is open-source pre-existing knowledge does not get leveraged in the open source world. There's a kind of market failure at work here it seems; the lack of commercial selective pressure results in the flourishing of lots of poorly researched OS solutions.

View on HN

This issue is not just a lack of learning from past failures, it's an active issue that is systemic to web development, especially node. Everyone wants reinvent the wheel rather than supporting a similar, already existing project. I don't know if it's that everyone wants to be the lead on something or if they all lack group skills, but there is no reason we need dozens of similar, partially functional libraries. I can barely, and I mean sooo very barely get behind the fact that all of these SaaS companies need to create their own versions of frameworks, but it amazes me just how many square wheels there are in the web community. It was one of the major reasons it took me so long to start doing full stack development, just way too many cooks all wanting to make almost the exact same meal, only theirs is more superior.

It’s because the average dev has less than 5 years of experience according to the StackOverlow survey, and web is the fastest growing field inside software engineering.

A large majority of people you’re chiding for not learning from others, don’t even realize those other things exist.

But it's not even independent green developers, it's everyone. Chai, mocha, jasmine, jest, should, expect, lab...omg do we really need another unit testing library? Sure they are all slightly different but there is no reason they all couldn't be condensed down to one or two libraries. Shall we list all the reactive UI frameworks? Or routing frameworks? Everyone is at fault here.

Chai is not a testing framework, it's an assertion library compatible with all the other main testing frameworks you mentioned. Yes, we do need experimentation and innovation in testing frameworks. Jest was a real innovation to the space and is particularly awesome for React testing with it's snapshots feature. This kind of argument never gets made with anything else. "Why can't we all just stick to the Model T. It's perfect."

The Model T is a product, but we are talking about tooling, in that context the same spanner that can fix the Model T can fix the latest Tesla.

The car industry probably wouldn't be as big, if you had to learn a new tool for every new car.

I am all for experimentation and creating something new. But so many of these projects out there are not forks of current projects, they are complete rewrites. Is this because the new project is vastly different? Nope! That is the issue, they aren't extremely different.

The reason this is a problem is because web tech is constantly changing, to the point that so many of these projects end up in the scrap heap far faster than other tech. It causes problems with long term service due to compatibility issues with ever changing dependencies.

I have a feeling that JavaScript, and some other areas of open source, have a popularity contest problem - people building projects not because they're needed or useful, but for that brief moment of Internet fame.

I have the same feeling about this. Github "collect the most stars" effect?

It gets worse when instead of your CV, you get hired by startups based on your Internet fame, or wasting your private life building Github (sorry Gitlab) portfolio.

Half of those are assertions libraries, not unit testing libraries. What are you comparing this list to? What is the appropriate number of unit testing libraries a language should have? Do you scale that number for community size?

Ignorance is curable, but requires the cooperation and desire of those who lack to achieve the cure. From my vantage the world of software development seems filled with mediocre individuals who all think of themselves as the Jon Galt of software.

On average most people are average, yes. Most above average people are average in most situations, even.

And sometimes it’s just resume building or intellectual curiosity itching.

Or people just enjoy building something that scratches an itch for them?

I like the energy around the javascript everywhere movement. So what if they reinvent the wheel, sometimes you find a better wheel and break the rules along the way.

There is something exciting about developers using a language in ways it was never designed. Then having the language change to support the changing ecosystem...

So true, at the end of the day people are working like this because it's the way they feel the most passionate about. You can't really blame them considering how disinterested people can get working on that last 10% of even their own projects.

haha, why do we do this? Should we judge programmers by how finished their thing is? I think it is the most impressive quality when I see it (which is non of my own stuff haha)

It's when you build a business on a technology and then have to re-invest to rebuild the product, that's when it becomes an issue. Think of all the start ups that built running businesses on Angular 1.

as far as i know, angular 1 still works just fine... :)

(as it happens 1.7 was released recently.)

It does but try finding a developer looking to work on Angular 1

> Very simple mistakes like immutable, never changing build releases

Can you expand a bit more? Not sure what this means.

[1] https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakag..., [2] https://www.csoonline.com/article/3214624/security/malicious..., [3] https://news.ycombinator.com/item?id=16087024

And the list goes on and on IMO. What's disappointing is that these were lessons learned a long time ago and now they're being re-learned.

This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc.

But anyways, [2] is at least a problem in many other package repositories. [1] would probably be a problem for many - given legal pressure (vendor your shit, that's the solution). [3] was a bug, not a design issue - no package management system is immune to bugs.

The one thing Java has is that it uses namespaces, which may help with [2] (but barely). [2] certainly has been a problem in PyPI.

Certainly all of this could happen to PyPI. We see it happen with js more, I think, because js happens to be extremely popular so there's a ton of packages for it and it's also much younger (especially node) than others.

> This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc.

He does have it in his slides.

Slide titled: "Regret: package.json", last 2 points:

> Ultimately I included NPM in the Node distribution, which much made it the defacto standard.

> It's unfortunate that there is a centralized (privately controlled even) repository for modules.

Yeah, I remembered the package.json bit, but that part still had nothing related to the issues/ mistakes mentioned.

Understood, sorry I wasn't trying to dispute any of your points about said issues/mistakes.

Just trying to clarify that he does actually talk about NPM and his regret about it.

Yeah, I actually only remembered the bit about 'package.json' and not the other quotes as well lol

More frustratingly, at least for me, is that some of us have been warning about these things for absolutely years without many paying any mind, only for them to keep in happening again. Eg. https://news.ycombinator.com/item?id=16090120

The problem is, how do we know that those shouting warnings are not false prophets?

Presumably by reading and understanding their arguments.

But, how do we know which ones we should be reading and understanding their arguments?

I've found that some people tend to take a ton of pride in the assumption that they have to make mistakes to learn from them, but you almost always want to learn from other peoples' mistakes first. Probably overlaps quite heavily with those people who desperately want to tread on new paths.

Sounds to me like the list has one item: “the npm registry once allowed users to delete packages”. [2] and [3] have nothing to do with immutability. None of them have to do with reinventing the wheel, either, unless you wanted Node to use Maven for package management?

They don't mean immutable as in language form, but immutable packaging system is the general form where you can add but not remove packages to it so as to not break things, which is the common form among most maven/cargo/hunter/etc.../etc... dependency packaging systems. It's generally considered that npm supporting deleting packages was a major mis-design, which became very public when a popular tiny package got deleted, which then broke so many things, so they learned that the hard way instead of learning from the systems that came before (obviously not cargo, but you get the drift ^.^).

> They don't mean immutable as in language form, but immutable packaging system

I know. [2] and [3] have nothing to do with a package repository you can’t delete things from.

Anyone who's acting like this wouldn't happen in Maven is lying. Just look at what happened when CodeHaus went out of business.

"The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again." - R.Jordan

I'm afraid the current frantic pace of reinvention in JS/web might cause the Breaking of the World and throw us into a Third Age where no one quite remembers the true lessons of the Ages before.

Reply on news.ycombinator.com