I just want to say these people do amazing work. It's truly been a pleasure to work with JS in 2016. Thank you to everyone working on Babel and the countless other great OSS projects. One of my goals for 2017 is to find a way to get involved.
Author here, if anyone had questions or wanted to know more about how to help out!
Personally, I'm most excited about babel-preset-env, and fixing how we work with the TC39 process via experimental plugins, and working with the community more.
For anyone wanting to get started in OSS or Babel I just started a year ago from knowing nothing about it!
I second (third?) the fact that I'm so thankful for these packages and contributors. Reading this article puts into perspective the amount of alignment within the community that it takes to be able to depend on external libraries to make our day-to-day easier.
It's very humbling. I'm just here standing on the shoulders of giants.
Not only is Babel great as a tool for transpiling JavaScript, I've found the plugin system to be splendid for building a compile-to-JS language as well. The tools are terrific to work with.
Many of the great features of modern js (destructuring, fat arrows, splats) came directly from CoffeeScript. As much as I loved the comparative power of CoffeeScript (list comprehensions, everything is an expression), its time has past. There is very little active development and it has lost all momentum. It also never started addressing the biggest issue facing large JS projects, typing and static analysis. Refactoring a CS project is a fragile process that I won't miss.
Are you sure CoffeeScript has lost momentum? It now supports ES2015 imports and exports, and I've seen quite a bit of work on the 2.0 branch (and various forks where contributors are adding new work before merging back to 2.0) to add support for extending ES2015 classes. It looks like that PR will be merged soon.
Also, how much momentum does it need? The language is complete and usable as it is.
I write this as someone who does lots of professional work in ES2015, and very little in CoffeeScript. But every time I come across CoffeeScript in a project, I find myself admiring how nice it looks, and realizing how ugly ES2015 looks in comparison.
Fun fact: Javascript was originally intented to have scheme-inspired syntax, until Sun marketing team decided that it should have Java-like syntax (and name). Luckily the semantics survived. So in a sense CoffeeScript respects more the true origins of "javascript" with its everything-is-expression idiom.
Personally, my strongest dislike with ES6 is its afterthought C-like syntax from 40 years ago. Nowadays, hardware is fast enough so that we don't need redundant {()}; hints for quick parsing, instead we should focus on human readability.
I wish there was an editor plugin which enabled alternative syntax (without dividing the community). Syntax is really a reprentational layer thing, just like color theme, and should be personally customizable.
There are many differences. One is that CoffeeScript will always need to be compiled. Code written in, e.g. ES7, will not have to be compiled down with Babel anymore once browsers in the wild all support ES7.
Also, AFAIK CoffeeScript restricts you to using JS features found in ES5.
On the other hand, I think that the time of CoffeeScript has passed. It made some sense before Babel but now, IMHO, it is only for Ruby developers who don't like the syntax of JavaScript.
As a Ruby developer who doesn't like the syntax of JavaScript, Babel and ES6+ have changed my perspective. After the initial hurdle of figuring out what the hell webpack, babel, and npm (now yarn) were doing, I've found Javascript to be outright pleasant to use.
There was a recent Reddit thread entitled "Modern JS dev workflow makes me sad" ([0]). The complaint was reasonably well-written, and I wrote a lengthy response in return ([1]). I'll quote part of my comment here:
> Another thing to keep in mind is that those tools constitute an entire compiler toolchain. If I was trying to compile, say, a Qt application on a Linux system, half of the headers and libraries would have been preinstalled on the system, as well as GCC. The Qt develop package may or may not be preinstalled, but would also constitute a pretty hefty chunk of dependencies. With Javascript, you're basically pulling down an entire compiler+linker+libraries chain for each project, which is both good and bad.
I also gave a presentation a couple months ago that gives an overview of what some of these tools are and what problems they're trying to solve ([2]), and my React/Redux links list ([3]) has links to a number of other similar overview articles that can help clarify why these tools exist ([4]).
Thanks for the link to your presentation. Very interesting to see the history in one place. I'm not totally clear on the primary cause of the mess once we get to npm, bower, grunt, etc. Is the main issue the shortcomings of JS itself or something else..?
I'll go ahead and quote the most relevant slides from my presentation:
> Javascript/Client Challenges:
> - No built-in module definition system
> - No encapsulation
> - Prototypal-based inheritance system unlike most languages
> - No static type declarations or compilation
> - Dynamically modified objects and data
> - Minimal standard library
> - Variations in browser capabilities
> - Document layout model repurposed for application layouts
> Javascript/Client Dev Goals
> - Minimize bytes sent over the wire
> - Handle browser compatibility issues
> - Fill in gaps in JS standard library and language spec
> - Reuse and share code between apps
> - Build increasingly complex full-blown applications that just happen to live inside a browser
So, it's all those aspects together. People want to use the latest syntax, patch holes in the language, standardize behavior, share code, and run full-blown compilation pipelines that parse, transform, link, and optimize, and use all that to build complex applications. That's a completely different world than just using jQuery to toggle some divs.
In addition, these pieces have really only come together in the last 6 years or so. The C ecosystem has been around since the late 70s, Java is over 20 years old, and so on. Those ecosystems have had time to build out tools and conventions, and the underlying platforms have been more stable as well. In the front-end world, browsers and runtime capabilities are constantly changing, and as people are pushing the limits of the language and ecosystem, others are inspired by those ideas. So, there's a lot of catch-up and iteration going on.
I'm not going to say that it's easy to keep up with or that everything about these changes is perfect and wonderful. That said, I _do_ think that the rate of change is slowing down somewhat, and that the situation is stabilizing. I think the last year and a half of "Javascript Fatigue" complaints have also raised awareness of the churn, and that there's a big emphasis on improving developer experience going on right now. For example, the Webpack team has made a huge effort to rewrite their docs from scratch ([0]), and there's several utilities out there that try to make it easier to write Webpack configs without having to fiddle with every last option yourself ([1], [2]). There's also tools like Create-React-App ([3}), which try to encapsulate the entire build tool process for you ([4]).
So, yeah - everyone's still trying to sort things out a bit, but ultimately the tools and technologies now available are letting people do a lot of things they couldn't do before.
As a insider to FE development, I'm tired of hearing comments about JS fatigue and all the rest.
FE development is made of many moving parts and standards managed by different players. JS, for example, has to work on a variety of browsers, from obsolete to bleeding edge, from desktop to game consoles to mobile phones. Imagine if you had to write SQL that needs to run on ALL versions of ALL major databases, paired with code that needs to run on every possible JVM. It's unavoidable that it be like that. I'd rather have that than going back to the days of Flash where everything was closed source and in Macromedia's (or even worse, Adobe's) hands.
If it's not your thing, just keep clear of it (I don't mean OP specifically)
Because everything is open source and developed by different players at their own pace, and nobody can force anyone to do things a certain way. Plus everything evolves very quickly. Right now, for example, we need Babel because we are in the middle of transitioning from ES5 to ES6. Unlike, say, Python, we can't just take 6 years or more for that process.
I hear what you're saying kinda. It sort of comes with the territory since the web is a completely open platform, not a controlled/contained ecosystem like Java or even an open-source language like Python.
It wasn't directed specifically at you, it just read better than "if it's not ONE's thing, ..."
> Also, I didn't mention anything about fatigue. You're projecting that.
I didn't say you mentioned it. It is a common complaint and one I have seen far too often (here on HN a popular article on the subject was posted and reposted almost daily for a couple of weeks), so I made an observation which was spurred by your comment.
I imagine you would write the "lowest common denominator" SQL which run on all of the database. You can do that with JS too. But then you miss out on all the browsers latest APIs.
Indeed. `babel-preset-env` in particular looks pretty amazing. Just tell it what browsers you want to support and it'll automatically apply whatever transformations are needed to target those versions? Yes, please!
It's no worse than any other ecosystem. Modern Java development is just as prickly -- the only difference is the complexity is more established. JS is still very "wild-west" because the community is still making rapid progress towards an ideal environment.
You may be right, but I'm not sure I totally agree. Maybe this is exactly what you meant, but I think the complexities are different. Java is inherently complex, I'll give you that, but in JS and FE development in general, it seems like the most basic building blocks are constantly being reinvented...large, open questions on basic stuff.
I've commented on this subject before[0], I think the past few years of web development has largely been about answering basic questions. Now there are well tested answers to those questions. I'm sure people will still reinvent these wheels, but now you don't have to when working on a large project.
Babel, Webpack et al are more useful when you're building a web-app, something generally comparable to a native app. The toolchain is complex, sure, but no more complex than what xcode or Android Studio do for you. I think the difference is that this has been a community effort, rather than a corporation assembling a product, so a) there are more people sharing opinions and b) the disagreements and exploration has been more public.
The issues with FE are twofold: browser incompatibilities and user expectations. The first is becoming easier over time (stop using IE, please). The second is an ongoing arms race.
Writing front end code is like writing a CLI. It starts off really easy - you have a use case (whether that's a page about your cat or a script that echoes "meow"), you solve for it, you show it off.
But then people ask for it to do other things. So you have to extend the code - perhaps we need to add flags so users see dog stuff instead of cat stuff. Oh, now users want an actual ascii animal to see so we cater to that. Now they want to name it so let's accept input somehow. They want to issue commands to it so let's deal with parsing and conditional branches.
The problem is that we have to deal with constant changes from browsers, from stakeholders, and from users. Stakeholders want certain features from our programs, users expect a certain standard of performance, and browsers hamper us with incompatibilities.
So we build libraries that solve some of these problems. jQuery helped us build websites, but then web apps became a thing. Backbone/Ember/Angular helped us build web decent web-apps, but then performance became a thing. React/Angular2/Ember2/Vue help us build performant applications... until the next thing.
I think the real problem are the choices people opt-in to. I use React and don't have JavaScript fatigue - but I've also chosen not to use JSX, Babel, Webpack, SSR, live reloading, linting, typing, automated deployment, trello, TravisCI, Docker, k8s, etc. Just libraries imported with script tags, writing ES5 (current standard, 100% implementation), using React.createElement and I've had no issues.
People may opt-in to reinvention and questioning basics, but there are plenty of individuals that get by just fine.
I disagree that the constant churn in FE/JS is necessarily a sign of "rapid progress", rather than a lack of strong stewardship/leadership leading to people reinventing the wheel.
I haven't worked with Java for a long time, but from what I've been hearing from colleagues who are exploring writing production software with it, .NET Core is currently a bit of a mess, showing that even coherent dev stories can easily slip into disorder.
> I disagree that the constant churn in FE/JS is necessarily a sign of "rapid progress",
It's the field that is progressing rapidly. Browsers are constantly adding new APIs, problems are being solved, etc. The difference is that it's open source
> a lack of strong stewardship/leadership
You can't have leadership in a field which has no owner. It's not like Oracle owning Java and deciding what happens with it.
> people reinventing the wheel.
This is a stereotype by people who don't really know the subject. Every new tool improves on the previous one. For example, grunt was the first JS build tool, it had some issues (huge configurations, and speed) some someone invented gulp, which uses streams for speed and code instead of configuration. But streams don't handle splitting files in bundles and other problems so well, so webpack was invented. There are overlaps but they all solve different problems, and all improve on the previous generation. They are not "reinventing the wheel"
> a lack of strong stewardship/leadership leading to people reinventing the wheel
There's lots of strong leadership. React, Angular, Vue, Ember, etc. all have very intelligent, hard-working people backing them. These frameworks aren't "reinventing the wheel", it's the complete opposite: the community has finally freed itself of jQuery/global scope/imperative DOM and these frameworks are all pushing the border in one way or another.
In this case, the wheel started off with an impractical oval shape and the reinventions are usually making it rounder.
If you'd stopped the churn two years ago, people would be using Bower for front-end package management in addition to NPM, and Gulp or Grunt for task automation. Now a few churns later, NPM is the only package manager you need since you can use Webpack to automatically cut out your duplicated front-end packages. And now NPM provides all the task scripting most devs would need, so no more Gulp or Grunt.
Things are getting simpler and easier, but if you're looking from the outside you'll just see a long list of names of tools.
Look at the number of binding/UI frameworks, look at the package managers, look at the number of unit test libraries, look at the number of build tools. Many get reinvented in a bubble when there are plenty of options already.
Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript.
And then you have things like angular creating churn within the framework.
So the argument is essentially "there's a lot of stuff I don't really understand, a lot of it must be redundant"?
React isn't just Angular with a different name -- they have fundamentally different views on how web development should be done. They also fit different use cases (Angular is a one-stop-shop, React is minimalist by design). Same thing with the build systems. Add in the fact that a lot of this wasn't possible until recently (i.e. Webpack is fundamentally enabled by ES6-style imports) and of course things are going to change rapidly.
> Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript.
I'm not sure what you mean by this. Elm-html is the only example I can think of that is non-Javascript. If you're referring to Angular2 being Typescript you can still use it just fine with regular JS.
For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them.
But secondly, what makes them crappy? I've used make, and IMO it's pretty crappy itself. Have you had to maintain a recursive makefile? It's a complete nightmare to say the least. And i'm far from the only one to think make is worthy of a "remake". In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc...
If you run your same search in pip, or ruby gems, or composer, or cargo, or cpan, or any other package manager for any other language and i'm sure you'll see it's fair share of build tools, frameworks, libraries, and unmaintained stuff.
> For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them.
It's a problem because every time I need $tool I might have to evaluate dozens of choices, check for compatibility, investigate the ones that suit, hope to god the rest of the community is familiar with it, hope it is supported in future, etc. And then with the rate of churn you might have to do the same in a year. Make has been supported for 30 years, I know it's not going anywhere.
> In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc...
So there's already dozens of tools, why reinvent them in javascript? Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world.
Well you don't need to evaluate dozens of choices, a few at most. Hell if you just wanted to go by your search above 2 of the top 3 are the 2 biggest build systems in JavaScript (grunt and gulp), and the other isn't a build system.
Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". The more the merrier IMO, and if they are good then they will rise to the top over time. If you don't want to choose, just pick the most popular and deal with it, it'll feel the same as another platform where there's only one to choose from.
But you could also just use make, it's all about your needs. Do you want your project to still build in a few decades with very little change? Then choose the tools for that. You just making a pet project that just needs to live until the domain expires? Try out something new! Afraid of change? Stick with make!
>Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world.
For the most part JS has settled. When it comes to "stuff like make" it's basically gulp or grunt (or make and friends). Yeah there are other smaller players, but there's also a few dozen Java build tools that you've probably never heard of.
> Maybe it's me, but I've never looked at a list of tools and thought "this is too many!".
There is the problem of diffraction of efforts, and spreading knowledge too thin. You see some of the problems in the way linux distros do packaging - every major distro family has its own packaging system, born from NIH syndrome. The result is less portability of both packages and skills.
Some competition is good, but there is a point beyond which lots of choice becomes counter-productive. Troubleshooting also becomes harder when the various tool communities are smaller on average.
I disagree with that premise though. Just because I made a package that's in the same realm as make doesn't mean that I could have or would have contributed to make instead.
And there's something to be said about smaller single-purpose tools. Adding a ton of features to something like make to support every possible option isn't a good idea IMO. Sometimes a small opinionated package with a "correct" way to use it is best for some circumstances.
Regardless, I really think that the market will sort itself out. If it's oversaturated then some big players will rise to the top and the rest forgotten. Unlike a Linux distro package manager, anyone can add anything to NPM with zero oversight. It makes the "floor" of quality much lower, but fragmentation isn't that big of a deal as the effort to publish is so low.
See I looked at grunt and gulp and they both seemed lacking. Grunt doesn't seem to be a make clone at all, the getting started page only pays lip service to custom tasks. They both seem to require the tools you want to use to have plugins specifically for them. Neither seems to allow for variables from the command line.
When I last looked into it I gave jake a go, but then you run into problems where other random tools only have grunt/gulp plugins. The core tools of the ecosystem just seem to be picking all the wrong abstraction points.
Personally I ended up sticking with gulp, but writing a small helper that turns the tasks into command line commands (search up gulp-run-command and my username if you care to look, I really only published it for ease of use though so don't rely on it not changing), so it basically feels like an easier cross-platform make with a fancier dependency system.
99% of tools have a CLI and it's generally pretty damn good.
If you don't have many "tasks" or they are pretty simple, just use npm's built in "npm run scripts" which works fantastically for smaller projects IMO.
I agree though about the lack of ability to pass flags. I wanted something that lets me make command line commands as tasks, build a dependency tree ala gulp, and pass in optional flags to trip things like prod vs dev builds.
But at the end of the day getting make to cooperate on all platforms was a mess, and it sure as shit didn't scale well or do stuff in parallel at all. So a simple if somewhat inelegant gulp file seems the best bet for us.
(I imagine this is how new build systems are born!)
What about them? As a front-end develop I don't know or care about them until they solve a problem I have with the existing toolset. I couldn't care less whether there's one alternative to React/Angular or a thousand.
Java and C++ always end up as the baselines for comparisons, besides both not being exactly being the poster boys of their respective fields. Just because C++ compiles even slower or a non-standard Maven setup is more inscrutable doesn't exactly praise the alternative.
We should stop being so content with not being/using the worst.
This is a point that is brought up a lot, and I'm happy that our community is having these discussions, but I don't think that this is the best place to bring it up again. This post is intended to convey a lot of technical, inside information about this tool to people who are already using it. If you don't know where to begin with Babel, this is not a good resource.
Also, constant negative feedback discourages the creators and maintainers of projects like this from continuing to work on them:
To be fair that assumes you have node and npm set up properly, including making them upgradable, making sure node_modules is in PATH, etc. I think it's easy to forget "obvious" knowledge like this that (for me at least) had to be figured out with some trial and error.
But npm comes with node, so it's just installing the language at that point. And you don't need `node_modules` in the PATH, npm-run scripts will search the local node_modules first before hitting the path.
But I do agree with your point. The "bootstrapping" process of getting started in a new ecosystem is always extremely exhausting. When i was first learning python, it took me 2 solid weeks of an hour or so a night to build my first package. From getting the right version installed, having to eventually compile it myself, getting pip installed, accidentally using setuptools directly, learning about virtualenvironments, trashing everything and starting over with a venv, getting told by people on stack-overflow that I shouldn't try messing with packages at all as I don't need them and should just install from git, etc...
And just recently I did something similar while revisiting an older PHP codebase. I realized that just getting it in a position where I could run it on the dev machine meant installing a database, language, server, setting up a web root, a shitton of apache config files, and more just to get to a point where I could print hello-world.
That part always sucks, and to be completely honest node-js was the one that sucked the least to me when I first started in that world. At least for windows, it was "download this MSI installer and run it, and now you can npm install stuff". It might be different on other platforms, but it was definitely a breath of fresh air there.
> getting told ... that I shouldn't try messing with packages at all as I don't need them and should just install from git
This is my pet hate, except when it's clearly a newbie question. It's usually something like: "Hi, how do I [do unusual thing]?" > "Oh, you shouldn't be doing that, ever." > "Well, this is why I'm trying to do it and the reasonable constraints involved" > "oh, didn't think of that, here's a way to do it". Irritating as hell.
That's not the way FE works. You want to focus on the latest browser APIs as possible, to build more complex interfaces more efficiently. For the unlucky ones stuck on old browsers, you provide a fall back. Luckily modern browsers all auto-update, it's just those stuck with IE10 you need to worry about.
This is a pretty terrible attitude, and is a sad explanation of the churn in the JS community. FE does not work like this and I really wish some of the less professional crowd would stop keep spouting this sort of nonsense.
You start with the damn requirements and then look at how the application may need to be built.
The latest browser APIs are not useful for 99% of the FE work going on out there. Yes, I know it's more satisfying to pretend that it is important, but it really isn't. Just because you can hook something up to a users webcam, or post annoying browser notifications about the latest cat picture a user uploaded doesn't mean you need to or even should.
FE is not a special snowflake. It's no different from most software development (and yes, other, non-FE developers have to figure out cross platform issues as well). If you want to be taken seriously in software development, then stop with the unprofessional attitude and learn how to do something useful for your users, like <a href="https://en.wikipedia.org/wiki/Progressive_enhancement">Progr... enhancement</a>.
I maintain that it holds as a general principle, whether you judge it with BE criteria or not. I basically said this:
"That some field (e.g. FE) has a specific way of working is orthogonal to that way being broken or not".
Otherwise there would never be any brokenness conceivable ever, and everything would be a matter of different ways/conventions.
I don't see why brokenness shouldn't be a possibility in FE or anywhere else though. Sure, I might be wrong, and FE might NOT be broken. But that would not be the case merely because "it has its own way for doing things" -- it would have to be inherently not broken, whereas "has its own way" merely tells us that it's idiomatic.
The criteria you use it to judge it determine whether it's assessed as broken or not. I maintain it is NOT broken; it's your broken-assessing criteria that are wrong.
this is what babel enables, though, but it prevents you from thinking about it in your day to day life. babel specifically is a platform for treating javascript as a syntax tree and providing plugins that transform your code to target the minimum requirements you care about now, or in a year.
the alternative you propose is that everyone writes code that only targets well-supported javascript, but does that exclude polyfills or convenience functions? Does that mean that using a polyfill for Array.prototype.map is worse than using an implementation like _.map or a hand-written map function? At best, this choice results in a complex maintenance burden that is borne by developers during future refactors (rather than an infra-focused developer upgrading the babel distribution and its presets/plugins)
the current reality is that the browser ecosystem remains heterogenous (which is why there is still a valid market for things like jquery). A plugin like babel-preset-env for instance allows you to dynamically adjust the "minimum requirements" without needing to write new polyfills and gives the benefit of improving the transformed code with little to developer intervention. It's computers doing what they're good at, i struggle to see the harm in that.
I am a Ruby dev so I definitely don't pretend to know, however it does seem wild that something like Babel is even needed.
It seems to me that it's like trying to mix Ruby 1.8.7 and 2x in the same project and needing a tool to translate it into 1.9.3. Why not just write in 1.9.3 if that's the required target?
I clearly don't know what I'm talking about but what's wrong with actually just writing the JavaScript that Babel spits out? Why is something like Babel even tolerated? What I mean is that I would never try to mix five different Ruby versions and expect that to be a good practice. Someone educate me -- I'm not entirely sold on what's happening or why it's considered good.
Because browser bugs, platform features, and language features have always been a mish-mash and a set of moving targets. See the ES6 language compatibility tables for a visualization ( http://kangax.github.io/compat-table/es6/ ).
So, the choices are either only use features once you _know_ that a large enough percentage of your target audience supports it, or transpile newer syntax into older, more widely compatible syntax.
Nobody's really mixing versions, it transpiles ES6 and above to ES5. You don't have to use Babel, you only use it if you want to use the latest version of JS, ES6. You can happily just use ES5, and many people do.
Why use ES6? Firstly, it's a much better version, it solves a lot of problems (chief of all, it has a module system which ES5 doesn't have, not built in at least). Second, JS technology moves incredibly fast. ES6 will likely be supported 100% before the end of next year in all major browsers. So by then you can drop babel and just have raw code. Same with node.
It was supposed to be fully implemented end of this year or thereabout, but it seems that implementing the module system is problematic. Sadly, it's the most important thing, without which you can't drop babel.
It will be years and years before transpiling for backwards compatibility is no longer necessary. I breathe a sigh of relief when I learn that our customers are using something as modern as IE 11.
Well, yeah, by then we'll have to go back to serve different JS files for different browsers. Luckily old IEs support conditional comments so it shouldn't be an issue.
If you are required to support legacy browsers (which is just the nature of the beast for certain projects), Babel makes it relatively simple to use a new version of JS that may not be supported by those older browsers. Newer versions of JS come with helpful features that reduce bloat and aid developer experience
You don't get it. In FE the target is Java 8, 7, 6, 5, 4 and 3. Everybody uses different browsers, on different devices. If you wait for the least common denominator all websites would still look like geocities
Among other things, Babel allows me to use ES6/ES7/ES8 (e.g. async/await), to write my components in JSX and to type my code with Flow.
It would be so painful to work without Babel.
Thanks guys!