15 ms·

Honest question, not meant to be inflammatory. If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evoluti

Honest question, not meant to be inflammatory. If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what’s the incentive to even bother thinking about what is official vs a Babel supported proposal. I like the idea of idiomatic JS with powerful modern features, but in practice every project I’ve seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are.

icholy 7y ago
I like TypeScript's (stage-3) approach to feature adoption.
- svieira 7y ago
  Gating on stage-3 really helps. (I have done the same on projects I work on and it helps) There are times when you need to consider the complexity of the specification and the amount of contention around it (decorators / SIMD for example). IMO, anything below that is effectively a custom macro anyway (for which you may want to consider sweet.js or babel.macro to make it clear that this may change and help you find places you use the feature). Real-world feedback may change anything from syntax to behavior (`flatMap -> flat`, `Object.observe -> Proxy`, `EventEmitter -> Observable -> Emitter?`, and the it-feels-like-dozens-of-options pipeline syntax)
- snek 7y ago
  It wasn't TS's idea, stage 3 exists purely for getting feedback from implementations about implementing and using the feature.
  - WorldMaker 7y ago
    It was TS's 2.0+ idea to stick to Stage 3 like glue. Especially prior to 1.0, but even during 1.x, TS implemented proposals in stages earlier to 3 (or even not yet staged). One of the regrets you sometimes hear from TS devs is that they added decorators way too early (it's still not Stage 3 and increasingly likely if it ever hits Stage 3 it will look very different, and it may never hit Stage 3 because there is a bunch of opposition), even though that is behind an "experimental" flag, there's a huge amount of "Production" code written with decorators in Typescript. (Largely thanks to the Angular ecosystem that became hugely dependent on decorators.)
adzicg 7y ago
Different products/teams can move at different speeds if they target a specific market. For example, for internal apps teams can expect that browsers are up-to-date, or that even only a specific browser will ever run the app. Also, people who write JS for back-end (eg node.js) or an embedded engine can control the environment their code runs in, and can use more up-to-date features. It’s similar to all the new tweaks and elements in HTML or DOM. If you’re working on Wikipedia, you will likely never get to use them. But if you work on a more niche app, they become quite useful. Over time, old browsers die out, and the amount of people who can use new features expands; early adopters do the testing for the late majority.
padolsey 7y ago
IMHO the current state of affairs is actually the best possible scenario. - Experimental language proposals can be tested in the wild - Real non-ivory-tower feedback is raised to TC39 - Everything feeds into the canonical ES spec (~no splintering) - Us regular folk are able to harness new syntax immediately - Users continue to have their old runtimes supported
- tlrobinson 7y ago
  I agree. 10 years ago I wouldn’t believe the language would be evolving (mostly improving) at the pace it currently is.
- mmartinson 7y ago
  I find these to be good points, but there is something missing for me that makes this "best possible scenario" only pretty good. JS is a notoriously quirky and inconsistent programming language. Clearly it's sufficiently usable for writing complex, powerful and reliable programs, but it's error-prone for non-experts and encourages programming patterns that make importing accidental complexity the norm. For many programming situations it'd be easy to just pick a different language, but obviously thus isn't the case for writing browser-based programs. The best possible scenario for me would somehow involve deprecation and removal of the nasty parts of JS, and a path towards a smaller, simpler, more consistent language. Right now it feels like the cost of backwards forever compatibility is paid every day, in every project, and it's completely wasteful, given that transpile and polyfill is widely considered best practice. Whether this could the job of TC39 or some other institution could go either way for certain.
  - bryanlarsen 7y ago
    Typescript removes some of the nastiest Javascript features. Of course that's not it's raison d'être and it includes a bunch of stuff you may not care for. However it is what is currently occupying the niche you're asking for. And it has all the advantages parent mentions.
  - z3t4 7y ago
    JavaScript was very simple compared to most languages. Adding a bunch of extra syntax variants, different types of scoping rules, magic syntax has made the language overly complex. Thankfully you can still use the "good parts".
snek 7y ago
You only need to target old es if you're deploying a website for a big company. Most people don't need IE6 compat. For example, people writing node apps can choose which version of node they deploy.
- GordonS 7y ago
  Maybe I'm missing something, but they said es5, not es4?
  - pault 7y ago
    I assume GP meant es5; es4 was an attempt to add static typing to JS and was never shipped. ActionScript 3 was the only implementation AFAIK.
coldtea 7y ago
>If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what’s the incentive to even bother thinking about what is official vs a Babel supported proposal. For one, not everyone works on the client. I can write for Node and use everything v8 supports without ever touching Babel and Typescript. >I like the idea of idiomatic JS with powerful modern features, but in practice every project I’ve seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are. Good parts/best practices are orthogonal to native features and libs, which is what we're discussing here.
- eropple 7y ago
  > I can write for Node and use everything v8 supports without ever touching Babel and Typescript. You totally can do that--but you probably shouldn't, because writing TypeScript is better for you and for future you. ;)
  - orange8 7y ago
    How will TypeScript instead of plain JS help the future me? Unless of-course you meant that as a joke (going by the wink).
    - Too 7y ago
      Type safe code improves code readability, and the future you will most likely read the code you are writing today.
      - orange8 7y ago
        If you were more comfortable/most familiar with strongly typed languages, then yes. But don't assume everyone has your tastes. Java for example is a very strongly typed language, and I find the verbosity makes it harder to parse. Good, future proof code can be written in any language. There's lots of still functioning, well maintained js written 10yrs back out there.
schwartzworld 7y ago
There are certain sectors in which backwards compatibility is important, but most people developing can confidently use ES2015+ features directly in the client without polyfill.
simias 7y ago
That's not unique to JS. Some compilers took over a decade to implement C99 features. Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it. If you never release new standards you'll never be able to use them. I realize that in JS world 4 years is basically an eternity so it's hard to project that far but I'm sure that if you still have to write javascript code 10 years from now you'll be happy to be able to use the features of ES2019. Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it?
- speeder 7y ago
  Sadly the "mostly" is because threads :( It is the part I was most excited about C99 and was very disappointed that it is so poorly supported.
  - kbp 7y ago
    Threads are C11, not C99.
- qudat 7y ago
  > Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it? If you are building a modern web "app", not a one off set of web pages, then yes, it is the standard. It would be very weird to not see a compile (transpilation) step.
  - untog 7y ago
    It's becoming less and less necessary. If you don't care about browsers with tiny usage you can ship ES6 as-is these days. All the main browsers support ES6 modules. And HTTP2 means having all those modules in different files doesn't have the huge performance impact it once did. About the only thing left (that isn't easily solvable) is stripping comments and minifying.
acdha 7y ago
> If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Your “we” isn’t everyone else’s. Some places need to support very old browsers but even in places like that usually not every app does. Those people are pushing the state of the art forward since they do real work outside of the standards process and that provides useful feedback to both the standards committees and browser developers.
- mmartinson 7y ago
  Fair, JS is everywhere and serves many use cases. The implicit "we" in that statement is developers 2019 who are building client side applications that need to get a lot done, run in most installed browsers, and remain maintainable to a 5-8 year horizon. Not everyone for certain, but probably enough to generalize, at least on this forum.
  - acdha 7y ago
    Again, that really depends on what features you use and who your clients are. It's entirely possible that a team may not need IE11 support now or that they've moved in the direction of low-overhead for modern clients and a legacy mode (possibly transpiled) for the <1% of people who affected. At some point this is a business decision like anything else and the security considerations in particular have helped get people onto evergreen browsers faster than used to seem possible.
  - mantap 7y ago
    You tell such users: "Your browser is too old, please update it" and direct them to the Chrome and Firefox websites. With the exception of Safari, all major browsers support auto-updating, and anybody who intentionally uses an outdated version of Safari is a masochist with a deviant fetish for error messages.
    - DonHopkins 7y ago
      And in the idealized fantasy world of Ayn Rand, any giant dinosaur enterprise corporation who insists on using antique outdated Jurrasic browsers deserves to be bitch-slapped by the invisible hand of the market into extinction for their outrageously dangerous security and privacy policies. To bad the real world doesn't work the same as it does in self-indulgent libertarian porn...
qudat 7y ago
From my perspective, it is less about what we can use in the browser without transpilation, but where the js ecosystem is heading. I personally only want to write JS that is in spec because in 5 years something like decorators might not be a thing. Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn. I think there's a lot of momentum with the spec and something to point to where can say "you should learn this syntax/feature because it's in the spec."
- mmartinson 7y ago
  > Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn. I agree, this is super important. My inclination whenever I did into a JS project has been to use lodash/underscore everywhere for everything, assuming that it is popular enough that someone will be able to maintain it without much headache, and I can actually get stuff done without breaking my brain over JavaScript's notorious quirks. I'm curious at what point this stops being a good practice. It certainly was 4 years ago.
  - mmcnl 7y ago
    I hardly use lodash. What do you use it for? I presume most of your use cases can by easily handled by just using JS from the ECMAScript spec. Personally, I only lodash for the debounce functionality.
  - thrownblown 7y ago
    This came up in my teams standup today. We were analyzing old dependencies and Lodash was in the list and none of us could justify why we needed it anymore. So I guess that point is nowish. Same for jQuery.
mattwad 7y ago
Not true at all; With Node.js I don't have to wait for a browser to update, and V8 is often up-to-date with the latest stuff. And as a full-time JS dev, I have not gotten the feeling that the transpiler authors get to determine what's in the language. Honestly if they add anything that isn't destined to be part of the spec, I wouldn't use it because then you're tied into that transpiler for good.
z3t4 7y ago
Almost all new features can be implemented is ES5 so instead of transpiling you can patch old engines. Eg. Array.prototype.flatmap
- spankalee 7y ago
  That's Array.prototype.flat
dbbk 7y ago
> If we still need to target es5 4 years later This is only true if you're writing JavaScript for the client and you have to support IE11. For many companies, the usage for IE11 is so low now that it can be safely dropped, for instance my SaaS products all just target evergreen browsers.
- mmartinson 7y ago
  It's still a moving target though. Either you transpile, and your target is just a config option, or you are in the business of being super selective about which "official" language features are ok to use for your user base. I can't imagine the business case for anything but write-anything, transpileto whatever the lowest common denominator of the day may be. Outside of one-off scripts, I don't imagine many browsers actually will be running any these new ES features until they become a compile target themselves in 8 years.
Aperocky 7y ago
As a purely backend engineer with a passionate hatred for NPM, I love writing ES6 and native javascript. All of the newer features (tbh, I don't know which are new but I guess 'const', 'arrow functions', 'default parameters', 'string interpolations', 'filter/map' are definitely a few of them and made javascript more like the back end language that I work with). I wrote at least a thousand line of native javascript for the monkey scripts and my personal websites and I consider the experience a good one. I applaud the advancement of the javascript language itself and I consider the package management the source of all evil for javascript.
- mmartinson 7y ago
  What's your take on Node and backwards compatibility? Since you get to choose your runtime, is it valuable to stick with the same always-add, never remove approach as the browser? NPM taken out of the picture, I get writing one language everywhere would be nice. Do you just consider the bad parts to be the price to pay for not needing to keep track of the distinctions? I've recently been working in Electron, and I find having app logic in both browser JS and Node to be more of a frustrating uncanny valley than a help. I suspect I'm in the minority on this one though, at least amount people with workaday skill set in client side JS.
  - Aperocky 7y ago
    I feel like you're mentioning forward compatibility instead of backward compatibility. ES5 code should run fine in ES6 AFAIK, and that's the extend of backward compatibility that should ever be needed. I haven't touched node all that much, and I'm in the camp that while it's good to just write one language everywhere, javascript still exhibits many of the key features of a browser language, which makes running it locally 'unnatural'. Same with trying to get python to run in a browser, maybe we should just embrace that we need to learn more languages as that is generally the case for us software engineers.
tlrobinson 7y ago
Having these features in the standard gives browsers and transpilers a common, well-specified target to work towards. If you only need to support a subset of browsers you can turn off compilation/polyfills for specific features, which sometimes leads to better performance and smaller bundles. I think of it like TypeScript and Babel running ahead experimenting with new ideas, ES following along turning the good ideas into a spec, and browsers taking up the rear implementing the spec. It’s a pretty decent system.
lucasmullens 7y ago
We're in the age of "evergreen" browsers, where almost everyone is on a browser that auto updates. New features can be useable in maybe 2 years now, depending on your audience.
- chadlavi 7y ago
  [laughs in enterprise web app]
  - DonHopkins 7y ago
    Those people should just stick to IE5 anyway. How about simply compiling IE5 into WebAssembly, wouldn't that solve the problem? ;)
ergothus 7y ago
> we still need to target es5 4 years later, This is a dramatic improvement over the 10 year lifespan of IE6 with es3. Once the need to target es5 drops, the next level gets even shorter - I don't think we'll get less than 2 years as a practical matter, but even at a 2 year delay, that's still regularly progress. > a pretty arbitrary subset of the language Best practices don't come from a mathematical model - programming is about communication and being compatible with user/business demands (which keep changing). Thus, best practices come about from a lot of experimentation and retrospective. That's ongoing. This doesn't mean it won't settle down. Heck, as it is, a lot of dynamic best practices influence the direction of non-dynamic languages - all of which arises from time and experimentation.
spankalee 7y ago
You don't necessarily need to target ES5. What percentage of your users is on IE11? Are you making money from them? Can you serve only them a compiled bundle?
baddox 7y ago
> Is the evolution of JS not directed in practice by the authors of Babel and Typescript? In practice? I suppose in practice, JavaScript is driven by everyone in aggregate and what people consider to be "JavaScript" rather than "something that can be made to run in traditional JavaScript environments like browsers." I'm not sure if you mean that, or simply who directs actual changes to the traditional JavaScript environments (like browsers) themselves. But yeah, if transpilation tools are reliable and continue to be well-maintained, you can say "why bother updated the 'official' language and implementation in browsers?" But I don't understand how this is a bad thing. You're getting the best of both worlds: browsers will implement new JavaScript features and optimizations, and some dev teams can also use build tools to use those new features, and other potential new features, and still make their work available to older browsers. It doesn't seem like a problem to me, unless you're thinking about all the language development effort in the JavaScript community as a fixed pie such that "non-official" language development like Babel and TypeScript take away effort that otherwise would be allocated to official language development. And I certainly don't think that is the case.
bastawhiz 7y ago
> If we still need to target es5 4 years later You don't. Unless you care about IE11 (for most consumer products and mobile apps isn't necessary) you can use many of the features up through ES2016 or later without transpilation. My business uses JS classes, arrow and async functions, and new prototype methods without issue.
mmckelvy 7y ago
In my experience, you don't really have to target es5 anymore. Most browsers support new features all the way through es2018. My Babel / Webpack config is pretty minimal these days.
marmada 7y ago
Are you proposing that we just never improve the language?
mmcnl 7y ago
JS doesn't compile so all the runtime engines (mainly browsers) need to adopt the new features as well. This takes time. These new features are part of the official ES2019 standard, and Babel makes it possible to use these new language features and transpile it to a language that all the browsers can use. What's not to love? This is actually a great (if not amazing) thing.
igneo676 7y ago
A few off the top of my head: 1. Node.js greatly benefits from these features. Transpiling is not as prevalent there 2. Some people do exclusively target "evergreen" browsers and don't care about IE support 3. Those that do differential bundling (different bundles per browsers) can see quite a performance boost by not transpiling on newer browsers
- masswerk 7y ago
  Ad 2) It isn't just about IE anymore as more and more older machines become outphased for current OSes. E.g., for a 10 years old Mac Pro, which is still a viable machine, Firefox is currently the only evergreen option which is still receiving updates. (Safari is largely OS-dependent, as is WebKit, and Chrome/Chromium cancels support as soon as the OS is phased out.)
NKCSS 7y ago
Because, everything has been moving to evergreen browsers for desktop. If only the mobile devices would do the same, you could have a future where you would not have to.
Vanderson 7y ago
One place this works, when your clients are able and willing to use the latest browsers to use your software. The primary benefit is that I don't have to rely on hacks. This is how I build the backend to my CMS and my clients are happy to keep their browsers updated. (nearly trivial to do these days). This also means that as soon as I see a new JS/CSS feature that will eventually become mainstream, I can use it in my admin as soon as both major browsers (Firefox/Chrome) support it. And even sooner if it's not a critical feature. (eg, I can skip adding a feature like "lazy loading" because browsers will have it built in eventually, etc...) On the public facing front end, that is a different story though. It's motivation to keep things simple.
Roboprog 7y ago
I hear you. I look forward to seeing the (support) death of IE11 in 2025 (!!!), which is likely all too close to my own retirement. Also about the “subset” thing: the last 10 years or so I have been moving away from OOP, and more towards FP, so stuff like class support or Typescript have been a big yawn, anyway. We had “C with classes” (I.e. C++ as it was known at the time) shoved down our throats in Uni back in the 80s, since garbage collection was impractical. That “wisdom” turned out to be short lived, and thus my migration towards FP (beyond the Lisp I had in an AI class back in the 80s)
TheRealPomax 7y ago
Equally honest counter-question: all modern browsers essentially support ES2019 already, so why would anyone still need babel outside of turning JSx into JS because React is still a hot tech, or in order to turn normal modern code into the kind of legacy code that >99% of your visitors won't need? I'm sure there are plenty of build systems out there that still indiscriminately turn things into ES5, because "that's how we wrote it years ago and it still works", but anyone who actually cares about performance will think twice before using babel today to turn nice, clean, concise modern code into incredibly verbose and shimmed legacy code, and will certainly think twice before serving ES5 code to users on a modern browser.
- tracker1 7y ago
  There's a handful of unsupported features I play with... the null operators and pipelines in particular. But I do set my presets for pretty modern support as a baseline. I still use webpack as well.
  - TheRealPomax 7y ago
    Webpack is just a bundler, it doesn't turn modern code into overly verbose legacy code on its own. Babel's the real troublemaker because by default it's still acting like it's the original 6to5 package. Using it to turn draft features into working ES2018 is sensible, using it to convert all the way down to ES5 for anything that isn't IE11 (which is basically the only legacy browser left at this point), not so much.
    - tracker1 7y ago
      Agreed. That's why my baseline is at least async support. Every modern browser has supported it for about 2 years now, and regenerator+asynch was the single biggest part of legacy transforms. I did have a second config for legacy, but at my current job was able to drop support, and just show unsupported browsers a message page now.
tracker1 7y ago
If you target modern browsers only, and if you're building non-web facing apps, you should be able to... you can absolutely use this stuff today. Right now, for example, the apps I'm working on require at least async/await support as a minimum test.

icholy 7y ago

I like TypeScript's (stage-3) approach to feature adoption.

svieira 7y ago
Gating on stage-3 really helps. (I have done the same on projects I work on and it helps) There are times when you need to consider the complexity of the specification and the amount of contention around it (decorators / SIMD for example). IMO, anything below that is effectively a custom macro anyway (for which you may want to consider sweet.js or babel.macro to make it clear that this may change and help you find places you use the feature). Real-world feedback may change anything from syntax to behavior (`flatMap -> flat`, `Object.observe -> Proxy`, `EventEmitter -> Observable -> Emitter?`, and the it-feels-like-dozens-of-options pipeline syntax)
snek 7y ago
It wasn't TS's idea, stage 3 exists purely for getting feedback from implementations about implementing and using the feature.
- WorldMaker 7y ago
  It was TS's 2.0+ idea to stick to Stage 3 like glue. Especially prior to 1.0, but even during 1.x, TS implemented proposals in stages earlier to 3 (or even not yet staged). One of the regrets you sometimes hear from TS devs is that they added decorators way too early (it's still not Stage 3 and increasingly likely if it ever hits Stage 3 it will look very different, and it may never hit Stage 3 because there is a bunch of opposition), even though that is behind an "experimental" flag, there's a huge amount of "Production" code written with decorators in Typescript. (Largely thanks to the Angular ecosystem that became hugely dependent on decorators.)

adzicg 7y ago

Different products/teams can move at different speeds if they target a specific market. For example, for internal apps teams can expect that browsers are up-to-date, or that even only a specific browser will ever run the app. Also, people who write JS for back-end (eg node.js) or an embedded engine can control the environment their code runs in, and can use more up-to-date features. It’s similar to all the new tweaks and elements in HTML or DOM. If you’re working on Wikipedia, you will likely never get to use them. But if you work on a more niche app, they become quite useful. Over time, old browsers die out, and the amount of people who can use new features expands; early adopters do the testing for the late majority.

padolsey 7y ago

IMHO the current state of affairs is actually the best possible scenario. - Experimental language proposals can be tested in the wild - Real non-ivory-tower feedback is raised to TC39 - Everything feeds into the canonical ES spec (~no splintering) - Us regular folk are able to harness new syntax immediately - Users continue to have their old runtimes supported

tlrobinson 7y ago
I agree. 10 years ago I wouldn’t believe the language would be evolving (mostly improving) at the pace it currently is.
mmartinson 7y ago
I find these to be good points, but there is something missing for me that makes this "best possible scenario" only pretty good. JS is a notoriously quirky and inconsistent programming language. Clearly it's sufficiently usable for writing complex, powerful and reliable programs, but it's error-prone for non-experts and encourages programming patterns that make importing accidental complexity the norm. For many programming situations it'd be easy to just pick a different language, but obviously thus isn't the case for writing browser-based programs. The best possible scenario for me would somehow involve deprecation and removal of the nasty parts of JS, and a path towards a smaller, simpler, more consistent language. Right now it feels like the cost of backwards forever compatibility is paid every day, in every project, and it's completely wasteful, given that transpile and polyfill is widely considered best practice. Whether this could the job of TC39 or some other institution could go either way for certain.
- bryanlarsen 7y ago
  Typescript removes some of the nastiest Javascript features. Of course that's not it's raison d'être and it includes a bunch of stuff you may not care for. However it is what is currently occupying the niche you're asking for. And it has all the advantages parent mentions.
- z3t4 7y ago
  JavaScript was very simple compared to most languages. Adding a bunch of extra syntax variants, different types of scoping rules, magic syntax has made the language overly complex. Thankfully you can still use the "good parts".

snek 7y ago

You only need to target old es if you're deploying a website for a big company. Most people don't need IE6 compat. For example, people writing node apps can choose which version of node they deploy.

GordonS 7y ago
Maybe I'm missing something, but they said es5, not es4?
- pault 7y ago
  I assume GP meant es5; es4 was an attempt to add static typing to JS and was never shipped. ActionScript 3 was the only implementation AFAIK.

coldtea 7y ago

>If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what’s the incentive to even bother thinking about what is official vs a Babel supported proposal. For one, not everyone works on the client. I can write for Node and use everything v8 supports without ever touching Babel and Typescript. >I like the idea of idiomatic JS with powerful modern features, but in practice every project I’ve seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are. Good parts/best practices are orthogonal to native features and libs, which is what we're discussing here.

eropple 7y ago
> I can write for Node and use everything v8 supports without ever touching Babel and Typescript. You totally can do that--but you probably shouldn't, because writing TypeScript is better for you and for future you. ;)
- orange8 7y ago
  How will TypeScript instead of plain JS help the future me? Unless of-course you meant that as a joke (going by the wink).
  - Too 7y ago
    Type safe code improves code readability, and the future you will most likely read the code you are writing today.
    - orange8 7y ago
      If you were more comfortable/most familiar with strongly typed languages, then yes. But don't assume everyone has your tastes. Java for example is a very strongly typed language, and I find the verbosity makes it harder to parse. Good, future proof code can be written in any language. There's lots of still functioning, well maintained js written 10yrs back out there.

schwartzworld 7y ago

There are certain sectors in which backwards compatibility is important, but most people developing can confidently use ES2015+ features directly in the client without polyfill.

simias 7y ago

That's not unique to JS. Some compilers took over a decade to implement C99 features. Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it. If you never release new standards you'll never be able to use them. I realize that in JS world 4 years is basically an eternity so it's hard to project that far but I'm sure that if you still have to write javascript code 10 years from now you'll be happy to be able to use the features of ES2019. Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it?

speeder 7y ago
Sadly the "mostly" is because threads :( It is the part I was most excited about C99 and was very disappointed that it is so poorly supported.
- kbp 7y ago
  Threads are C11, not C99.
qudat 7y ago
> Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it? If you are building a modern web "app", not a one off set of web pages, then yes, it is the standard. It would be very weird to not see a compile (transpilation) step.
- untog 7y ago
  It's becoming less and less necessary. If you don't care about browsers with tiny usage you can ship ES6 as-is these days. All the main browsers support ES6 modules. And HTTP2 means having all those modules in different files doesn't have the huge performance impact it once did. About the only thing left (that isn't easily solvable) is stripping comments and minifying.

acdha 7y ago

> If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Your “we” isn’t everyone else’s. Some places need to support very old browsers but even in places like that usually not every app does. Those people are pushing the state of the art forward since they do real work outside of the standards process and that provides useful feedback to both the standards committees and browser developers.

mmartinson 7y ago
Fair, JS is everywhere and serves many use cases. The implicit "we" in that statement is developers 2019 who are building client side applications that need to get a lot done, run in most installed browsers, and remain maintainable to a 5-8 year horizon. Not everyone for certain, but probably enough to generalize, at least on this forum.
- acdha 7y ago
  Again, that really depends on what features you use and who your clients are. It's entirely possible that a team may not need IE11 support now or that they've moved in the direction of low-overhead for modern clients and a legacy mode (possibly transpiled) for the <1% of people who affected. At some point this is a business decision like anything else and the security considerations in particular have helped get people onto evergreen browsers faster than used to seem possible.
- mantap 7y ago
  You tell such users: "Your browser is too old, please update it" and direct them to the Chrome and Firefox websites. With the exception of Safari, all major browsers support auto-updating, and anybody who intentionally uses an outdated version of Safari is a masochist with a deviant fetish for error messages.
  - DonHopkins 7y ago
    And in the idealized fantasy world of Ayn Rand, any giant dinosaur enterprise corporation who insists on using antique outdated Jurrasic browsers deserves to be bitch-slapped by the invisible hand of the market into extinction for their outrageously dangerous security and privacy policies. To bad the real world doesn't work the same as it does in self-indulgent libertarian porn...

qudat 7y ago

From my perspective, it is less about what we can use in the browser without transpilation, but where the js ecosystem is heading. I personally only want to write JS that is in spec because in 5 years something like decorators might not be a thing. Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn. I think there's a lot of momentum with the spec and something to point to where can say "you should learn this syntax/feature because it's in the spec."

mmartinson 7y ago
> Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn. I agree, this is super important. My inclination whenever I did into a JS project has been to use lodash/underscore everywhere for everything, assuming that it is popular enough that someone will be able to maintain it without much headache, and I can actually get stuff done without breaking my brain over JavaScript's notorious quirks. I'm curious at what point this stops being a good practice. It certainly was 4 years ago.
- mmcnl 7y ago
  I hardly use lodash. What do you use it for? I presume most of your use cases can by easily handled by just using JS from the ECMAScript spec. Personally, I only lodash for the debounce functionality.
- thrownblown 7y ago
  This came up in my teams standup today. We were analyzing old dependencies and Lodash was in the list and none of us could justify why we needed it anymore. So I guess that point is nowish. Same for jQuery.

mattwad 7y ago

Not true at all; With Node.js I don't have to wait for a browser to update, and V8 is often up-to-date with the latest stuff. And as a full-time JS dev, I have not gotten the feeling that the transpiler authors get to determine what's in the language. Honestly if they add anything that isn't destined to be part of the spec, I wouldn't use it because then you're tied into that transpiler for good.

z3t4 7y ago

Almost all new features can be implemented is ES5 so instead of transpiling you can patch old engines. Eg. Array.prototype.flatmap

spankalee 7y ago
That's Array.prototype.flat

dbbk 7y ago

> If we still need to target es5 4 years later This is only true if you're writing JavaScript for the client and you have to support IE11. For many companies, the usage for IE11 is so low now that it can be safely dropped, for instance my SaaS products all just target evergreen browsers.

mmartinson 7y ago
It's still a moving target though. Either you transpile, and your target is just a config option, or you are in the business of being super selective about which "official" language features are ok to use for your user base. I can't imagine the business case for anything but write-anything, transpileto whatever the lowest common denominator of the day may be. Outside of one-off scripts, I don't imagine many browsers actually will be running any these new ES features until they become a compile target themselves in 8 years.

Aperocky 7y ago

As a purely backend engineer with a passionate hatred for NPM, I love writing ES6 and native javascript. All of the newer features (tbh, I don't know which are new but I guess 'const', 'arrow functions', 'default parameters', 'string interpolations', 'filter/map' are definitely a few of them and made javascript more like the back end language that I work with). I wrote at least a thousand line of native javascript for the monkey scripts and my personal websites and I consider the experience a good one. I applaud the advancement of the javascript language itself and I consider the package management the source of all evil for javascript.

mmartinson 7y ago
What's your take on Node and backwards compatibility? Since you get to choose your runtime, is it valuable to stick with the same always-add, never remove approach as the browser? NPM taken out of the picture, I get writing one language everywhere would be nice. Do you just consider the bad parts to be the price to pay for not needing to keep track of the distinctions? I've recently been working in Electron, and I find having app logic in both browser JS and Node to be more of a frustrating uncanny valley than a help. I suspect I'm in the minority on this one though, at least amount people with workaday skill set in client side JS.
- Aperocky 7y ago
  I feel like you're mentioning forward compatibility instead of backward compatibility. ES5 code should run fine in ES6 AFAIK, and that's the extend of backward compatibility that should ever be needed. I haven't touched node all that much, and I'm in the camp that while it's good to just write one language everywhere, javascript still exhibits many of the key features of a browser language, which makes running it locally 'unnatural'. Same with trying to get python to run in a browser, maybe we should just embrace that we need to learn more languages as that is generally the case for us software engineers.

tlrobinson 7y ago

Having these features in the standard gives browsers and transpilers a common, well-specified target to work towards. If you only need to support a subset of browsers you can turn off compilation/polyfills for specific features, which sometimes leads to better performance and smaller bundles. I think of it like TypeScript and Babel running ahead experimenting with new ideas, ES following along turning the good ideas into a spec, and browsers taking up the rear implementing the spec. It’s a pretty decent system.

lucasmullens 7y ago

We're in the age of "evergreen" browsers, where almost everyone is on a browser that auto updates. New features can be useable in maybe 2 years now, depending on your audience.

chadlavi 7y ago
[laughs in enterprise web app]
- DonHopkins 7y ago
  Those people should just stick to IE5 anyway. How about simply compiling IE5 into WebAssembly, wouldn't that solve the problem? ;)

ergothus 7y ago

> we still need to target es5 4 years later, This is a dramatic improvement over the 10 year lifespan of IE6 with es3. Once the need to target es5 drops, the next level gets even shorter - I don't think we'll get less than 2 years as a practical matter, but even at a 2 year delay, that's still regularly progress. > a pretty arbitrary subset of the language Best practices don't come from a mathematical model - programming is about communication and being compatible with user/business demands (which keep changing). Thus, best practices come about from a lot of experimentation and retrospective. That's ongoing. This doesn't mean it won't settle down. Heck, as it is, a lot of dynamic best practices influence the direction of non-dynamic languages - all of which arises from time and experimentation.

spankalee 7y ago

You don't necessarily need to target ES5. What percentage of your users is on IE11? Are you making money from them? Can you serve only them a compiled bundle?

baddox 7y ago

> Is the evolution of JS not directed in practice by the authors of Babel and Typescript? In practice? I suppose in practice, JavaScript is driven by everyone in aggregate and what people consider to be "JavaScript" rather than "something that can be made to run in traditional JavaScript environments like browsers." I'm not sure if you mean that, or simply who directs actual changes to the traditional JavaScript environments (like browsers) themselves. But yeah, if transpilation tools are reliable and continue to be well-maintained, you can say "why bother updated the 'official' language and implementation in browsers?" But I don't understand how this is a bad thing. You're getting the best of both worlds: browsers will implement new JavaScript features and optimizations, and some dev teams can also use build tools to use those new features, and other potential new features, and still make their work available to older browsers. It doesn't seem like a problem to me, unless you're thinking about all the language development effort in the JavaScript community as a fixed pie such that "non-official" language development like Babel and TypeScript take away effort that otherwise would be allocated to official language development. And I certainly don't think that is the case.

bastawhiz 7y ago

> If we still need to target es5 4 years later You don't. Unless you care about IE11 (for most consumer products and mobile apps isn't necessary) you can use many of the features up through ES2016 or later without transpilation. My business uses JS classes, arrow and async functions, and new prototype methods without issue.

mmckelvy 7y ago

In my experience, you don't really have to target es5 anymore. Most browsers support new features all the way through es2018. My Babel / Webpack config is pretty minimal these days.

marmada 7y ago

Are you proposing that we just never improve the language?

mmcnl 7y ago

JS doesn't compile so all the runtime engines (mainly browsers) need to adopt the new features as well. This takes time. These new features are part of the official ES2019 standard, and Babel makes it possible to use these new language features and transpile it to a language that all the browsers can use. What's not to love? This is actually a great (if not amazing) thing.

igneo676 7y ago

A few off the top of my head: 1. Node.js greatly benefits from these features. Transpiling is not as prevalent there 2. Some people do exclusively target "evergreen" browsers and don't care about IE support 3. Those that do differential bundling (different bundles per browsers) can see quite a performance boost by not transpiling on newer browsers

masswerk 7y ago
Ad 2) It isn't just about IE anymore as more and more older machines become outphased for current OSes. E.g., for a 10 years old Mac Pro, which is still a viable machine, Firefox is currently the only evergreen option which is still receiving updates. (Safari is largely OS-dependent, as is WebKit, and Chrome/Chromium cancels support as soon as the OS is phased out.)

NKCSS 7y ago

Because, everything has been moving to evergreen browsers for desktop. If only the mobile devices would do the same, you could have a future where you would not have to.

Vanderson 7y ago

One place this works, when your clients are able and willing to use the latest browsers to use your software. The primary benefit is that I don't have to rely on hacks. This is how I build the backend to my CMS and my clients are happy to keep their browsers updated. (nearly trivial to do these days). This also means that as soon as I see a new JS/CSS feature that will eventually become mainstream, I can use it in my admin as soon as both major browsers (Firefox/Chrome) support it. And even sooner if it's not a critical feature. (eg, I can skip adding a feature like "lazy loading" because browsers will have it built in eventually, etc...) On the public facing front end, that is a different story though. It's motivation to keep things simple.

Roboprog 7y ago

I hear you. I look forward to seeing the (support) death of IE11 in 2025 (!!!), which is likely all too close to my own retirement. Also about the “subset” thing: the last 10 years or so I have been moving away from OOP, and more towards FP, so stuff like class support or Typescript have been a big yawn, anyway. We had “C with classes” (I.e. C++ as it was known at the time) shoved down our throats in Uni back in the 80s, since garbage collection was impractical. That “wisdom” turned out to be short lived, and thus my migration towards FP (beyond the Lisp I had in an AI class back in the 80s)

TheRealPomax 7y ago

Equally honest counter-question: all modern browsers essentially support ES2019 already, so why would anyone still need babel outside of turning JSx into JS because React is still a hot tech, or in order to turn normal modern code into the kind of legacy code that >99% of your visitors won't need? I'm sure there are plenty of build systems out there that still indiscriminately turn things into ES5, because "that's how we wrote it years ago and it still works", but anyone who actually cares about performance will think twice before using babel today to turn nice, clean, concise modern code into incredibly verbose and shimmed legacy code, and will certainly think twice before serving ES5 code to users on a modern browser.

tracker1 7y ago
There's a handful of unsupported features I play with... the null operators and pipelines in particular. But I do set my presets for pretty modern support as a baseline. I still use webpack as well.
- TheRealPomax 7y ago
  Webpack is just a bundler, it doesn't turn modern code into overly verbose legacy code on its own. Babel's the real troublemaker because by default it's still acting like it's the original 6to5 package. Using it to turn draft features into working ES2018 is sensible, using it to convert all the way down to ES5 for anything that isn't IE11 (which is basically the only legacy browser left at this point), not so much.
  - tracker1 7y ago
    Agreed. That's why my baseline is at least async support. Every modern browser has supported it for about 2 years now, and regenerator+asynch was the single biggest part of legacy transforms. I did have a second config for legacy, but at my current job was able to drop support, and just show unsupported browsers a message page now.

tracker1 7y ago

If you target modern browsers only, and if you're building non-web facing apps, you should be able to... you can absolutely use this stuff today. Right now, for example, the apps I'm working on require at least async/await support as a minimum test.