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
> Babel transforms your JavaScript, You put JavaScript in, And get JavaScript out
That says all you need to know about the javascript ecosystem.