The State of Babel
babeljs.io
babeljs.io
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!
babel completely changed my pov on javascript
Babel is great, I think returning the issues to GH is a big win.
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!
It's very humbling. I'm just here standing on the shoulders of giants.
https://twitter.com/jlongster/status/804888882408026113 which uses recast/babylon
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.
I think things will get very interesting indeed once WebAssembly really starts to be a real thing.
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.
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.
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.
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.
We should stop being so content with not being/using the worst.
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.
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.
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"
Snark aside, just because a product exists doesn't mean it's perfect, it doesn't mean that it can't be improved on.
Gulp is significantly easier to work with than make for many usecases, and tools like webpack aren't really comparable to make.
Most of the churn seems to come from people reinventing the wheel over and over again.
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.
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.
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.
It's not a problem, and it never will be.
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.
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.
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.
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!)
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.
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.
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.
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)
Why is that?
> If it's not your thing, just keep clear of it.
I don't currently do FE development, but like to keep abreast of changes. Why can't I make an observation about the apparent state of the ecosystem?
Also, I didn't mention anything about fatigue. You're projecting that.
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.
>Why is that?
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.
Different browser vendors with different motivations, vision and priorities as to what a web browser should do. As simple as that.
Both things are entirely possible -- and much simpler than the current state of FE.
> 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]).
[0]: https://www.reddit.com/r/javascript/comments/5fphiw/modern_j...
[1]: https://www.reddit.com/r/javascript/comments/5fphiw/modern_j...
[2]: http://blog.isquaredsoftware.com/2016/10/presentation-modern...
[3]: https://github.com/markerikson/react-redux-links
[4]: https://github.com/markerikson/react-redux-links/blob/master...
> 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.
[1] https://github.com/andywer/webpack-blocks
[2] https://github.com/webpack-flow/webpack-flow
[3] https://github.com/facebookincubator/create-react-app
[4] https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne...
Also, constant negative feedback discourages the creators and maintainers of projects like this from continuing to work on them:
https://medium.com/@thejameskyle/dear-javascript-7e14ffcae36...
To use ES6/ES7/ES8 (e.g. async/await), it's just:
npm install --save-dev babel-cli babel-preset-latest
"scripts": {
"build": "babel src -d dist --presets latest"
}I'm an experienced front-end developer and I must say that that list is intimidating.
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.
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.
> Babel transforms your JavaScript, You put JavaScript in, And get JavaScript out
That says all you need to know about the javascript ecosystem.
You work out the minimum requirements and write to that, you don't start out with the latest and greatest and work backwards.
FE having a specific way of working, doesn't preclude that way being broken.
"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.
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>.
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.
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.
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.
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.