Lowering for ES5?

[chowey]

This is an awesome project, by the way!

Do you have any longer-term plans to support ES5? I ask, because this is the only thing preventing me from using esbuild exclusively for all my transpiling needs.

Specifically, I am still required to support IE11, because it still has official support from Microsoft:

Is Internet Explorer 11 the last version of Internet Explorer?

Yes, Internet Explorer 11 is the last major version of Internet Explorer. Internet Explorer 11 will continue receiving security updates and technical support for the lifecycle of the version of Windows on which it is installed. IE 11 is available via Microsoft Update Catalog, Windows Update and Windows Server Update Service (WSUS).

What's worse, the "version of Windows on which it is installed" is Windows 10, which is planned to be the last version of Windows. So IE 11 may not be going away any time soon.

Something like shimport can be used to get ES modules running on IE11, so the only thing missing is ES5 lowering.

Perhaps this is something the community can help with?

[dmichon-msft]

Even without the ability to transpile down to ES5, having the ability to not introduce ES6 code during minification would make esbuild suitable for usage as a replacement for terser on existing ES5-compatible code, which appears to already be a significant performance win. I know that for many projects minification is a significant portion of the ship build time.

I authored this to try to cut down on the time spent in the minification process in large projects; would love to be able to use esbuild as an alternative minifier implementation for even better performance, but I'm stuck needing ES5 support for the time being.

[evanw]

Even without the ability to transpile down to ES5, having the ability to not introduce ES6 code during minification would make esbuild suitable for usage as a replacement for terser on existing ES5-compatible code

This will only happen if you set the target to es6 or above. If you set the target to es5, esbuild will not introduce ES6 code during minification. That flag won't translate ES6 constructs to ES5 because esbuild doesn't have support for that yet, but it will keep ES5 code as ES5 code. Please let me know if you are encountering any errors with ES5 code that unexpectedly becomes ES6 code when the language target is set to es5.

[dmichon-msft]

@evanw, good to know, I guess I misunderstood the issue around arrow functions, since converting function declarations to arrow functions is a pretty common transform when targeting es6. Might be worth mentioning in the docs that you can set the target below es2015, it just won't perform any additional syntax transformations?

[danickinator]

Please let me know if you are encountering any errors with ES5 code that unexpectedly becomes ES6 code when the language target is set to es5.

@evanw the issue that we've come up against trying to target IE11 (we're also locked into supporting it for the foreseeable future) is that IE11 supports a couple of ES6 features - most notably let and const - which will raise an error if esbuild is set to target 'es5'. Unfortunately, targetting 'es6' very quickly generates template literals which IE11 doesn't support.

As a result there currently isn't a target that can safely used to minify code for IE11. An 'ie11' target that was essentially just 'es5' + let/const would be a godsend.

[tooolbox]

Just have to comment how incredibly exciting it is to see the work on lowering template literals to string addition. Three cheers for @evanw !

[HugoDF]

For anyone else like me who was trying to get transpilation to ES5, I've used swc successfully as per this comment: #182 (comment) (thanks @evanw ). It's a magnitude faster than Babel.

[mindplay-dk]

As a result there currently isn't a target that can safely used to minify code for IE11. An 'ie11' target that was essentially just 'es5' + let/const would be a godsend.

While fully supporting ES5 is probably considerably more work, this sounds like relatively low-hanging fruit?

This might be a good, preliminary work-around for the "corporate world", where (sadly) IE11 is still the lowest common denominator.

[chowey]

Reversely, adding support for const/let => var is probably the most straightforward lowering that you could ask for.

If it is a comparable amount of work to do that replacement as it is to add a special "ie11" target, then I vote to just do the replacement (s/const|let/var/g or equivalent).

[mindplay-dk]

@chowey is it that simple? let and const have different scope.

[chowey]

You are right, a straight replacement won't work. Here is an example using Babel:

// input
var a, b;
{
  const a = 1;
  var b = 2;
}

// output
"use strict";

var a, b;
{
  var _a = 1;
  var b = 2;
}

[mindplay-dk]

Hm, there's probably a ton of other features required for IE11 too though?

for..of, template literals, default values for parameters, all the new object literal shorthands...

[tooolbox]

Well, template literals are done 😉

[jhsware]

IE11 will reach end-of-life on Aug 17th, 2021, so I doubt supporting it is worth the overhead unless you get it for free.
https://www.theverge.com/2020/8/17/21372487/microsoft-internet-explorer-11-support-end-365-legacy-edge

[mindplay-dk]

@jhsware unfortunately, reaching EOL does not mean every user stops using it on that date - as long as there's even 1 or 2 % still using it, most corporate products have to continue to support it. (21+ years of web development made agonizing by IE, so no doubt I'd have been the first to swear it off - sadly, most developers don't get to make that call.)

[chowey]

From the Verge article:

While it’s still going to take some time to pry enterprise users of Internet Explorer 11 away, Microsoft is hoping that the new Internet Explorer legacy mode in the Chromium-based Microsoft Edge browser will help. It will continue to let businesses access old sites that were specifically built for Internet Explorer, until Microsoft fully drops support for Internet Explorer 11 within Windows 10. Microsoft’s move to stop supporting Internet Explorer 11 with its main web properties is a good first step, though.

It seems like "dropping support" means their Office 365 products will no longer support it. This is definitely good news, don't get me wrong! But it is different than the browser itself reaching end-of-life.

[jhsware]

@mindplay-dk @chowey I agree that IE has an impressive will to survive. But given the negative impact of supporting IE on the other 98%+ of users I don't think the benefit is even close to making it worth it. Even if that means loosing 75% of potential adoption during the first years. This will start off as a niche tool anyway and we have to make life a simple as possible for the author so he has a long and prosperous life! :)

[tooolbox]

Arrow functions done 🚀

Anybody have a full list of what's left?

[evanw]

There's a lot left to do. Going off of http://es6-features.org/, it's something like this (for the syntax-level things at least):

• Block-scoped variables
• Default parameters
• Rest parameters
• Spread operator
• Template tags
• Computed object properties
• Object methods
• Destructuring
• Classes
• For-of loops
• Generators

This is a very significant undertaking and would likely result in the addition of a lot of bugs because these features have a lot of subtlety to them and interact in complex ways. TypeScript and Babel don't even get these features completely right and they have been around for a long time.

Realistically you would also probably need polyfills for various features such as maps, sets, typed arrays, and maybe promises? But esbuild is only concerned about the syntax transforms, not the polyfills, so it's bring-your-own-polyfill.

[chowey]

Realistically you would also probably need polyfills for various features such as maps, sets, typed arrays, and maybe promises? But esbuild is only concerned about the syntax transforms, not the polyfills, so it's bring-your-own-polyfill.

I fully agree! Polyfills can be handled by importing a library such as core-js. Babel has a preset-env that will detect which features you are using that might need a polyfill, and it will automatically add those core-js imports for you. But that is just a convenience. If esbuild does ES5 lowering and leaves polyfills to me, then I am totally satisfied.

[mindplay-dk]

Just a thought, but would it be feasible to bundle with esbuild, and then transpile the completed build with babel?

I mean, during development, you're probably testing with a modern browser anyhow - so you can skip babel, and then maybe the babel step and legacy browser testing is just something you do before a release.

You'd normally have two npm scripts anyhow, right? One for watching during development - and one to build for production, which would pipe the result through babel.

Any reason that wouldn't be feasible? 🤔

[chowey]

Honestly I work with Go-based servers. esbuild has the potential to completely eliminate Node and NPM from my development workflow. An esbuild-based Go HTTP handler could understand JavaScript source trees and generate bundles more-or-less on-the-fly.

There is also the possibility to do pre-compilation of source files, like HUGO does, using a similar pure-Go-based approach.

As you say, we do right now use Node-based tools because we have to. So it is possible to bundle using esbuild and then transpile the completed build with babel. But babel is slow. Like, really slow in comparison to esbuild. I do realize babel is doing extra ES5 lowering (which is more work than esbuild currently needs to do), but still. Really slow.

So while what you say is correct, and it is a good workaround for right now, I still feel it is a worthwhile goal to lower to ES5 directly from esbuild.

[jakearchibald]

Just a thought, but would it be feasible to bundle with esbuild, and then transpile the completed build with babel?

I think this is a good idea, even if esbuild gets first class support for ES5. This could be a plugin hook that gets the opportunity to transform each output chunk, similar to https://rollupjs.org/guide/en/#renderchunk in Rollup.

[evanw]

I'm closing this issue because I do not plan on doing this. My apologies to everyone who wanted esbuild to do this. ES6 was released a long time ago at this point and the cases where you need to target ES5 are rare and getting rarer. I believe that it makes sense to focus esbuild's limited development effort on other things.

This issue being closed doesn't change anything about how esbuild behaves when targeting ES5. The ES5 target is not being removed, and this doesn't prevent esbuild from potentially lowering additional syntax to ES5 in the future. It only means that esbuild will never fully support lowering everything to ES5.

I recognize that there are legitimate cases for running your code as ES5. Some mentioned in the above thread are supporting the few people that still use IE, building code for old smart TVs with outdated JS VMs, or building code for custom JS VMs that are selective about which parts of the JS spec they implement (e.g. Goja or Hermes). If you still want to use esbuild when targeting these unusual environments, then you will have to use an additional tool after running esbuild that transforms esbuild's ES6 output to ES5. Production-quality tools to do this are already written, widely used, and work well. This is not an area that esbuild needs to innovate in.