The state of JavaScript modules
medium.com
The state of JavaScript modules
1–10 of 106 posts
Re: The state of JavaScript modules
#2edit: not sure why people don't like amdefine
Paul Graham is wrong. Downvote discussion helps. Asking for feedback is something we want to encourage.
Re: The state of JavaScript modules
#3just 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.
Re: The state of JavaScript modules
#4just 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.
You can't vote posts down on HN. If it has low votes it just means people aren't interested enough to vote up.
Re: The state of JavaScript modules
#5just 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.
You can't vote posts down on HN. If it has low votes it just means people aren't interested enough to vote up.
Re: The state of JavaScript modules
#6Re: The state of JavaScript modules
#7just 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.
You can't vote posts down on HN. If it has low votes it just means people aren't interested enough to vote up.
Re: The state of JavaScript modules
#8As 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?
Re: The state of JavaScript modules
#9And 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.
Re: The state of JavaScript modules
#10just 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.
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]