After this, we changed the name of 6to5 to Babel, to remove the ES6 to 5 connotation, and made ourselves future proof. The general platform concept manifested in the release of Babel 6, which moved out all of the core transforms and made it a general-purpose JS compiler.
-
Show this thread
-
This was only supposed to be the beginning of my vision though. I released Babel 6 live on stage at "EmberCamp London 2015", where in the closing slides, I spoke of my excitement for new tools to be built on top of Babel, including a linter, autoformatter, minifier and more.pic.twitter.com/g182MLst0s
1 reply 0 retweets 20 likesShow this thread -
After Babel 6, I eventually left the project due to mental health reasons and never really got involved again. Since then I've been experimenting with a lot of these ideas and have arrived at some conclusions.
1 reply 1 retweet 24 likesShow this thread -
The idea of these tools being built on top of Babel isn't very sound. An ad-hoc collection of tools is a fragile ecosystem. Atomic releases of all the tools to support new syntax, behaviour, configuration, and more is extremely difficult.
1 reply 0 retweets 22 likesShow this thread -
Today's JavaScript programs uses several different parsers spread across the engines the code is executing in, all the way to the linters, compilers, bundlers and more that are a part of the development process.
1 reply 0 retweets 14 likesShow this thread -
Consolidation of parsers isn't very interesting though. Sure we can all share the same AST, and syntax support, but that doesn't give us any new capabilities. What I'm excited about are things like:
1 reply 1 retweet 13 likesShow this thread -
- a testing framework that uses the same bundler for your test files as the one in production - a linter built on top of compiler so you can do complex AST autofixes - a single config file - a bundler that understands how dependencies are used, and optimizes your bundle
2 replies 1 retweet 53 likesShow this thread -
- a minifier that does constant folding and inlining - a compiler transforms that don't rely on order - a compiler that uses an immutable AST to perform transforms, with accurate scope tracking - a linter that gives me suggestions on how to fix my code - ...
2 replies 2 retweets 35 likesShow this thread -
What possibilities are you excited about?
10 replies 0 retweets 15 likesShow this thread -
Replying to @sebmck
entire babel/webpack stack ported to c++. so many people would pay for this.
2 replies 0 retweets 6 likes
What if a JS tool was fast enough?
-
-
Replying to @sebmck
these types of tools are never fast enough! and js will always be noticeably slower than a compile-to-native non-gc language
2 replies 0 retweets 5 likes -
Replying to @floydophone @sebmck
The language isn’t really the bottleneck for these tools. It’s almost always the algorithms. Also, in a JS worker model you can disable the GC and revert to arena allocation if you don’t like GC pauses.
1 reply 0 retweets 1 like - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
he/him 