Hacker News Reader

Comment by weego | Hacker News Reader

Ironically I feel like the entire process node/npm is labouring through is anything but modern. None of these problems are new or unique, unless you ignore the last few decades of lessons from engineering concerns in other ecosystems, which unfortunately people seem determined to do.

View on HN

Problems that Node/npm deals with that are relatively new/unique:

- Distributing modules that work in both the browser as well as on the back-end

- Working with and developing an ecosystem for a language that wasn't really developed for years and years, was still missing quite a bit of functionality, and then suddenly gained a lot of traction

- That language having to catch up on years and years of developments in computer science, and having to do so in a backwards compatible way

These are real problems that have influenced and caused a lot of the perceived idiosyncrasies in the Node/npm module ecosystem, and that do not have simple solutions that can be simply copy-pasted from other languages or ecosystems.

> Distributing modules that work in both the browser as well as on the back-end

You could say that they are two different runtimes, think CPython / pypy

Sure, but though I'm not that familiar with CPython and pypy, I don't think there are many situations where those runtimes have as varying and sometimes conflicting requirements as Node and the browser. I'd guess the differences are more similar to the differences among the different browsers alone, which already are different runtimes by themselves.

That said, even if those runtimes are as different as Node and the browser are, it's the interplay of that restriction in combination with the other characteristics I mentioned that make this a new challenge in its own right.

The python distribution infrastructure lags far behind that of javascript.

> None of these problems are new or unique, unless you ignore the last few decades of lessons from engineering concerns in other ecosystems, which unfortunately people seem determined to do.

Not intentionally you see. This is completely anecdotal, so take it with appropriate grains of salt, but I have observed that the majority of people is the JS ecosystem are not proper students of computer science/development. Most are either self-taught or come from fast paced bootcamps. So they lack the historical knowledge of software engineering and basic passing knowledge of other ecosystems.

Now for the most of us that have spent time studying the field, it is easy to identify the problems and at least remember that some solutions exist. Most of the people in JS community do not. So they go through the same process others have gone through before and land in the same mess.

There is nothing anyone can do about it.

This is a great insight. This kind of explains my constant surprise when I hear concepts I was taught in university reappear in the JS ecosystem with different names, and with great fanfare. In a way it's great that these developers have the ingenuity to rediscover these things on their own, but I can't help but wonder whether this is a case of those not knowing history being condemned to repeat it.

JS developers sometimes have the opposite impression, that computer scientists have conspired to repeat history in order to make the ecosystem look like something they know.

CS move forward one generation at a time. The less CS you know the more likely you are to spot bad practices. And the more naive you are the more likely you are to make a solution. Sure it might already been solved 30 years ago - but it might not have been the right time.

Oh please... this is not nearly the case anytime recent. If anything, new CS grads are more prone to reinvent some solution from scratch than to reuse existing solutions.

The main issues are that browser tech has advanced rapidly and is/was a non-homogeneous runtime environment. Also JS eco is built from OSS by an enormous pool of developers.

There is a difference between implementing a reinventing a new solution with knowledge of the past mistakes that prevents those mistakes from occurring again and a new solution without knowledge of the past mistakes, which leads to those mistakes being repeated again. In my observation, the JS community tends to go towards the latter.

Could you share some examples of these failures please?

The community as a whole has the kind of immaturity that leads to repeated and terrifying security incidents, for one.

Reply on news.ycombinator.com