Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The state of JavaScript modules

medium.com

Post reply on HN
Print view View original

21–30 of 106 posts

Re: The state of JavaScript modules

#21

Post by drej »

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.

Re: The state of JavaScript modules

#23

Post by rimliu »

sergiotapia wrote: post #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 coul…

  > At what point will Javascript relax and stop reinventing
  > itself and what works?
I am afraid part of the reason for this is continuous effort to put a square peg into a round hole (by this I mean the "web for everything, JS for everything" attitude), so it will go on for a while.

Re: The state of JavaScript modules

#24

Post by dalailambda »

sergiotapia wrote: post #19
eindbaas wrote: post #17

Earlier quoted context omitted.

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

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.

Re: The state of JavaScript modules

#26

Post by kuschku »

sim0n wrote: post #18
sergiotapia wrote: post #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 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.

Nice idea, but false. Your code depends on libraries and frameworks, which constantly change and adapt to the the mood of the time.

Re: The state of JavaScript modules

#27

Post by spankalee »

robertkrahn01 wrote: post #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 tha…

Careful, that loader spec is dead. Unless something drastic changes, don't expect any of those hooks.

Re: The state of JavaScript modules

#28

Post by tlrobinson »

sergiotapia wrote: post #19
eindbaas wrote: post #17

Earlier quoted context omitted.

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

You can transpile dependencies without migrating your whole app (though I'm not sure why you would)

Re: The state of JavaScript modules

#30

Post by _pmf_ »

robertkrahn01 wrote: post #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 tha…

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

Post reply on HN