6 ms·

A JavaScript Module Manager That Fits in a Tweet

40 points by hk__2 11y ago

bigethan 11y ago
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 11y ago
  "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__ 11y ago
    Really? I like the ternary operator more than if, but only because if is a statement in JavaScript.
    - 91bananas 11y ago
      https://github.com/mbostock/d3/blob/master/src/selection/html.js https://github.com/mbostock/d3/blob/master/src/selection/htm... I had to look this over the other day, I found it nearly unreadable.
      - Stratoscope 11y ago
        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 11y ago
        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!?
- neogodless 11y ago
  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 http://www.joelonsoftware.com/articles/fog0000000069.html
endemic 11y ago
Made me think of https://github.com/testdouble/defuse https://github.com/testdouble/defuse.
mckoss 11y ago
Similar to a namespace package I've been using for 6 years. https://github.com/mckoss/namespace https://github.com/mckoss/namespace
cj 11y ago
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.
EdSharkey 11y ago
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.
iamleppert 11y ago
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!

40 points by hk__2 11y ago

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 11y ago
"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__ 11y ago
  Really? I like the ternary operator more than if, but only because if is a statement in JavaScript.
  - 91bananas 11y ago
    https://github.com/mbostock/d3/blob/master/src/selection/html.js https://github.com/mbostock/d3/blob/master/src/selection/htm... I had to look this over the other day, I found it nearly unreadable.
    - Stratoscope 11y ago
      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 11y ago
        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!?
neogodless 11y ago
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 http://www.joelonsoftware.com/articles/fog0000000069.html

endemic 11y ago

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

mckoss 11y ago

Similar to a namespace package I've been using for 6 years. https://github.com/mckoss/namespace https://github.com/mckoss/namespace

cj 11y ago

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.

EdSharkey 11y ago

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.

iamleppert 11y ago

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!