The state of JavaScript modules

Post by nilliams » Mon, May 29, 2017, 11:06 AM UTC

aaron-lebo wrote: post #63

SquareWheel wrote: post #61

Earlier quoted context omitted.

I know you're trying to be helpful, but I'd like to make clear that if you're a noobie, you don't need any of these tools. Plain Javascript is just fine, especially with the improvements of ES6. Tools are here to solve problems. Don't bother with them until you have that problem yourself. If you one day decide you want to set up things like auto-minification, image compression, CSS-preprocessing, then look into build…

You don't need any of those if you are doing a node project, yeah, but if you want to do any work on the browser, you're gonna need to transpile anyway, so it's something people should be aware of. Plus it's literally a 20 line config file to do so. module.exports = { entry: './src/app.js', output: { path: './bin', filename: 'app.bundle.js', }, module: { loaders: [{ test: /\.js$/, exclude: /node_modules/, loader: 'ba…

Post by eloisant » Mon, May 29, 2017, 11:17 AM UTC

bshimmin wrote: post #40

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

Post by andreareina » Mon, May 29, 2017, 11:21 AM UTC

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)

Post by hdhzy » Mon, May 29, 2017, 11:42 AM UTC

bcherny wrote: post #76

hdhzy wrote: post #70

Earlier quoted context omitted.

I meant higher level constructs. Classes are just an example. Even in Haskell you have typeclasses and modules. The point is that even though in JavaScript (and other Turing complete languages) you can emulate anything with what is available (for JS that is functions) you cannot easily build tooling around your ad hoc constructs.

Again, maybe a concrete example would help?

  const x = require;
  const m = x('crypto');

Post by pas » Mon, May 29, 2017, 12:20 PM UTC

coldtea wrote: post #47

pas wrote: post #42

Earlier quoted context omitted.

JS is backward compatible. So it got that too from Java other than the funky name. So it's stable. jQuery? Works. Good old document.getElementById? Works. And thanks to the standardization efforts of vendors (and countless volunteers, who created feature matrices and feature tests and polyfills, and so on), now using those is easy, because you can look up what's supported, what will be supported, and what is deprecat…

> JS is backward compatible. So it got that too from Java other than the funky name. You mean forward compatible. Which is unlike in Java. New code (e.g. with ES6 features) doesn't work in older JS engines / browsers -- that's why we have transpilers.