4 ms·

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 its

by hliyan 8y ago

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.

weego 8y ago
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.
- quantummkv 8y ago
  > 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.
  - hliyan 8y ago
    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.
    - wiredearp 8y ago
      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.
      - z3t4 8y ago
        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.
  - gedy 8y ago
    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.
    - quantummkv 8y ago
      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.
      - MarvelousWololo 8y ago
        Could you share some examples of these failures please?
        krageon 8y ago
        The community as a whole has the kind of immaturity that leads to repeated and terrifying security incidents, for one.
- Vinnl 8y ago
  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.
  - riquito 8y ago
    > 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
    - Vinnl 8y ago
      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.
    - jessaustin 8y ago
      The python distribution infrastructure lags far behind that of javascript.
mrspeaker 8y ago
"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."
- jwdunne 8y ago
  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 https://github.com/facebook/jest/issues/6694
  - GijsjanB 8y ago
    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
    - jwdunne 8y ago
      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.
- Vinnl 8y ago
  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 https://news.ycombinator.com/item?id=19294189
ChrisSD 8y ago
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.
userbinator 8y ago
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.
ascorbic 8y ago
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.
- l_t 8y ago
  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.

by hliyan 8y ago

weego 8y ago

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.

quantummkv 8y ago
> 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.
- hliyan 8y ago
  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.
  - wiredearp 8y ago
    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.
    - z3t4 8y ago
      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.
- gedy 8y ago
  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.
  - quantummkv 8y ago
    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.
    - MarvelousWololo 8y ago
      Could you share some examples of these failures please?
      - krageon 8y ago
        The community as a whole has the kind of immaturity that leads to repeated and terrifying security incidents, for one.
Vinnl 8y ago
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.
- riquito 8y ago
  > 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
  - Vinnl 8y ago
    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.
  - jessaustin 8y ago
    The python distribution infrastructure lags far behind that of javascript.

mrspeaker 8y ago

"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."

jwdunne 8y ago
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 https://github.com/facebook/jest/issues/6694
- GijsjanB 8y ago
  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
  - jwdunne 8y ago
    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.
Vinnl 8y ago
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 https://news.ycombinator.com/item?id=19294189

ChrisSD 8y ago

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.

userbinator 8y ago

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.

ascorbic 8y ago

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.

l_t 8y ago
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.