HN Explorer

19 comments

[ 3.0 ms ] story [ 54.2 ms ] thread
sebastianmck
I'm the creator of 6to5, awesome work! Let me know if you have any concerns/issues at all https://github.com/6to5/6to5/issues
[dead] mentaat
what is the difference between this and google's traceur?
illicium
I was hesitant to use ES6 because of how terrible Traceur's output is, but 6to5 looks really nice!
gianlucaguarini
thanks without you this project would neither exist. At moment I didn't find any issue with 6to5 but if I'll do of course I will let you know. Btw feel free to do the same on my project.
bpicolo
jsbeautify and jshint configs seem to disagree on number of spaces.
illicium
The module system shimming is kind of roundabout. 6to5 generates CommonJS, RequireJS converts CommonJS to AMD, and AMDclean converts that to "regular" JS.

RequireJS is really only good for AMD, but since AMD is rightfully dying in favor of CommonJS, I would use Webpack instead. There is some overhead compared to the AMDclean-ed version since it shims require(), though.

lobster_johnson
Yes, I don't see the point of using RequireJS/AMD these days. We use Browserify, which is excellent, and allows you to partition your code into any number of bundles as required; it's a great match for ES6 modules. I hear Webpack is pretty good, too.
wldcordeiro
Browserify gets my vote as well. I'm using it in a project currently and barely learned how to use it when I was starting the project. It's got clear documentation and works very well.
rich_harris
There's also Esperanto (http://www.rich-harris.co.uk/esperanto/ - disclaimer, I wrote it). It supports bundling and one-to-one transformations, and the bundled output is even slimmer than AMDClean
gianlucaguarini
I didn't know Esperanto.I will test it an if it produces a better output I'd be happy to replace requirejs + amdclean with it
gianlucaguarini
Thanks 4 your feedback, the reason why I am using the requrejs + amdclean is that the other tools I've found like browserify add extra code to keep using the require calls and I would like to avoid it. If there is a better solution I'd really appreciate a pull request
lobster_johnson
Browserify's "runtime" is about 440 bytes. For example, consider:

    // hello.js
    module.exports.hello = function() {
      console.log("hello");
    }

    // test.js
    var h = require('./hello');
    h.hello();
The result of browserifying this is:

    (function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);var f=new Error("Cannot find module '"+o+"'");throw f.code="MODULE_NOT_FOUND",f}var l=n[o]={exports:{}};t[o][0].call(l.exports,function(e){var n=t[o][1][e];return s(n?n:e)},l,l.exports,e,t,n,r)}return n[o].exports}var i=typeof require=="function"&&require;for(var o=0;o<r.length;o++)s(r[o]);return s})({1:[function(require,module,exports){
    module.exports.hello = function() {
      console.log("hello");
    }
    },{}],2:[function(require,module,exports){
    var h = require('./hello');
    h.hello();
    },{"./hello":1}]},{},[2]);
It's pretty damn compact. Sure, every module is wrapped with the signature "function(require, module, exports)", but a good minifier such as Google Closure will reduce that by a lot:

    (function e$$0(d,b,f){function g(c,e){if(!b[c]){if(!d[c]){var a="function"==typeof require&&require;if(!e&&a)return a(c,!0);if(h)return h(c,!0);a=Error("Cannot find module '"+c+"'");throw a.code="MODULE_NOT_FOUND",a;}a=b[c]={exports:{}};d[c][0].call(a.exports,function(a){var b=d[c][1][a];return g(b?b:a)},a,a.exports,e$$0,d,b,f)}return b[c].exports}for(var h="function"==typeof require&&require,e=0;e<f.length;e++)g(f[e]);return g})({1:[function(k,d,b){d.exports.hello=function(){console.log("hello")}},
    {}],2:[function(k,d,b){k("./hello").hello()},{"./hello":1}]},{},[2]);
I don't see what you win by going with RequireJS/AMD.
gianlucaguarini
My es6 project starter kit works in any kind of environment without damaging anyone: it provides also the dist/cmj folder for the browserify users or whatever other tool you use to load commonjs code. The reason why I don't want to compile directly using browserify is that its require shim even if it's small, it will be then included in any single script you are going to use in your app, imagine the following use case: in your app you want to use a.js build with browserify and b.js build with it as well. Now including a.js and b.js in your page you will have 2 times the browserify shim (btw it could be also different depending on the browserify version you have used to compile). But if I provide a distribution folder containing the script cleaned up (without extra code) and the commonjs version of it's a win for everyone.
joesmo
So what exactly does this do? It's rather unclear.
gianlucaguarini
It lets you write javascript using the brand new ES6 syntax (not yet supported by any browser) publishing code runnable on any modern browser/nodejs
[deleted]
(comment deleted)
markuz
why not gulp ?
gianlucaguarini
Good point..well I have used gulp on a couple of projects and in the end I understood that I was working more on the gulp tasks than on project code itself. I think gulp is a great tool but it simply doesn't fit my needs I don't like wasting time including several gulp dependencies for things that I could do with 3 lines of config file in grunt