Babel is great, and by all means use it if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider whether you actually need Babel. Maybe you can write a few more lines of utility code and forego the need to pre-process. If you're only targeting some platforms, you may not need anything more than plain old ES6. At the very least, make sure you know what Babel is doing for you, and what it's not. Some developers believe that Babel is protecting us from a great demon of code complexity when, in truth, browsers and node are pretty easy to deal with on their own. Let's take a look at some of the strategies for not needing Babel. ES5 is pretty okay: In the days when we used tables for layout and the debugger was named alert() , we would have been so grateful if JavaScript had the features that ES5 has today. If you truly need Babel you are not only a weak programmer, but also an ingrate. Face ...
Uh oh, its almost the end of 2015 so I'd better put at least one blog post here for posterity! About ten years ago, I was at a startup I co-owned and searching for a way to easily create a nice-looking UI for a Windows-based utility. Since this was a Windows app, most people at the time would have chosen C or C++ as the language or used C# and a framework like .NET. Or perhaps they would have gone old-school with something like MFC. Instead, we hosted the Windows HTML rendering engine in our own executable and built 80 percent of the app (including 99 percent of the user interface) in JavaScript and HTML. Basically, this would be a Cordova app today, but we coded it uphill both ways back then. A short time into development, it was becoming clear that there had to be a better way to organize all the DOM manipulation that had to be done. I looked around and tried a few libraries available at the time, but they seemed a bit ugly and weren't helping that much. Then, almost ten ...