Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lowering for ES5? #297

Closed
chowey opened this issue Jul 29, 2020 · 59 comments
Closed

Lowering for ES5? #297

chowey opened this issue Jul 29, 2020 · 59 comments

Comments

@chowey
Copy link

chowey commented Jul 29, 2020

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
Copy link

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
Copy link
Owner

evanw commented Aug 7, 2020

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
Copy link

@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
Copy link

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
Copy link
Contributor

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
Copy link

HugoDF commented Aug 14, 2020

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
Copy link

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
Copy link
Author

chowey commented Aug 19, 2020

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
Copy link

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

@chowey
Copy link
Author

chowey commented Aug 19, 2020

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
Copy link

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
Copy link
Contributor

Well, template literals are done 😉

@jhsware
Copy link

jhsware commented Sep 15, 2020

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
Copy link

@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
Copy link
Author

chowey commented Sep 15, 2020

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
Copy link

jhsware commented Sep 17, 2020

@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
Copy link
Contributor

Arrow functions done 🚀

Anybody have a full list of what's left?

@evanw
Copy link
Owner

evanw commented Sep 20, 2020

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
Copy link
Author

chowey commented Sep 20, 2020

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
Copy link

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
Copy link
Author

chowey commented Sep 27, 2020

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
Copy link

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
Copy link
Owner

evanw commented Aug 8, 2023

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.

@evanw evanw closed this as not planned Won't fix, can't repro, duplicate, stale Aug 8, 2023
sdavids added a commit to sdavids/sdavids.de-homepage that referenced this issue Aug 30, 2023
evanw/esbuild#297 (comment)

Signed-off-by: Sebastian Davids <sdavids@gmx.de>
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to sbc100/emscripten that referenced this issue Dec 8, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See emscripten-core#20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
sbc100 added a commit to emscripten-core/emscripten that referenced this issue Dec 9, 2023
We recently switch from using closure-compiler with `WHITESPACE_ONLY` to
closure-compiler with `SIMPLE_OPTIMIZATIONS`.  However this had the
negative side effect that all input need to be free of closure compiler
warnings, and this turned out not to be practical for all users.
See #20810 for more on this

When selecting a transpilation tool use I also evaluated `swx` (written
in rust) and `esbuild` (written in go).  `esbuild` was rejected
because the simply don't support ES5
(evanw/esbuild#297).  `swx` was rejected
because it almost doubled the side of our `node_modules` directory by
adding two 50mb binary files.
peaBerberian added a commit to canalplus/rx-player that referenced this issue Apr 3, 2024
For purposes where we need to generate a bundle (the demo, the worker
files, the RxPlayer bundle builds), we're progressively removing our
reliance on webpack toward esbuild.

It began with the demo page originally for performance reasons, but we
found out that the esbuild behavior and API was much simpler to
understand than webpack's, and so we ended up also prefering to rely on
it for our worker build.

Considering that we since the v4 only rely on TypeScript with no
bundling step for our "regular" build (and our home-made scripts in the
`./scripts` directory), we thus ended up having no reliance on webpack
for most of our builds.

However at #1400, we noticed that we might also need to provide an ES5
version of our worker file (at least for the PlayStation 4), and I found
that having ES5 support through esbuild is not straightforward
(evanw/esbuild#297).

Historically, [babeljs](https://babeljs.io/) was used to translate to
ES5 - and that's the one I know, so I tried using it on the bundle made
by esbuild.
However it turns out that there's no resource for how to use babel
like this - not integrated as a bundler's plugin (here we just wanted to
translate an ES2017 already-made bundle to es5) so I just gave up and
relied on webpack for specifically that ES5 build.

However this both added some perceptible delay in our build, and we
now relied on two different bundlers in our `npm run build` main
build script, which made me un-comfortable in terms of maintainance and
understanding of how our build step worked.

So I re-looked around and read about [`swc`](https://swc.rs/), which
seems to be some kind of babel competitor with some credibility (though
they advertises themselves as a """platform""", I would have preferred a
clearer term but ok), with some differences, including speed, but what is
most interesting here is that it can just be run as a standalone
transpiler (what I mean: not embedded in a bundler).

By using it, I've been able to remove reliance on webpack (and babel) in
our regular build steps (produced by `npm run build`) which should be
realistically used by 99.9999% of applications (approximately!). The
only exception where both webpack and babel are still used is to produce
our bundles attached to each release notes (they expose the RxPlayer
through `window`, like our grandfathers did) - which I guess are rarely
relied upon.
Still, we should probably remove reliance on webpack there in the
future.

Swc is maintained apparently by volunteers, and is less known than
babeljs, so there's still that. Also, the bundler and transpiler
JavaScript landscape is __VERY__ active (even in JavaScript terms) right
now with projects like [rolldown](https://rolldown.rs/) and
[oxc](https://oxc-project.github.io/) so sadly it may be not the last
update of this part of our build process.
peaBerberian added a commit to canalplus/rx-player that referenced this issue Apr 4, 2024
For purposes where we need to generate a bundle (the demo, the worker
files, the RxPlayer bundle builds), we're progressively removing our
reliance on webpack toward esbuild.

It began with the demo page originally for performance reasons, but we
found out that the esbuild behavior and API was much simpler to
understand than webpack's, and so we ended up also prefering to rely on
it for our worker build.

Considering that we since the v4 only rely on TypeScript with no
bundling step for our "regular" build (and our home-made scripts in the
`./scripts` directory), we thus ended up having no reliance on webpack
for most of our builds.

However at #1400, we noticed that we might also need to provide an ES5
version of our worker file (at least for the PlayStation 4), and I found
that having ES5 support through esbuild is not straightforward
(evanw/esbuild#297).

Historically, [babeljs](https://babeljs.io/) was used to translate to
ES5 - and that's the one I know, so I tried using it on the bundle made
by esbuild.
However it turns out that there's no resource for how to use babel
like this - not integrated as a bundler's plugin (here we just wanted to
translate an ES2017 already-made bundle to es5) so I just gave up and
relied on webpack for specifically that ES5 build.

However this both added some perceptible delay in our build, and we
now relied on two different bundlers in our `npm run build` main
build script, which made me un-comfortable in terms of maintainance and
understanding of how our build step worked.

So I re-looked around and read about [`swc`](https://swc.rs/), which
seems to be some kind of babel competitor with some credibility (though
they advertises themselves as a """platform""", I would have preferred a
clearer term but ok), with some differences, including speed, but what is
most interesting here is that it can just be run as a standalone
transpiler (what I mean: not embedded in a bundler).

By using it, I've been able to remove reliance on webpack (and babel) in
our regular build steps (produced by `npm run build`) which should be
realistically used by 99.9999% of applications (approximately!). The
only exception where both webpack and babel are still used is to produce
our bundles attached to each release notes (they expose the RxPlayer
through `window`, like our grandfathers did) - which I guess are rarely
relied upon.
Still, we should probably remove reliance on webpack there in the
future.

Swc is maintained apparently by volunteers, and is less known than
babeljs, so there's still that. Also, the bundler and transpiler
JavaScript landscape is __VERY__ active (even in JavaScript terms) right
now with projects like [rolldown](https://rolldown.rs/) and
[oxc](https://oxc-project.github.io/) so sadly it may be not the last
update of this part of our build process.
peaBerberian added a commit to canalplus/rx-player that referenced this issue Jun 13, 2024
For purposes where we need to generate a bundle (the demo, the worker
files, the RxPlayer bundle builds), we're progressively removing our
reliance on webpack toward esbuild.

It began with the demo page originally for performance reasons, but we
found out that the esbuild behavior and API was much simpler to
understand than webpack's, and so we ended up also prefering to rely on
it for our worker build.

Considering that we since the v4 only rely on TypeScript with no
bundling step for our "regular" build (and our home-made scripts in the
`./scripts` directory), we thus ended up having no reliance on webpack
for most of our builds.

However at #1400, we noticed that we might also need to provide an ES5
version of our worker file (at least for the PlayStation 4), and I found
that having ES5 support through esbuild is not straightforward
(evanw/esbuild#297).

Historically, [babeljs](https://babeljs.io/) was used to translate to
ES5 - and that's the one I know, so I tried using it on the bundle made
by esbuild.
However it turns out that there's no resource for how to use babel
like this - not integrated as a bundler's plugin (here we just wanted to
translate an ES2017 already-made bundle to es5) so I just gave up and
relied on webpack for specifically that ES5 build.

However this both added some perceptible delay in our build, and we
now relied on two different bundlers in our `npm run build` main
build script, which made me un-comfortable in terms of maintainance and
understanding of how our build step worked.

So I re-looked around and read about [`swc`](https://swc.rs/), which
seems to be some kind of babel competitor with some credibility (though
they advertises themselves as a """platform""", I would have preferred a
clearer term but ok), with some differences, including speed, but what is
most interesting here is that it can just be run as a standalone
transpiler (what I mean: not embedded in a bundler).

By using it, I've been able to remove reliance on webpack (and babel) in
our regular build steps (produced by `npm run build`) which should be
realistically used by 99.9999% of applications (approximately!). The
only exception where both webpack and babel are still used is to produce
our bundles attached to each release notes (they expose the RxPlayer
through `window`, like our grandfathers did) - which I guess are rarely
relied upon.
Still, we should probably remove reliance on webpack there in the
future.

Swc is maintained apparently by volunteers, and is less known than
babeljs, so there's still that. Also, the bundler and transpiler
JavaScript landscape is __VERY__ active (even in JavaScript terms) right
now with projects like [rolldown](https://rolldown.rs/) and
[oxc](https://oxc-project.github.io/) so sadly it may be not the last
update of this part of our build process.
peaBerberian added a commit to canalplus/rx-player that referenced this issue Jun 17, 2024
For purposes where we need to generate a bundle (the demo, the worker
files, the RxPlayer bundle builds), we're progressively removing our
reliance on webpack toward esbuild.

It began with the demo page originally for performance reasons, but we
found out that the esbuild behavior and API was much simpler to
understand than webpack's, and so we ended up also prefering to rely on
it for our worker build.

Considering that we since the v4 only rely on TypeScript with no
bundling step for our "regular" build (and our home-made scripts in the
`./scripts` directory), we thus ended up having no reliance on webpack
for most of our builds.

However at #1400, we noticed that we might also need to provide an ES5
version of our worker file (at least for the PlayStation 4), and I found
that having ES5 support through esbuild is not straightforward
(evanw/esbuild#297).

Historically, [babeljs](https://babeljs.io/) was used to translate to
ES5 - and that's the one I know, so I tried using it on the bundle made
by esbuild.
However it turns out that there's no resource for how to use babel
like this - not integrated as a bundler's plugin (here we just wanted to
translate an ES2017 already-made bundle to es5) so I just gave up and
relied on webpack for specifically that ES5 build.

However this both added some perceptible delay in our build, and we
now relied on two different bundlers in our `npm run build` main
build script, which made me un-comfortable in terms of maintainance and
understanding of how our build step worked.

So I re-looked around and read about [`swc`](https://swc.rs/), which
seems to be some kind of babel competitor with some credibility (though
they advertises themselves as a """platform""", I would have preferred a
clearer term but ok), with some differences, including speed, but what is
most interesting here is that it can just be run as a standalone
transpiler (what I mean: not embedded in a bundler).

By using it, I've been able to remove reliance on webpack (and babel) in
our regular build steps (produced by `npm run build`) which should be
realistically used by 99.9999% of applications (approximately!). The
only exception where both webpack and babel are still used is to produce
our bundles attached to each release notes (they expose the RxPlayer
through `window`, like our grandfathers did) - which I guess are rarely
relied upon.
Still, we should probably remove reliance on webpack there in the
future.

Swc is maintained apparently by volunteers, and is less known than
babeljs, so there's still that. Also, the bundler and transpiler
JavaScript landscape is __VERY__ active (even in JavaScript terms) right
now with projects like [rolldown](https://rolldown.rs/) and
[oxc](https://oxc-project.github.io/) so sadly it may be not the last
update of this part of our build process.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests