3 ms·

I can't do much without some degree of pre-processing. The browser can't resolve NodeJS-style require's, so I'll need a bundler to serve my app in a manner the

I can't do much without some degree of pre-processing. The browser can't resolve NodeJS-style require's, so I'll need a bundler to serve my app in a manner the browser can understand. I imagine most use cases today face this dilemma. It wasn't the type annotations holding me back for requiring pre-processing, it was the ecosystem around how JavaScript is written that is the primary factor.

runarberg 4y ago
I haven’t used NodeJS type requires in new projects since Node 12 (which EOL-ed last april). Most code I write now uses standard imports. There is off course some issues around resolving from npm but there are mitigations, and going forward import maps (already supported by Chrome) will solve most of these. Really the only reason to do pre-processing is if you want to do some optimization beyond what the browser can do, or if you want to write a syntax which is not supported by your target runtimes. And for many developers (including most library authors) this is not the case.
- 88913527 4y ago
  So the moment a single library author doesn't support a target runtime I have, I have to pre-process. It seems to further the point that pre-processing is a critical step for many that isn't going away. Some projects like Angular are using non-standards compliant decorators, so until they re-think that decision, it's an absolute must for them. It's really hard to guarantee a world where my complete dependency tree meets my target runtime requirements (eg: I might also not be using nodejs-style require, but my dependencies could be), so pre-processing seems like something that will be with us for some time.
afavour 4y ago
That’s your use case, but it’s not the use case the standards bodies have in mind. ESM imports are the standard, unlike Node’s require. And you can now write ESM code that’ll run flawlessly on the backend and the front end without any transpiration. IMO that’s huge. Type annotations remove yet another blocker.

runarberg 4y ago

I haven’t used NodeJS type requires in new projects since Node 12 (which EOL-ed last april). Most code I write now uses standard imports. There is off course some issues around resolving from npm but there are mitigations, and going forward import maps (already supported by Chrome) will solve most of these. Really the only reason to do pre-processing is if you want to do some optimization beyond what the browser can do, or if you want to write a syntax which is not supported by your target runtimes. And for many developers (including most library authors) this is not the case.

88913527 4y ago
So the moment a single library author doesn't support a target runtime I have, I have to pre-process. It seems to further the point that pre-processing is a critical step for many that isn't going away. Some projects like Angular are using non-standards compliant decorators, so until they re-think that decision, it's an absolute must for them. It's really hard to guarantee a world where my complete dependency tree meets my target runtime requirements (eg: I might also not be using nodejs-style require, but my dependencies could be), so pre-processing seems like something that will be with us for some time.

afavour 4y ago

That’s your use case, but it’s not the use case the standards bodies have in mind. ESM imports are the standard, unlike Node’s require. And you can now write ESM code that’ll run flawlessly on the backend and the front end without any transpiration. IMO that’s huge. Type annotations remove yet another blocker.