Hacker News Reader

Comment by hliyan | Hacker News Reader

While I'm a big fan of native modules, I find the constant use of the adjective "modern" in new JS project descriptions somewhat disturbing. Being modern in itself is not of any value. If it loads faster, or if it obviates the need for a bundler, or if it makes granular upgrades easier, or if it reduces the amount of configurations or tooling, we should put those benefits first.

View on HN

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.

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.

"Modern" is another meaningless software-project marketing adjective like "blazingly fast". I'm pretty sure we'll eventually be able to use these buzzwords to perform carbon-dating of old projects.

"Hmm, uses the term 'modern' but the README has limited image macro memes... seems like an early 2019 release."

Jest, FB's JS testing framework, is described as blazing fast but is actually twice as slow as Jasmine (or was at some point). If twice as slow is blazing fast, I don't know what twice as fast is. I do know 'blazing fast' is meaningless. It's just deceptive.

For reference: https://github.com/facebook/jest/issues/6694

OT, but I was using Jest and switched back to Mocha. Since my tests are nothing special and 100% browser env they load instant. Should have done sooner

I made liberal use of jest's expectation framework and module mocking. Migrating is 'doable' but at this stage in the project I can't justify the delay on the deadline.

I've got about 200 integration tests too with a package that builds itself into an OS dependent state so I'm stuck running things in a VM. Probably easier to mark up the tests so I can run unit tests most of the time. That should make things bearable.

In this case, I think "modern" means "uses ES modules", which have somewhat recently become standardised, but have not (yet) been adopted by all npm packages for various reasons: https://news.ycombinator.com/item?id=19294189

I think it's simply a way to distinguish between old style JS ecosystems and new. It encompasses a range of benefits and lessons learned in JS. Of course not everyone is going to agree that the "modern" way is the right reaction to the problems of the past but most active JS programmer will have a good idea what it means.

C++ has a similar issue. There's a very distinct difference between C++11 and what came before. And C++20 could be another big shift (especially with modules). Modern has a useful meaning, even if it's fuzzy and temporal.

Whenever I see that word, I am reminded of a book I have titled Modern Welding --- published in the late 60s, so I guess it has always been a pretty meaningless adjective; but it does seem the JS (and web development) community in general likes to use that word a lot.

In the sense they're using it here it's perfectly valid. ES Modules are the modern replacement for the old legacy JS module systems.

It's valid, but not interesting. The "old legacy" system was once modern, too. And before that it was <script>. Better to talk about the technical benefits of the solution instead of how new (i.e. modern) it is.

Reply on news.ycombinator.com