
Bublé: a fast, batteries-included ES2015 transpiler - gedy
https://buble.surge.sh/guide/
======
cprecioso
I've already used this for a couple of projects, and works exactly like
advertised: blazing fast. Also, it's from the guy behind Rollup, Ractive,
Gobble, all tools that I use and love.

~~~
yamafaktory
I've just created a starter project to provide a simple boilerplate to get
started with React bundled as an ES2015 module via Rollup, compiled by Bublé
[https://github.com/yamafaktory/buble-react-rollup-
starter](https://github.com/yamafaktory/buble-react-rollup-starter) .So far so
good!

------
pgz
_> Rather than manipulating the AST, Bublé manipulates the source code
directly, using the AST as a guide – so there's no costly code generation step
at the end._

Is that really good idea when looking at the possibility of introducing bugs
in the transpiler?

~~~
rich_harris
> Is that really good idea when looking at the possibility of introducing bugs
> in the transpiler?

That's what a test suite is for :)

~~~
aspiringuser
Surely the AST is still produced? Acorn is the parser I assume?

~~~
rich_harris
Correct – Acorn is a truly wonderful library

~~~
Touche
Hey Rich, I wish some time you would write more about magic-string and what
makes it special. You say "no costly code generation step", but what makes
codegen costly compared to what you're doing in magic-string?

~~~
rich_harris
I plan to write about this in the near future (in fact I'm writing slides for
a talk on it this week) – essentially, codegen is more costly because a) you
have to generate the entire program, rather than just modifying the nodes that
have changed, b) your code generator needs to know about every single node
type, and c) you have to keep track of state (e.g indentation levels).

------
moretti
[https://twitter.com/domenic/status/721796970197684224](https://twitter.com/domenic/status/721796970197684224)

~~~
dchest
"Bublé is so funny. Remember Babel started out as "Traceur output is too
complex!" Over time they learned that being spec-compliant matters." — Domenic
Denicola (@dominic, Editor of the @htmlstandard and @streamstandard. Works on
@googlechrome.)

~~~
sp332
(Continued) "Now the cycle begins anew, with a "lightweight" ES transpiler
that generates output with oversimplified, wrong semantics."

~~~
Dylan16807
That seems like a biased description. Being lightweight doesn't seem to be a
goal. The goal is having a very clear function with no configuration, and
being simpler is just for brownie points.

------
oelmekki
I don't see any mention about async functions, are they supported? It's the
single most important reason why I prefer to go with transpiling from es7
rather than es6.

Or maybe it's now part of ES2016? I get quite lost in those sliding
features...

~~~
liadmat
I don't think async is currently in the official spec. Last time I checked it
was stage 3.

~~~
exception_e
I didn't know it was still in progress... really hope async/await makes it in.
I'm betting on that pattern to make JavaScript much more pleasant to write!

~~~
tracker1
It'll probably make it into ES2017, given that Edge, Chrome and maybe FF will
have it in their browsers by the end of next year, official spec or not. It's
a popular feature, and with Promises and generators in place, easy enough to
support.

It really does cleanup a lot of code, but getting people to understand that an
Async function returns a promise isn't always the easiest thing to convey
until after it's been used. I resisted Promises for a while, once it became a
part of ES6, and with async/await in Babel, I started using it... the cleaner
code is worth the minor bit of overhead.

------
bsimpson
Honestly, why invest time re-writing an ES2015 transpiler? Hasn't this area
already been sufficiently covered by existing tools (especially since the
author explicitly "limits [Buble} to ES2015")?

~~~
rich_harris
Because it's many times faster (~4x faster with small files, ~20x faster with
large files), very easy to set up, and tiny (which has a significant impact on
CI – it's very quick to install). It also generates leaner code, and doesn't
rewrite the parts that don't need to be transpiled, so your style/formatting
is preserved. We need to update the docs – it actually supports ES2016 (only
one new language feature – the exponentiation operator) and may support JSX in
future.

~~~
bcherny
How does it compare to the Typescript transpiler? Do you have benchmarks
somewhere?

~~~
rich_harris
Not yet, though I agree that would be worthwhile

~~~
bcherny
If your selling point is speed, I agree that a benchmark would be worthwhile..

~~~
akras14
Compared to Babel, which he clearly had a benchmark for. No need to get toxic.

------
tjelen
This look really great, thanks! Any ideas how to connect it with JSX code? Is
it possible to use it with the JSXTransform from React v0.13 or is there any
other alternative (and preferably lightweight) JSX transformer that is not
Babel?

~~~
rich_harris
There's an issue open for JSX: [https://gitlab.com/Rich-
Harris/buble/issues/26](https://gitlab.com/Rich-Harris/buble/issues/26). The
short answer is it's definitely on the TODO list, either as a separate
preprocessing step that uses the same techniques (buble-jsx), or in the tool
itself. Just haven't got round to it yet :)

~~~
aspiringuser
I continue to use babel 5.x which is much easier to use than babel 6.x which
cannot be globally installed. Babel 5.x supports jsx by default. Would be
great if buble would have feature parity with babel 5.x to ease the switch
over.

------
thejaredhooper
Can someone explain to me the use of a transpiler like this? I'm a novice and
I can't think of any personal use cases

~~~
nothrabannosir
you mean transpilers like this, and Babel, in general?

You want to write ES6 code today, but your clients (= browsers) don't support
it yet. So you use the transpiler: write ES6, compile to ES5, serve that.

It's the opposite of what Python did with the 2to3 tool, where you wrote
Python 2, and converted it to Python 3 before running.

Why do you want to write ES6? Well, hopefully, every change ES6 introduces to
ES5 is an improvement. I'd hope. So every different thing between them, you'd
want to use, sort of by definition. That's the idea, at least :)

~~~
tracker1
For me, the biggest changes are the syntax sugar... rest, spread, fat-arrow
syntax, destructured assignment, etc. The vnext bits I'm most using are
async/await, and some of the class/property extensions, and more
rest/spread/destructuring extensions. A lot of the other stuff is of less
interest to me in writing code, but I can see how they would appeal to others.

Not every piece has to be useful to everyone.

------
exception_e
Really cool project. I haven't had the opportunity to use things like Buble or
Babel on a project yet but would certainly like to.

I don't quite follow why plugins are discouraged in your FAQ section. I was
looking at this Gulp plugin (it's very new, but looks straightforward/is
idiomatic gulp): [https://github.com/TrySound/gulp-
buble](https://github.com/TrySound/gulp-buble) \-- I'm not following why that
would be an anti-pattern.

~~~
rich_harris
Ah, I should clarify the readme. What that refers to is plugins that add
additional functionality to Bublé, such as compiling features that aren't yet
in the spec (class decorators and so on). Plugins like gulp-buble, which allow
other tools to work smoothly with Bublé, are warmly encouraged!

------
spraak
The in -> out example for Classes (transforms.classes) helps me understand how
ES6 classes work, as I was really confused

I'm still unsure what they offer over a simple object with property key
values.

~~~
girvo
> _I 'm still unsure what they offer over a simple object with property key
> values._

They offer a particular abstraction, that gives a certain automatic conceptual
clarity for free. Personally, I'm a massive fan of prototype-based object
systems, but having the class syntax sugar on top of it has made certain
patterns clearer to express even if it's semantically equivalent.

My main issue with ES2015 classes, is that I've seen some projects use it for
everything including things that it's really not required for; really putting
the _Java_ back in Javascript, so to speak. But that can be said for a lot of
language features, really.

------
aspiringuser
rich_harris Yet another great project. Thanks.

Question - how to have buble accept input from stdin and output to stdout?
This is useful for quick ES6 tests and chaining piped output.

buble with no args prints help. Would be more useful if it just started
parsing code from stdin as babel 5.x did.

~~~
rich_harris
Thanks! It does accept input from stdin and direct to stdout if you do e.g.

    
    
        cat somefile.js | buble
    

– can you explain in more detail what you mean? (Or better yet raise an issue
:)

~~~
aspiringuser
`cat | buble` did the trick! Thanks.

------
lowboy
Hey Rich, Bublé looks interesting! Ever going to move onto ES2016/17/etc
features? Can't imagine myself just being satisfied with ES2015 for years to
come.

~~~
rich_harris
ES2016 is already supported, in fact – it only adds one new language feature,
the exponentiation operator. (It also adds Array.prototype.includes, but
that's an environment feature rather than a language feature, i.e. it needs to
be supported via a polyfill rather than a transpiler).

The idea is for Bublé to eventually become irrelevant (planned obsolescence) –
but as new language features do arrive it will be fairly straightforward to
add them. I'm just not sure if there'll be that many more language features
after ES2017, at least of the transpilable sort – I'd be surprised if we ever
have another big bang like ES2015 was.

~~~
tracker1
generators and async/await are pretty big pieces missing for me... can't speak
for others. And generators are mostly as a path to async/await for me.

~~~
rich_harris
Cool features, but they don't transpile very well (the output is much larger
than the input), and require a non-trivial runtime component. Unless you're
aware of the tradeoffs and have determined that the cost to your users is
genuinely worth the nicer coding experience, I'd argue that it qualifies as a
footgun.

Having said that, I'm very interested in seeing where
[https://github.com/marten-de-vries/kneden](https://github.com/marten-de-
vries/kneden) goes.

~~~
tracker1
I absolutely understand that the transpile is kind of weird and requires
tooling... the regenerator output isn't too hard to follow, but probably the
farthest from the input.

All of that said, I think it's definitely worth it, and the extra size is less
of a difference for larger projects. For server-side code, the size is less of
a difference since it isn't downloaded, and the performance impact has been
negligible in terms of noticeable, real-world performance.

Of coure by the end of 2017 I expect most browsers to have implemented
async/await natively... so by 2019 won't be an issue... that said, it's still
2016, so I'll keep using Babel.

~~~
rich_harris
That's a good point regarding server-side code

------
SimeVidas
Wait, doesn’t Babel provide a zero-configuration setup for ES 2015-to-ES5
transpilation?

~~~
Touche
No, Babel does nothing by default.

~~~
SimeVidas
Yes, Babel by default does nothing, but I meant, does it not have a quick
route to ES 2015-to-ES5 transpilation without having to perform the standard
installation and setup procedure? (I’m asking from the perspective of someone
who hasn’t started using Babel yet.) Something like “install this one thing
and you’re done”?

------
smithkl42
Interesting, but not sure why you'd ever use this instead of TypeScript. TS
has most everything this has - including real ease-of-use compared to Babel -
plus a lot of additional stuff that's critical for large code bases. And its
semantics are very clearly defined.

~~~
cdata
I love TypeScript, but one thing that I find increasingly irksome is the
phenomenon of TypeScript advocates who present a dismissive attitude towards
workflows that don't include TypeScript.

Why would I ever use this instead of TypeScript? A totally reasonable answer
to this question is that I don't want my JavaScript sources to require
transpilation before they will run in a modern browser.

~~~
rich_harris
> I don't want my JavaScript sources to require transpilation before they will
> run in a modern browser.

Exactly this. Bublé is designed to become increasingly redundant as node and
browsers progress, until one day you can just remove it from your stack
altogether. Planned obsolescence is an underrated feature in software

~~~
smrtinsert
I think you mean
[https://en.wikipedia.org/wiki/Forward_compatibility](https://en.wikipedia.org/wiki/Forward_compatibility)
and not
[https://en.wikipedia.org/wiki/Planned_obsolescence](https://en.wikipedia.org/wiki/Planned_obsolescence).

~~~
rich_harris
Actually now that I read both definitions, neither is quite right. Perhaps a
better metaphor would be dissolvable stitches – you need them when your wound
is open, but once it heals the stitches vanish.

If anyone can help me out with a less gross version of the same metaphor I'd
be grateful!

------
alfanick
i was hoping to see something compiling ES to native code, not another
transpiler...

~~~
phpnode
Here's something a bit like that, it turns TypeScript into JS, WASM and C,
very early but interesting -
[https://github.com/evanw/thinscript](https://github.com/evanw/thinscript)

~~~
phpnode
Replying to myself because it is too late to edit: thinscript isn't exactly
typescript, it has some extra features and doesn't attempt full js
compatibility, but they are very similar.

------
rashthedude
not yet another transpiler/compiler for Js

------
rajington
My main complaint with bublé is that it wasn't called babybel.

~~~
rajington
in all seriousness though, if I rely on async/await is kneden/nodent the way
to go?

~~~
dumbmatter
kneden is cool, but fairly buggy still. I wouldn't recommend it unless you
just want to play around with it and possibly work on making it less buggy.

I believe most people use Babel to compile async/await to generators.

