AppId is over the quota
Decide what type of new, cutting edge version of JS/ES you are going to write inFigure out what combination of Babel + plugins will work properly with this versionBuild your package.json and figure out what dependencies you neededfigure out the correct Babel config that will compile your codeonce you’ve compiled your code, you need to compile it again so that the module system you are using works properlybut wait, you might also have an intermediary compile step depending on if you are using JSX and the tooling around that
I’m not saying these are bad things. Things like React and Node have done wonderful things for web development and allowed us to move forward in the web space in new and exciting ways. The problem is that we’ve created such a barrier around these great things that it is becoming increasingly harder to take advantage of them in a way that is reasonable.
Let me tell you about the times I have tried to use Babel. Yes, plural, because up until recently I could never get it to work. I wrote my ES2015 code, went to find Babel, only to be told that I needed babel-cli, once I got babel-cli I then figure out that it does nothing by itself and you need to download plugins. At this point I was confused, isn’t the point of Babel to compile modern JS code down to code we can use now? Why do we need to install plugins for something to do what it was built to do?
After again figuring out the ancient incantations of the compiler flags that would make even kernel developers blush, and again writing more config files, I finally have compiled my ES2015 code down to something I can include in my browser.
After all this, I load up my test.html file, and bask in the ‘hello world’ application I have just written in the new hotness that is ES2015. Except, now I have 2 actual source files (I was experimenting with ES2015 modules), 2 compiled files, 1 concatenated build.min.js file, and a ridiculous amount of configuration and build files.