
A JavaScript Module Manager That Fits in a Tweet - hk__2
http://bfontaine.net/blog/2015/10/29/a-javascript-modules-manager-that-fits-in-a-tweet/
======
EdSharkey
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.

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

~~~
louhike
"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.

~~~
k__
Really?

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

~~~
91bananas
[https://github.com/mbostock/d3/blob/master/src/selection/htm...](https://github.com/mbostock/d3/blob/master/src/selection/html.js)
I had to look this over the other day, I found it nearly unreadable.

~~~
Stratoscope
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.

~~~
91bananas
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!?

------
cj
Similar to this 22 line require.js replacement:
[https://gist.github.com/paton/ab27a1be7e843d220ee3](https://gist.github.com/paton/ab27a1be7e843d220ee3)

We use this in our production apps.

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

[https://github.com/mckoss/namespace](https://github.com/mckoss/namespace)

------
endemic
Made me think of
[https://github.com/testdouble/defuse](https://github.com/testdouble/defuse).

------
iamleppert
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!

