9 ms·

The state of JavaScript modules

139 points by thmslee 9y ago

anythingbot 9y ago
just use amdefine edit: not sure why people don't like amdefine Paul Graham is wrong. Downvote discussion helps. Asking for feedback is something we want to encourage.
- elliotec 9y ago
  You can't vote posts down on HN. If it has low votes it just means people aren't interested enough to vote up.
  - deleted 9y ago
    [deleted]
  - gjjrfcbugxbhf 9y ago
    Once one has more than 500 karma one gets a downvote button..
    - deleted 9y ago
      [deleted]
  - marklgr 9y ago
    There are downvotes on HN, you just need to reach some karma (500 if I'm correct) before being able to do so.
    - elliotec 9y ago
      That is for comments, he said posts. You cannot vote down posts (submissions) at all. I'm obviously aware of the downvote button on comments, and thanks to those of you who tried to prove a point by hitting yours on this one.
    - deleted 9y ago
      [deleted]
- shakna 9y ago
  > just use amdefine That's unhelpful, and hardly helps with today's problems. We didn't need classes, because we had objects. You could create your own constructors and methods. Why did we need anything more? Why does Scheme today not just use McCarthy's original 7 special forms? A discussion about the differences of modules today, and where you can rely on compatibility is a good thing that helps with shaping the future. > stop voting this post down Don't mention downvotes. It isn't helpful to discussion, and is sort of against HNs guidelines. It will earn you more. [1] [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
LeoNatan25 9y ago
“Most frontend developers still remember the dark days of JavaScript dependency management.” As opposed to now, where even the smallest “app” has hundreds if not thousands of dependencies for the most basic of functionality (‘need to iterate an array, better bring lodash’), often there being multiple copies of the same dependency due to conflicting versions?
- bfred_it 9y ago
  Do you prefer handling these conflicts by hand by shuffling global variables?
  - LeoNatan25 9y ago
    I would prefer there be a comprehensive base library, thus cutting dependencies to a minimum. Beyond that, I would prefer to handle those manually, yes, rather than have multiple versions of these libraries just load into memory. Conflicting dependencies is not a coherent development state.
- bshimmin 9y ago
  You beat me to the punch: I really don't remember "you would copy and paste a library into a vendor folder, rely on global variables, try to concat everything in the right order and still would had to deal with namespace issues" as being all that big of a problem! It was (is!) simple enough, and it mostly worked; if you were trying to deploy something to a customer site where they already accidentally had two different old versions of jQuery loaded in the page, sure, that could be problematic... but deploying stuff to customer sites is always problematic one way or the other. (I accept this is something of a rose-tinted over-simplification, but a paragraph titled "An ancient fear" probably deserves some slightly flippant commentary.)
  - eloisant 9y ago
    I do remember that being a huge pain in the back, as in: - You have to maintain a full list of your files, in order, to include them in your html page (in dev mode) and concat (for prod mode) - If you want to know on what other module a given module depends on, you have to hunt every call in the source code - You can never remove a dependency on an external lib as you can never be sure it's not used somewhere - Upgrading a lib was a pain Compared to every other language, it was a huge pain point. It's not by chance that so many people started to work on implementing modules for JS, there was a real need.
git-pull 9y ago
I support innovation and people who like to code and build great things. And am happy to see JS is getting these features. I even see a downvoted comment to "just use amdefine". Well that solution worked fine for me, then 5 years of amazing hop scotch between build tools and libraries happened. And while some report benefits and advancement, I have to tell you, the amount of tools you have to pull in these days just get some single page interaction going... Just stop. And we need to draw a line between "progress" for the language and its libraries vs introducing features without discipline. The more features a language has, the harder it will be for open source and industry to develop consensus on what's idiomatic. Want to know another language feature? Being stable. I swear, it's like the language reinvents itself every year. Give me some sort of promise when you'll leave the standard alone, then I'll wait for the community to form best practices / libraries to catch up. After the dust settles, I'll invest time reading up on the standard. Ain't trying to jab javascript. Love the language, community is top tier, but everything these days from build tools to libraries seems like a moving target.
- anythingbot 9y ago
  I said just use amdefine. I didn't say "just use amdefine" because I want you to agree with me. I don't care if you agree with me. I said it because it appears to solve the same problem the author has, and it is tiny.
  - dagw 9y ago
    Seriously. Just use it. I'm sorry, but that is hardly a convincing argument. For all I know you may be right, but just write one paragraph about what "amdefine" actually is/does, and why it is a better solution than what people are currently using and people might actually agree with you.
    - deleted 9y ago
      [deleted]
- hdhzy 9y ago
  Well, in ancient ES3 times all we had was functions and so we used functions for everything and that was good as they are extremely versatile. But now a different problem appeared: it's hard to statically analyze function-based constructs for various purposes (tree shaking, refactoring, etc.) so new syntax was invented to capture what was convention inside the language itself. If you look at classes they are "just" syntactic sugar that works just like good ol' prototype system. But the one key difference is that this is now easier to statically analyze. The same happens with modules although having written several require.js like loaders I find the ES system a little bit lacking. > I swear, it's like the language reinvents itself every year. Give me some sort of promise when you'll leave the standard alone, then I'll wait for the community to form best practices / libraries to catch up. After the dust settles, I'll invest time reading up on the standard. Sorry to disappoint you but this will never happen, especially not in JavaScript. Actually the standard is released every year that's why we have ES2015, ES2016... But that's just the way things work in IT: people keep changing things and we are supposed to follow. > ... seems like a moving target. Yes, exactly. But that seems to be "by design" rather than "by accident", see Fire and Motion [0]. [0]: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
sergiotapia 9y ago
Just like when Meteor was the hottest kid on the block, ES6 came along and pulled the rug out from under me. Now that I'm finally used to ES6, here comes some other frankenstein with more flesh bolted on. At what point will Javascript relax and stop reinventing itself and what works? When will stability become a core goal for the Javascript thought-leaders? I haven't worked with .NET and C# for years but I bet I could feel right at home today. I couldn't say the same for Javascript.
- eindbaas 9y ago
  Why does your app have to be bleeding-edge?
  - sergiotapia 9y ago
    If I hadn't migrated to ES6, I would not have been able to use some javascript packages I enjoy. For example: https://github.com/JedWatson/react-select https://github.com/JedWatson/react-select
    - dalailambda 9y ago
      There doesn't seem to be any part of that package that requires ES6 to use. You can use it as an ES6 module, but the commonjs version should work fine as well.
    - tlrobinson 9y ago
      You can transpile dependencies without migrating your whole app (though I'm not sure why you would)
- sim0n 9y ago
  You don't have to use the hottest new framework or language feature. The JavaScript you're writing now will still be supported while the language evolves and improves.
  - kuschku 9y ago
franciscop 9y ago
Something I think is not explicit enough: you can import whatever from 'whatever' independently of whenever that package is updated or not. What you cannot do is require() an exported package. This is great and in no way the same as Python 3; with this old packages are compatible with newer ones, it is newer ones the ones that will not be compatible with older ones (not ideal, but still acceptable IMO).
robertkrahn01 9y ago
The work done by Guy Bedford and others in building SystemJS [1] is great. SystemJS is a practical implementation of the whatwg loader specification proposal [2]. Using SystemJS you can use es modules in node.js and the browser right now. On nodejs it provides an escape hatch via System._nodeRequire to fallback to node.js' require from within an es module if you really have to. The one thing that I really miss is that most (all?) JS module implementations really seem to be focused on static compile workflows. Sure, for deployments you want that, for development JS as a very dynamic language would offer much better support for live programming systems if the module systems would play along nicely. One reason why I personally was excited to see that the loader proposal initially considered custom locate/fetch/define behavior added via hooks but more recent discussions about bringing it forward seem to dismiss that. I think for great tooling a module system that supports both deployment as well as development needs is necessary and would really add to the JS ecosystem. [1] https://github.com/systemjs/systemjs https://github.com/systemjs/systemjs [2] https://github.com/whatwg/loader https://github.com/whatwg/loader
- spankalee 9y ago
  Careful, that loader spec is dead. Unless something drastic changes, don't expect any of those hooks.
- _pmf_ 9y ago
  > The one thing that I really miss is that most (all?) JS module implementations really seem to be focused on static compile workflows. That's what baffles me coming from Java and C#; I can have dynamically loaded modules with strongly typed interfaces in these ecosystems, but not in any JS module system.
  - bfred_it 9y ago
    require() is dynamic and import() will be too. What are you talking about? JavaScript is not a typed language (yet?) so it's like expecting pigs to fly.
    - 9y ago
drej 9y ago
I recently started working on a JavaScript thingy and I'm really glad for two things: 1. These package managers and build systems and all that are fairly replacable in terms of implementation. They all just give you some namespace management, but the actual JS code is usually the same or very similar. 2. I'm using vanilla JavaScript, so even though I have to reinvent the wheel from time to time, I don't have to support outdated APIs, bother people with further dependencies, and save bandwidth. And given that I'm lucky enough not having to worry about backwards compatibility, I can leverage all the Maps, Sets, UintxArrays and other modern JavaScript goodness that was previously delegated to libraries.
simooooo 9y ago
So... Still a nightmare of competing solutions.
- 35bge57dtjku 9y ago
  Some lessons are hard learned.
pabl0rg 9y ago
KotlinJS, please add google closure support and save us from the madness of javascript tooling, modules, etc.
skratlo 9y ago
One has to admit that exporting to / importing from global namespace, as in the old days, is for a typical/small project way easier and simpler than to deal with conflicting module systems and mediocre dependency/build tooling. JS module/dependency/build ecosystem is sick and fragmented and The solution is in the cold.
- bfred_it 9y ago
  I've been doing that recently with Web Extensions. It's not "easier". After a handful of files I just end up implementing rollup.
yladiz 9y ago
Serious question: what benefit does this (.mjs) have over the current way of doing things?
- Vinnl 9y ago
  It enables you to not package modules that your app's not using, preventing the dreaded "shipping x MB to your users".
  - yladiz 9y ago
    But can't you just do some "tree shaking" with something like Rollup, so it only sends the code you use?
    - Vinnl 9y ago
      You can only do so _thanks to_ the new module system. From the Rollup website [1]: > Since this approach is based on explicit import and export statements, it is vastly more effective than simply running an automated minifier to detect unused variables in the compiled output code. [1] https://rollupjs.org/#tree-shaking https://rollupjs.org/#tree-shaking
partycoder 9y ago
Given the fact that few npm package authors understand the node.js event loop, pick your modules very carefully.
ausjke 9y ago
Don't know what to say really, I just dislike JS no matter how hard I tried, it's a chaos to say the least, other languages, such as C, C++, Java, PHP are way more cleaner and reliable to me. Also it's so easy to be burnt out by those JS new advancements...enough is enough
dwaltrip 9y ago
All of the top level comments are complaining... How many of those people have written at least 10k+ lines of JavaScript? These changes are hard, but they are undeniably improving the language. And as many others have stated repeatedly, it is not necessary to chase the bleeding edge. For example, I just learned React for the first time a few weeks ago, and I'm glad I waited (I haven't started using Redux yet either). I'm also still using browserify instead of webpack. And so on.
btomstrem 9y ago
Is web assembly going to fix any of these?

139 points by thmslee 9y ago

just use amdefine edit: not sure why people don't like amdefine Paul Graham is wrong. Downvote discussion helps. Asking for feedback is something we want to encourage.

elliotec 9y ago
You can't vote posts down on HN. If it has low votes it just means people aren't interested enough to vote up.
- deleted 9y ago
  [deleted]
- gjjrfcbugxbhf 9y ago
  Once one has more than 500 karma one gets a downvote button..
  - deleted 9y ago
    [deleted]
- marklgr 9y ago
  There are downvotes on HN, you just need to reach some karma (500 if I'm correct) before being able to do so.
  - elliotec 9y ago
    That is for comments, he said posts. You cannot vote down posts (submissions) at all. I'm obviously aware of the downvote button on comments, and thanks to those of you who tried to prove a point by hitting yours on this one.
  - deleted 9y ago
    [deleted]
shakna 9y ago
> just use amdefine That's unhelpful, and hardly helps with today's problems. We didn't need classes, because we had objects. You could create your own constructors and methods. Why did we need anything more? Why does Scheme today not just use McCarthy's original 7 special forms? A discussion about the differences of modules today, and where you can rely on compatibility is a good thing that helps with shaping the future. > stop voting this post down Don't mention downvotes. It isn't helpful to discussion, and is sort of against HNs guidelines. It will earn you more. [1] [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

LeoNatan25 9y ago

“Most frontend developers still remember the dark days of JavaScript dependency management.” As opposed to now, where even the smallest “app” has hundreds if not thousands of dependencies for the most basic of functionality (‘need to iterate an array, better bring lodash’), often there being multiple copies of the same dependency due to conflicting versions?

bfred_it 9y ago
Do you prefer handling these conflicts by hand by shuffling global variables?
- LeoNatan25 9y ago
  I would prefer there be a comprehensive base library, thus cutting dependencies to a minimum. Beyond that, I would prefer to handle those manually, yes, rather than have multiple versions of these libraries just load into memory. Conflicting dependencies is not a coherent development state.
bshimmin 9y ago
You beat me to the punch: I really don't remember "you would copy and paste a library into a vendor folder, rely on global variables, try to concat everything in the right order and still would had to deal with namespace issues" as being all that big of a problem! It was (is!) simple enough, and it mostly worked; if you were trying to deploy something to a customer site where they already accidentally had two different old versions of jQuery loaded in the page, sure, that could be problematic... but deploying stuff to customer sites is always problematic one way or the other. (I accept this is something of a rose-tinted over-simplification, but a paragraph titled "An ancient fear" probably deserves some slightly flippant commentary.)
- eloisant 9y ago
  I do remember that being a huge pain in the back, as in: - You have to maintain a full list of your files, in order, to include them in your html page (in dev mode) and concat (for prod mode) - If you want to know on what other module a given module depends on, you have to hunt every call in the source code - You can never remove a dependency on an external lib as you can never be sure it's not used somewhere - Upgrading a lib was a pain Compared to every other language, it was a huge pain point. It's not by chance that so many people started to work on implementing modules for JS, there was a real need.

git-pull 9y ago

I support innovation and people who like to code and build great things. And am happy to see JS is getting these features. I even see a downvoted comment to "just use amdefine". Well that solution worked fine for me, then 5 years of amazing hop scotch between build tools and libraries happened. And while some report benefits and advancement, I have to tell you, the amount of tools you have to pull in these days just get some single page interaction going... Just stop. And we need to draw a line between "progress" for the language and its libraries vs introducing features without discipline. The more features a language has, the harder it will be for open source and industry to develop consensus on what's idiomatic. Want to know another language feature? Being stable. I swear, it's like the language reinvents itself every year. Give me some sort of promise when you'll leave the standard alone, then I'll wait for the community to form best practices / libraries to catch up. After the dust settles, I'll invest time reading up on the standard. Ain't trying to jab javascript. Love the language, community is top tier, but everything these days from build tools to libraries seems like a moving target.

anythingbot 9y ago
I said just use amdefine. I didn't say "just use amdefine" because I want you to agree with me. I don't care if you agree with me. I said it because it appears to solve the same problem the author has, and it is tiny.
- dagw 9y ago
  Seriously. Just use it. I'm sorry, but that is hardly a convincing argument. For all I know you may be right, but just write one paragraph about what "amdefine" actually is/does, and why it is a better solution than what people are currently using and people might actually agree with you.
  - deleted 9y ago
    [deleted]
hdhzy 9y ago
Well, in ancient ES3 times all we had was functions and so we used functions for everything and that was good as they are extremely versatile. But now a different problem appeared: it's hard to statically analyze function-based constructs for various purposes (tree shaking, refactoring, etc.) so new syntax was invented to capture what was convention inside the language itself. If you look at classes they are "just" syntactic sugar that works just like good ol' prototype system. But the one key difference is that this is now easier to statically analyze. The same happens with modules although having written several require.js like loaders I find the ES system a little bit lacking. > I swear, it's like the language reinvents itself every year. Give me some sort of promise when you'll leave the standard alone, then I'll wait for the community to form best practices / libraries to catch up. After the dust settles, I'll invest time reading up on the standard. Sorry to disappoint you but this will never happen, especially not in JavaScript. Actually the standard is released every year that's why we have ES2015, ES2016... But that's just the way things work in IT: people keep changing things and we are supposed to follow. > ... seems like a moving target. Yes, exactly. But that seems to be "by design" rather than "by accident", see Fire and Motion [0]. [0]: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

sergiotapia 9y ago

Just like when Meteor was the hottest kid on the block, ES6 came along and pulled the rug out from under me. Now that I'm finally used to ES6, here comes some other frankenstein with more flesh bolted on. At what point will Javascript relax and stop reinventing itself and what works? When will stability become a core goal for the Javascript thought-leaders? I haven't worked with .NET and C# for years but I bet I could feel right at home today. I couldn't say the same for Javascript.

eindbaas 9y ago
Why does your app have to be bleeding-edge?
- sergiotapia 9y ago
  If I hadn't migrated to ES6, I would not have been able to use some javascript packages I enjoy. For example: https://github.com/JedWatson/react-select https://github.com/JedWatson/react-select
  - dalailambda 9y ago
    There doesn't seem to be any part of that package that requires ES6 to use. You can use it as an ES6 module, but the commonjs version should work fine as well.
  - tlrobinson 9y ago
    You can transpile dependencies without migrating your whole app (though I'm not sure why you would)
sim0n 9y ago
You don't have to use the hottest new framework or language feature. The JavaScript you're writing now will still be supported while the language evolves and improves.
- kuschku 9y ago

franciscop 9y ago

Something I think is not explicit enough: you can import whatever from 'whatever' independently of whenever that package is updated or not. What you cannot do is require() an exported package. This is great and in no way the same as Python 3; with this old packages are compatible with newer ones, it is newer ones the ones that will not be compatible with older ones (not ideal, but still acceptable IMO).

robertkrahn01 9y ago

The work done by Guy Bedford and others in building SystemJS [1] is great. SystemJS is a practical implementation of the whatwg loader specification proposal [2]. Using SystemJS you can use es modules in node.js and the browser right now. On nodejs it provides an escape hatch via System._nodeRequire to fallback to node.js' require from within an es module if you really have to. The one thing that I really miss is that most (all?) JS module implementations really seem to be focused on static compile workflows. Sure, for deployments you want that, for development JS as a very dynamic language would offer much better support for live programming systems if the module systems would play along nicely. One reason why I personally was excited to see that the loader proposal initially considered custom locate/fetch/define behavior added via hooks but more recent discussions about bringing it forward seem to dismiss that. I think for great tooling a module system that supports both deployment as well as development needs is necessary and would really add to the JS ecosystem. [1] https://github.com/systemjs/systemjs https://github.com/systemjs/systemjs [2] https://github.com/whatwg/loader https://github.com/whatwg/loader

spankalee 9y ago
Careful, that loader spec is dead. Unless something drastic changes, don't expect any of those hooks.
_pmf_ 9y ago
> The one thing that I really miss is that most (all?) JS module implementations really seem to be focused on static compile workflows. That's what baffles me coming from Java and C#; I can have dynamically loaded modules with strongly typed interfaces in these ecosystems, but not in any JS module system.
- bfred_it 9y ago
  require() is dynamic and import() will be too. What are you talking about? JavaScript is not a typed language (yet?) so it's like expecting pigs to fly.
  - 9y ago

drej 9y ago

I recently started working on a JavaScript thingy and I'm really glad for two things: 1. These package managers and build systems and all that are fairly replacable in terms of implementation. They all just give you some namespace management, but the actual JS code is usually the same or very similar. 2. I'm using vanilla JavaScript, so even though I have to reinvent the wheel from time to time, I don't have to support outdated APIs, bother people with further dependencies, and save bandwidth. And given that I'm lucky enough not having to worry about backwards compatibility, I can leverage all the Maps, Sets, UintxArrays and other modern JavaScript goodness that was previously delegated to libraries.

simooooo 9y ago

So... Still a nightmare of competing solutions.

35bge57dtjku 9y ago
Some lessons are hard learned.

pabl0rg 9y ago

KotlinJS, please add google closure support and save us from the madness of javascript tooling, modules, etc.

skratlo 9y ago

One has to admit that exporting to / importing from global namespace, as in the old days, is for a typical/small project way easier and simpler than to deal with conflicting module systems and mediocre dependency/build tooling. JS module/dependency/build ecosystem is sick and fragmented and The solution is in the cold.

bfred_it 9y ago
I've been doing that recently with Web Extensions. It's not "easier". After a handful of files I just end up implementing rollup.

yladiz 9y ago

Serious question: what benefit does this (.mjs) have over the current way of doing things?

Vinnl 9y ago
It enables you to not package modules that your app's not using, preventing the dreaded "shipping x MB to your users".
- yladiz 9y ago
  But can't you just do some "tree shaking" with something like Rollup, so it only sends the code you use?
  - Vinnl 9y ago
    You can only do so _thanks to_ the new module system. From the Rollup website [1]: > Since this approach is based on explicit import and export statements, it is vastly more effective than simply running an automated minifier to detect unused variables in the compiled output code. [1] https://rollupjs.org/#tree-shaking https://rollupjs.org/#tree-shaking

partycoder 9y ago

Given the fact that few npm package authors understand the node.js event loop, pick your modules very carefully.

ausjke 9y ago

Don't know what to say really, I just dislike JS no matter how hard I tried, it's a chaos to say the least, other languages, such as C, C++, Java, PHP are way more cleaner and reliable to me. Also it's so easy to be burnt out by those JS new advancements...enough is enough

dwaltrip 9y ago

All of the top level comments are complaining... How many of those people have written at least 10k+ lines of JavaScript? These changes are hard, but they are undeniably improving the language. And as many others have stated repeatedly, it is not necessary to chase the bleeding edge. For example, I just learned React for the first time a few weeks ago, and I'm glad I waited (I haven't started using Redux yet either). I'm also still using browserify instead of webpack. And so on.

btomstrem 9y ago

Is web assembly going to fix any of these?