A JavaScript Module Manager That Fits in a Tweet | Hacker News Reader

A JavaScript Module Manager That Fits in a Tweet

bfontaine.net

40 pointshk__212 comments

The magic with these module systems isn't in the namespacing, that's just formalizing new scope creation via IIFE's and "exporting" symbols from that new scope to a variable on the outer scope. Big whoop; make an IIFE and return something from the function, there's your "export". Code golfing your module spec implementation is a fun exercise, though, I don't begrudge anyone for having fun.

No, the magic in JavaScript land right now is being able to take the CommonJS, AMD, or ES6 module spec and have that be the basis for JavaScript _bundling_ and _source code transformation_. Systems like Webpack and Browserify can perform these important functions. The magic is the plugin ecosystems that assemble around your modules to form your software project's build, test, and runtime systems.

The magic is that your JavaScript modules can be isomorphic and bundled to be delivered to and run identically on the web browser just the same as it can run on a Node.JS container. The magic is that IDE's now can grok these module specs and construct a type library - essentially treating the loosey goosey JavaScript language like it had static types. Employing JSDoc comments across your entire codebase is how you give hints to the IDE about parameter types, what can be nullable or optional, etc. You can essentially rig up a statically typed language out of modules and JSDoc comments in modern IDE's like IntelliJ/WebStorm.

JavaScript ES3/ES5 is a crappy toy language, ES6/ES2015 is somewhat less crappy, but still backwards crappatible. It's these modern tools and libraries that all agree on what constitutes a module that make JavaScript a joy to work with and very, very productive.

I appreciated the minification walk-through more than actually having a tweet solid package manager. Before you get to the range of code golf, less code means less bugs.

"less code means less bugs"

That really depends on how you make less code. Transforming an if condition in a ternary operator could make the code much harder maintain, therefore bring more bugs. This is one example from several cases.

Sometimes a longer code means a code more readable.

Really?

I like the ternary operator more than if, but only because if is a statement in JavaScript.

https://github.com/mbostock/d3/blob/master/src/selection/htm... I had to look this over the other day, I found it nearly unreadable.

The problem with that code is partly the overuse of the ternary operator, but even more it's the wildly inappropriate code formatting and structure. Code that looks like this would be a WTF no matter what operators or statements it uses.

Judicious, simple, and straightforward use of the ternary operator looks nothing like that.

The craziest part to me is if you look at the history of that file, that is the ONLY commit on that file ever. How does one write that the first time, and never have to touch it again!?

I think you can likely argue writing less code means creating fewer bugs. But there are a billion counterexamples where more code accounts for more conditions, and thus means less remaining bugs.

This is a great read on why that's the case: http://www.joelonsoftware.com/articles/fog0000000069.html

Similar to this 22 line require.js replacement: https://gist.github.com/paton/ab27a1be7e843d220ee3

We use this in our production apps.

Similar to a namespace package I've been using for 6 years.

https://github.com/mckoss/namespace

Made me think of https://github.com/testdouble/defuse.

you know what else is a good package manager?

var object = { thing: {}, otherthing: function() { console.log("I need", this.thing): } };

Just minify all your code into one file people!

Reply on news.ycombinator.com