5 ms·

I think the problem was using Node in the first place - most the article is fighting node + NPM nonsense. I personally try to avoid Node + NPM where I can thes

I think the problem was using Node in the first place - most the article is fighting node + NPM nonsense. I personally try to avoid Node + NPM where I can these days, and use Deno for backend stuff since it is much more sane IMO. I've never heard of people putting typescript into a .js file - is that some node thing? Modules in the browser for vanilla JS is a delight and Just Works though. I've started doing it recently and it is lovely - no need for a bundler/compile step. There are concerns about load performance if there ends up being many modules, but you can do on-demand module loading via vanilla javascript (import returns a promise IIRC) for when that happens.

MCArth 4y ago
I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export only an es module.
- mattlondon 4y ago
  I guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things. It seems to me that nopde + npm here is - as usual - a bit of a cesspit. It is this sort of thing that keeps driving me away from node + npm. There is just too much hassle and gotchyas and concerns when using it these days. By comparison Deno is a joy to use, as is pure vanilla js in the browser without a build step.
  - whostolemyhat 4y ago
    > why should ECMAscript care about what node does? Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?
    - mattlondon 4y ago
      The same could be said about individual browsers. With web standards there is precedent for doing the "right" thing rather than just going along with whatever one product has already implemented and calling it a standard. E.g. there were recent posts here on HN about WebSQL (already implemented in Chrome so many hundreds of millions of users) being replaced by a design agreed upon by all interested parties rather than just what Google wanted for Chrome and Gmail. Indexdb may not be what everyone wanted of course, but that is beside the point. There is a place for experimentation and trying stuff out, but just shipping something first shouldn't mean you get to dictate future standards or be guaranteed backwards compatibility or a zero-effort upgrade path. Standards should learn from and build upon earlier implementations and mistakes. They should not be slaves to what has gone before.
    - lelanthran 4y ago
      > Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day? They shouldn't pay any attention to it. The language spec should drive the implementations, not a single implementation driving the language specification. Normal exceptions for languages that have a spec based on a reference implementation.
      - ByteJockey 4y ago
        That's fine in a language with a bunch of implementations, but JS only has one (relevant) implementation. V8 powers Chrome, all Chrome-based browsers (Brave, Edge, etc), node, and deno. Sure, you can switch your backend to some esoteric thing based on Rhino, but unlike C/C++/whatever, your end-user's also have an implementation and it matters. And they are overwhelmingly using v8. The Ecma International is basically naval-gazing at this point. They don't control JS, google does. Just see what happened when they added TCO to the spec and google didn't implement it.
- an1sotropy 4y ago
  You made a similar comment elsewhere about ES6 being "half-baked", and I'll ask my question again here: Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - MCArth 4y ago
    I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.
    - an1sotropy 4y ago
      ok, that makes sense (and sorry for making you answer twice). But I think sometimes a clean break is a necessary part of progress.
- WorldMaker 4y ago
  I think the history shows that Node's CommonJS was the half-baked approach that even at time browser owners and frontend programmers were complaining couldn't operate correctly in a browser environment. (AMD is awful, but it was at least designed around the constraints of a browser.) ES Modules are possibly over-baked, but they are certainly not half-baked: they are extremely carefully designed to operate well under the constraints of browser environments (and Deno and Node 12+ shows they work well in other environments too). It's not this ES Module spec's fault that Node picked a half-baked module format that was known to be deficient at the time and built a massive legacy ecosystem on top of a bad module format. As nasty as AMD is to write, had Node picked something much more like it the backwards compatibility story would have been much, much simpler all around. It's fair to suggest that because the Node ecosystem has become so dominant that the lack of backward compatibility is a serious concern in practical usage of ES Modules, but that doesn't mean ES Modules are half-baked, it means the ecosystem has growing pains and migration needs. Many of those growing pains and migration needs are getting solved. It wasn't the ES Module spec's job to magically prevent growing pains/migration needs, it was to set a solid "goal spec" for the end result to migrate to. I think it did a relatively good job at that just as I sometimes lament the growing pains and migrations I experience in my own apps. I blame CommonJS though. CommonJS should never have become such a widely deployed "standard" with no strong compatibility with browser environments built in.
AgentME 4y ago
+1 for Deno. It seems like it's taking the good ideas that developed from the node+npm ecosystem while filing off the unnecessary complexity that's accumulated in the ecosystem over the years. I've worked with node+npm+typescript/babel/webpack/etc for years and know the ecosystem pretty well, but I get apprehensive when thinking of starting a new project with it because there's such a deluge of not-very-meaningful choices and piles of configs for using best-practices while setting up a project. Getting into using Deno has been so refreshingly simple in comparison, and it's made me enthusiastic about starting new projects or libraries. I've had some game/mod ideas for a while that involves having players write real code to interact with games, and I would create some tutorials for beginners to get started writing code so they can use it. I love Typescript and think it would make a good language for it, but I absolutely dreaded the idea when I realized using it properly would involve having to onboard users to all the tooling of Node+npm+build configs+testing tools+eslint etc. Onboarding users to Rust properly almost seems simpler in comparison because of its integrated tooling even accounting for the fact that the language itself is so much harder to use! I mostly scrapped the idea for the time being because of this, but now that I've discovered Deno I've been reinvigorated on the idea. A beginner tutorial involving Deno can actually focus on using the language with a few libraries without having the user get sidetracked into being distracted by a dozen other tools.
- halfmatthalfcat 4y ago
  Why not just use ts-node and be done with it?
  - moochmooch 4y ago
    ts-node introduces its own bugs and ergonomics inconsistencies on top of node. I've used it on multiple projects in the past and ended up removing it as a dep when I've been able to. Not saying anyone who is using ts-node should immediately jump to Deno. Their use cases don't fully overlap.
jseban 4y ago
> I've started doing it recently and it is lovely - no need for a bundler/compile step. Same here, I'm also doing on-demand module loading, it's an enormous productivity boost for me as a developer because of the shorter feedback loop, zero time spent fighting/configuring the tool chain, and how powerful the debugger in the browser is when it actually works. It's also a massive performance boost for the resulting web page because of orders of magnitude less code, and small entry point/initial page load.
WorldMaker 4y ago
> I've never heard of people putting typescript into a .js file - is that some node thing? Node won't load TS files by default at all. You need complicated plugins like ts-node and few people know/setup ts-node, and I believe ts-node still expects Typescript code to be in TS files. It's likely accidental babel "bleedover" in that at this point even non-Typescript babel presets will strip Typescript types without warning.

MCArth 4y ago

I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export only an es module.

mattlondon 4y ago
I guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things. It seems to me that nopde + npm here is - as usual - a bit of a cesspit. It is this sort of thing that keeps driving me away from node + npm. There is just too much hassle and gotchyas and concerns when using it these days. By comparison Deno is a joy to use, as is pure vanilla js in the browser without a build step.
- whostolemyhat 4y ago
  > why should ECMAscript care about what node does? Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?
  - mattlondon 4y ago
    The same could be said about individual browsers. With web standards there is precedent for doing the "right" thing rather than just going along with whatever one product has already implemented and calling it a standard. E.g. there were recent posts here on HN about WebSQL (already implemented in Chrome so many hundreds of millions of users) being replaced by a design agreed upon by all interested parties rather than just what Google wanted for Chrome and Gmail. Indexdb may not be what everyone wanted of course, but that is beside the point. There is a place for experimentation and trying stuff out, but just shipping something first shouldn't mean you get to dictate future standards or be guaranteed backwards compatibility or a zero-effort upgrade path. Standards should learn from and build upon earlier implementations and mistakes. They should not be slaves to what has gone before.
  - lelanthran 4y ago
    > Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day? They shouldn't pay any attention to it. The language spec should drive the implementations, not a single implementation driving the language specification. Normal exceptions for languages that have a spec based on a reference implementation.
    - ByteJockey 4y ago
      That's fine in a language with a bunch of implementations, but JS only has one (relevant) implementation. V8 powers Chrome, all Chrome-based browsers (Brave, Edge, etc), node, and deno. Sure, you can switch your backend to some esoteric thing based on Rhino, but unlike C/C++/whatever, your end-user's also have an implementation and it matters. And they are overwhelmingly using v8. The Ecma International is basically naval-gazing at this point. They don't control JS, google does. Just see what happened when they added TCO to the spec and google didn't implement it.
an1sotropy 4y ago
You made a similar comment elsewhere about ES6 being "half-baked", and I'll ask my question again here: Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- MCArth 4y ago
  I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.
  - an1sotropy 4y ago
    ok, that makes sense (and sorry for making you answer twice). But I think sometimes a clean break is a necessary part of progress.
WorldMaker 4y ago
I think the history shows that Node's CommonJS was the half-baked approach that even at time browser owners and frontend programmers were complaining couldn't operate correctly in a browser environment. (AMD is awful, but it was at least designed around the constraints of a browser.) ES Modules are possibly over-baked, but they are certainly not half-baked: they are extremely carefully designed to operate well under the constraints of browser environments (and Deno and Node 12+ shows they work well in other environments too). It's not this ES Module spec's fault that Node picked a half-baked module format that was known to be deficient at the time and built a massive legacy ecosystem on top of a bad module format. As nasty as AMD is to write, had Node picked something much more like it the backwards compatibility story would have been much, much simpler all around. It's fair to suggest that because the Node ecosystem has become so dominant that the lack of backward compatibility is a serious concern in practical usage of ES Modules, but that doesn't mean ES Modules are half-baked, it means the ecosystem has growing pains and migration needs. Many of those growing pains and migration needs are getting solved. It wasn't the ES Module spec's job to magically prevent growing pains/migration needs, it was to set a solid "goal spec" for the end result to migrate to. I think it did a relatively good job at that just as I sometimes lament the growing pains and migrations I experience in my own apps. I blame CommonJS though. CommonJS should never have become such a widely deployed "standard" with no strong compatibility with browser environments built in.

AgentME 4y ago

+1 for Deno. It seems like it's taking the good ideas that developed from the node+npm ecosystem while filing off the unnecessary complexity that's accumulated in the ecosystem over the years. I've worked with node+npm+typescript/babel/webpack/etc for years and know the ecosystem pretty well, but I get apprehensive when thinking of starting a new project with it because there's such a deluge of not-very-meaningful choices and piles of configs for using best-practices while setting up a project. Getting into using Deno has been so refreshingly simple in comparison, and it's made me enthusiastic about starting new projects or libraries. I've had some game/mod ideas for a while that involves having players write real code to interact with games, and I would create some tutorials for beginners to get started writing code so they can use it. I love Typescript and think it would make a good language for it, but I absolutely dreaded the idea when I realized using it properly would involve having to onboard users to all the tooling of Node+npm+build configs+testing tools+eslint etc. Onboarding users to Rust properly almost seems simpler in comparison because of its integrated tooling even accounting for the fact that the language itself is so much harder to use! I mostly scrapped the idea for the time being because of this, but now that I've discovered Deno I've been reinvigorated on the idea. A beginner tutorial involving Deno can actually focus on using the language with a few libraries without having the user get sidetracked into being distracted by a dozen other tools.

halfmatthalfcat 4y ago
Why not just use ts-node and be done with it?
- moochmooch 4y ago
  ts-node introduces its own bugs and ergonomics inconsistencies on top of node. I've used it on multiple projects in the past and ended up removing it as a dep when I've been able to. Not saying anyone who is using ts-node should immediately jump to Deno. Their use cases don't fully overlap.

jseban 4y ago

> I've started doing it recently and it is lovely - no need for a bundler/compile step. Same here, I'm also doing on-demand module loading, it's an enormous productivity boost for me as a developer because of the shorter feedback loop, zero time spent fighting/configuring the tool chain, and how powerful the debugger in the browser is when it actually works. It's also a massive performance boost for the resulting web page because of orders of magnitude less code, and small entry point/initial page load.

WorldMaker 4y ago

> I've never heard of people putting typescript into a .js file - is that some node thing? Node won't load TS files by default at all. You need complicated plugins like ts-node and few people know/setup ts-node, and I believe ts-node still expects Typescript code to be in TS files. It's likely accidental babel "bleedover" in that at this point even non-Typescript babel presets will strip Typescript types without warning.