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

101–106 of 106 posts

Re: The state of JavaScript modules

#101

Post by jbergens »

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…

Actually other languages evolve too. C# 1.0 is not the same as C# 7, Java 1.0 is not close to Java 8 (which differs a lot from Java 7) and soon Java 9 seems to add more changes including new module handling systems.

I think that core js evolution has slowed down. There is not that many new things in ES2017 compared to ES2016.

Some libraries still evolve a lot but that will probably slow down over time. Some tools evolve but that is slower than the libraries. It was a few years between webpack 1 and 2, for example.

Re: The state of JavaScript modules

#102

Post by jbergens »

ilugaslifk wrote: post #91
ng12 wrote: post #89

Earlier quoted context omitted.

> 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 I don't understand what's stopping you from doing that. There are many perfectly fine jQuery/Backbone/Angular/etc apps that are chugging along perfectly fine. There's no reason for you to adopt new technology unless it makes your life easier. And therein lies the problem…

> due to efforts of people who love the language Extremely tangential, but does anybody actually love javascript? We've been in a captive situation with this deeply flawed hack for 20 years. Once WebAssembly is mature enough to fulfill its promise, and after that once we've burned through the generation born into this JS captivity, is anyone going to want use it anymore? Like, if it were magically possible to use any…

I've been more curious if anybody actually loves Java. Ok Java 8 seems to be fine but do people really love it? And did they also love Java 7?

Re: The state of JavaScript modules

#103

Post by omginternets »

jessaustin wrote: post #99
omginternets wrote: post #90

Earlier quoted context omitted.

That was true years ago. It's really not the case anymore. Related reading: https://glyph.twistedmatrix.com/2016/08/python-packaging.htm... More to the point, even if what you said were true, the tooling is still absurdly complicated in the JS world. Your comment is a mix of of a red herring and whataboutism.

Thanks, I read that last year. This seems telling: There should be tools that help you write and update a setup.py. In my experience, this was always the hardest part. I started using python in 1999, and I never really had any problems setting up dev environments or doing any of the other things that Glyph discusses at length at that link. As I said above, distribution is the difficulty. The javascript "complications…

>If comparing the pros and cons of two languages in response to another such comparison is "whataboutism", then I have no fucking idea what that term means.

The issue at hand is not whether Python is superior to JS. Rather, we're talking about a specific problem in the JS world -- the apparent need for tooling and its so-called "dependency hell".

Bringing deployment into the conversation is whataboutism.

Re: The state of JavaScript modules

#104

Post by elliotec »

marklgr wrote: post #7
elliotec wrote: post #3

Earlier quoted context omitted.

You can't vote posts down on HN. If it has low votes it just means people aren't interested enough to vote up.

There are downvotes on HN, you just need to reach some karma (500 if I'm correct) before being able to do so.

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.

Re: The state of JavaScript modules

#106

Post by bcherny »

hdhzy wrote: post #77
bcherny wrote: post #76

Earlier quoted context omitted.

Again, maybe a concrete example would help?

Import/export statements vs require() calls? const x = require; const m = x('crypto'); Here I'm requiring a module but it's hard to follow for a tool that Crypto is being imported. The proliferation of class systems in JS before ES6 classes. Building a tool (IDE for example) to support all of them would be a complex problem. See also interviews with Anders Hejlsberg (e.g. [0]) where he explicitly mentions that TypeSc…

Not sure I see what you're saying.

Requires are impossible to statically analyze in some pathological cases, which is why more rigidly defined imports made it into the ES2015 spec.

That's totally unrelated to classes vs. functions or any of the other things you've mentioned.

Post reply on HN