5 ms·

> "dependencies": { > "babel-preset-stage-0": "6.5.0", > "babel-preset-es2015": "6.6.0", > "babel-runtime": "6.6.1", > "babel-plug

> "dependencies": { > "babel-preset-stage-0": "6.5.0", > "babel-preset-es2015": "6.6.0", > "babel-runtime": "6.6.1", > "babel-plugin-transform-runtime": "6.6.0", > "babel-cli": "6.6.5", > "babel-core": "6.7.4", > "twit": "2.2.3", > "entities": "1.1.1" > }, The problem right here. Just to run a script you now need to import a whole third party language runtime ? what other language does pull this kind of stunt ? Javascript is madness.

BinaryIdiot 11y ago
Most of that is so people can use the slightly nicer syntax of the newer version of JavaScript in a more supported way as it's transpired. Honestly I'm not a fan because, as you can see, it's a big ass bucket of extra complexity for some extra, albeit nice, syntax updates. I'm waiting for wide support of ECMAScript 6 before I start using it widely. Though I feel I'm a bit in the minority here I just don't want to deal with all of the transpiling complexities if I don't need to.
- abecedarius 11y ago
  I've started using ES6 sans 'transpiler' for web development on Chrome. There's still the build step for release to other browsers, but so far I haven't bothered. (I think your decision is completely reasonable; only pointing out that since just this month, with Chrome 49 out, you can develop without any build step.)
  - david-given 11y ago
    Yup. I'm working on a Polymer project in ES6. I develop in Chrome with it pointing directly at my source, so I get a full debugger and quick reloads by hitting the F5 button. Then I use crisper/babel/vulcanise via a ninja build script to generate an ES5 deployment package for the other browsers. It works really well. (ES6 is so, so much nicer than ES5. It's almost like a real language now!)
    - voltagex_ 11y ago
      Is there anything you can share of that ninja script? I've been looking at it as a replacement for environments where grunt doesn't work too well.
      - david-given 11y ago
        Sure --- it's a mess, though. https://github.com/davidgiven/gruntle/blob/gruntle/build.ninja https://github.com/davidgiven/gruntle/blob/gruntle/build.nin... https://github.com/davidgiven/gruntle/blob/gruntle/build https://github.com/davidgiven/gruntle/blob/gruntle/build build is a tiny Lua preprocessor which expands templates in build.ninja. It needs a cleanup but it works, it's way faster than gulp, and is much easier to debug. Haven't touched grunt so I don't know how it compares there.
        voltagex_ 11y ago
        Thanks. Could I get away without the Lua?
        david-given 11y ago
        Yes, but you'd need to expand the source file rules inline --- I added the Lua because I was fed up with doing it by hand. (Ninja doesn't have implicit rules.)
  - deleted 11y ago
    [deleted]
  - bzbarsky 11y ago
    Note that other browsers (specifically Firefox and Edge) generally have better ES6 support than Chrome does, so a "build step" is not needed for them unless you happen to be using one of the very few things that Chrome supports and they do not.
dc2 11y ago
Not really. Usually people include them as "devDependencies", and Babel will transpile to ES5 before publishing. I think Guillermo simply didn't care. Because it's not important for a joke. --- Uninformed presumptions are madness.
- rubber_duck 11y ago
  Umm isn't babel-runtime an actual third party language runtime dependency (like polyfills and shared code for stuff like async) ?
  - shaunol 11y ago
    Indeed, it is the only post-build babel dependency required if you want things like you say: async/await. The rest are the babel dependencies are build tools.
  - j_jochem 11y ago
    I wouldn't really call it a dependency since it gets inlined with the shipped code.
- m_mueller 11y ago
  I think it was important to him since otherwise leftPad probably wouldn't fit in a tweet so nicely..
mbrock 11y ago
Babel is run on the tweet, presumably to allow more terse code and thus more useful 140 character libraries.
rat87 11y ago
clojure? I think the language is one just another jar to install. Makes it easier to pin stuff to the language version.
sebak 11y ago
Javascript is in fact special because it's one of the few languages where the developer can't choose the version of the language to use. It's dictated by users with 4 year old browsers.
- Jack5500 11y ago
  Execpt for server-side languages that's nearly always the case
  - kuschku 11y ago
    Where? Java has such short maintainable cycles that Java 7 was dropped before Java 8 became used, and compiled languages (think C, C++, Haskell) always work. Are there any other languages relevant for non-server usage?
  - donatj 11y ago
    You can quite easily choose your version. There are virtual hosts out there supporting any version of anything. This problem is largely solved.
  - goldbrick 11y ago
    That's nearly never the case, unless you are running uncompiled scripts downloaded from the internet with no version manifest, in which case that's also horrible.
  - eridius 11y ago
    For scripting languages, sure. For compiled languages, you can choose whatever version you want, since the end user gets a binary blob instead of source code (and even if they're building from source, their package manager should be able to download the required build dependencies for them).
z3t4 11y ago
This is just to let non-JS programmers program JavaScript. Asynchronous programming, or programming without global/imports is too hard it seems.
euske 11y ago
I don't think it's the amount of code that is a problem here (we all depend on million lines of codes for a simple hello world program in C). The problem is the number of sources that one should trust to run it, which should be minimal.
kowdermeister 11y ago
It's part of the joke that makes this post funny.
goldbrick 11y ago
First of all, whoosh, and second, no other language has the same platform/delivery mechanism as web client javascript. Any "transpiled" language is going to have to include it's own dependencies somehow.
kin 11y ago
Well this is meant to be a bad example, really all the babel stuff would be dev dependencies and ideally you'd have some watch task to compile and auto-reload. In production you'd only have a bundled/minified version transpiled JS so there's no need for a runtime. Ultimately with web assembly this gets even better.

BinaryIdiot 11y ago

Most of that is so people can use the slightly nicer syntax of the newer version of JavaScript in a more supported way as it's transpired. Honestly I'm not a fan because, as you can see, it's a big ass bucket of extra complexity for some extra, albeit nice, syntax updates. I'm waiting for wide support of ECMAScript 6 before I start using it widely. Though I feel I'm a bit in the minority here I just don't want to deal with all of the transpiling complexities if I don't need to.

abecedarius 11y ago
I've started using ES6 sans 'transpiler' for web development on Chrome. There's still the build step for release to other browsers, but so far I haven't bothered. (I think your decision is completely reasonable; only pointing out that since just this month, with Chrome 49 out, you can develop without any build step.)
- david-given 11y ago
  Yup. I'm working on a Polymer project in ES6. I develop in Chrome with it pointing directly at my source, so I get a full debugger and quick reloads by hitting the F5 button. Then I use crisper/babel/vulcanise via a ninja build script to generate an ES5 deployment package for the other browsers. It works really well. (ES6 is so, so much nicer than ES5. It's almost like a real language now!)
  - voltagex_ 11y ago
    Is there anything you can share of that ninja script? I've been looking at it as a replacement for environments where grunt doesn't work too well.
    - david-given 11y ago
      Sure --- it's a mess, though. https://github.com/davidgiven/gruntle/blob/gruntle/build.ninja https://github.com/davidgiven/gruntle/blob/gruntle/build.nin... https://github.com/davidgiven/gruntle/blob/gruntle/build https://github.com/davidgiven/gruntle/blob/gruntle/build build is a tiny Lua preprocessor which expands templates in build.ninja. It needs a cleanup but it works, it's way faster than gulp, and is much easier to debug. Haven't touched grunt so I don't know how it compares there.
      - voltagex_ 11y ago
        Thanks. Could I get away without the Lua?
        david-given 11y ago
        Yes, but you'd need to expand the source file rules inline --- I added the Lua because I was fed up with doing it by hand. (Ninja doesn't have implicit rules.)
- deleted 11y ago
  [deleted]
- bzbarsky 11y ago
  Note that other browsers (specifically Firefox and Edge) generally have better ES6 support than Chrome does, so a "build step" is not needed for them unless you happen to be using one of the very few things that Chrome supports and they do not.

dc2 11y ago

Not really. Usually people include them as "devDependencies", and Babel will transpile to ES5 before publishing. I think Guillermo simply didn't care. Because it's not important for a joke. --- Uninformed presumptions are madness.

rubber_duck 11y ago
Umm isn't babel-runtime an actual third party language runtime dependency (like polyfills and shared code for stuff like async) ?
- shaunol 11y ago
  Indeed, it is the only post-build babel dependency required if you want things like you say: async/await. The rest are the babel dependencies are build tools.
- j_jochem 11y ago
  I wouldn't really call it a dependency since it gets inlined with the shipped code.
m_mueller 11y ago
I think it was important to him since otherwise leftPad probably wouldn't fit in a tweet so nicely..

mbrock 11y ago

Babel is run on the tweet, presumably to allow more terse code and thus more useful 140 character libraries.

rat87 11y ago

clojure? I think the language is one just another jar to install. Makes it easier to pin stuff to the language version.

sebak 11y ago

Javascript is in fact special because it's one of the few languages where the developer can't choose the version of the language to use. It's dictated by users with 4 year old browsers.

Jack5500 11y ago
Execpt for server-side languages that's nearly always the case
- kuschku 11y ago
  Where? Java has such short maintainable cycles that Java 7 was dropped before Java 8 became used, and compiled languages (think C, C++, Haskell) always work. Are there any other languages relevant for non-server usage?
- donatj 11y ago
  You can quite easily choose your version. There are virtual hosts out there supporting any version of anything. This problem is largely solved.
- goldbrick 11y ago
  That's nearly never the case, unless you are running uncompiled scripts downloaded from the internet with no version manifest, in which case that's also horrible.
- eridius 11y ago
  For scripting languages, sure. For compiled languages, you can choose whatever version you want, since the end user gets a binary blob instead of source code (and even if they're building from source, their package manager should be able to download the required build dependencies for them).

z3t4 11y ago

This is just to let non-JS programmers program JavaScript. Asynchronous programming, or programming without global/imports is too hard it seems.

euske 11y ago

I don't think it's the amount of code that is a problem here (we all depend on million lines of codes for a simple hello world program in C). The problem is the number of sources that one should trust to run it, which should be minimal.

kowdermeister 11y ago

It's part of the joke that makes this post funny.

goldbrick 11y ago

First of all, whoosh, and second, no other language has the same platform/delivery mechanism as web client javascript. Any "transpiled" language is going to have to include it's own dependencies somehow.

kin 11y ago

Well this is meant to be a bad example, really all the babel stuff would be dev dependencies and ideally you'd have some watch task to compile and auto-reload. In production you'd only have a bundled/minified version transpiled JS so there's no need for a runtime. Ultimately with web assembly this gets even better.