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

31–40 of 106 posts

Re: The state of JavaScript modules

#31

Post by tlrobinson »

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…

Before ~2015: "JavaScript is a terrible language!"

After ~2016: "Stop improving JavaScript, I can't keep up!"

(Not a personal attack, just general sentiment I've observed)

Re: The state of JavaScript modules

#32

Post by tlrobinson »

kuschku wrote: post #26
sim0n wrote: post #18

Earlier quoted context omitted.

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.

So transpile the library. Webpack and others can do it.

Re: The state of JavaScript modules

#33

Post by octalmage »

kuschku wrote: post #26
sim0n wrote: post #18

Earlier quoted context omitted.

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.

Many libraries that use ES6 features distribute the transpiled version through npm or GitHub. If they don't, you can just transpile the library using Webpack then use that.

Or you could use codemods to update your code base in an automated way. See: https://github.com/cpojer/js-codemod

Re: The state of JavaScript modules

#34

Post by skratlo »

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.

Re: The state of JavaScript modules

#35

Post by thinkxl »

git-pull wrote: 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…

Also, there is a trend to shame old technology, or better said, to shame devs that use jQuery, Backbone, or similar.

> "Oh, why are you using Backbone? That's an old and obsolete technology. You should learn React/Vue/Elm."

(Vue is easy to learn for new devs, though)

The dev is not familiar with functional programming or other paradigms that React suggests or requires you to know. He may be in a early learning process where Backbone/jQuery makes it easier for him to start on building webapps.

Re: The state of JavaScript modules

#36

Post by bfred_it »

LeoNatan25 wrote: post #8

“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?

Do you prefer handling these conflicts by hand by shuffling global variables?

Re: The state of JavaScript modules

#37

Post by bfred_it »

skratlo wrote: post #34

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.

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

Re: The state of JavaScript modules

#38

Post by _pmf_ »

tlrobinson wrote: post #31
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…

Before ~2015: "JavaScript is a terrible language!" After ~2016: "Stop improving JavaScript, I can't keep up!" (Not a personal attack, just general sentiment I've observed)

To be fair, those are not mutually exclusive options.

Re: The state of JavaScript modules

#39

Post by bfred_it »

_pmf_ wrote: post #30
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.

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.

Re: The state of JavaScript modules

#40

Post by bshimmin »

LeoNatan25 wrote: post #8

“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?

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

Post reply on HN