Live data from Hacker News

The state of JavaScript modules

medium.com

11–20 of 106 posts

Re: The state of JavaScript modules

#11
post #9

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…

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.

Re: The state of JavaScript modules

#12
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.

Re: The state of JavaScript modules

#13
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).

Re: The state of JavaScript modules

#14
post #9

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…

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.

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.

Re: The state of JavaScript modules

#15
post #14

Earlier quoted context omitted.

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.

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]

Re: The state of JavaScript modules

#16
post #9

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…

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/

Re: The state of JavaScript modules

#17

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 coul…

Why does your app have to be bleeding-edge?

Re: The state of JavaScript modules

#18

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 coul…

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.

Re: The state of JavaScript modules

#19

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 coul…

Why does your app have to be bleeding-edge?

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

Re: The state of JavaScript modules

#20
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 [2] https://github.com/whatwg/loader

Post reply on HN