Provide ES5 version of the worker file #1400
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `MULTI_THREAD` experimental feature rely on a Worker file which use
ES2017 features.
The most relied on way to import this file is through its "embedded
version", which is usually not processed by bundlers/compilers of the
application so it could be translated to a more compatible (usually
older) version of JavaScript.
Yet, we're encountering on the PlayStation 4 a case where the
`MULTI_THREAD` feature may be used, the device is compatible to
the WebWorker web API, but does not understand all of ES2017 features
(let alone ES2015 features).
For those devices, and because we could still want to be able to rely on
ES2017 for the vast majority of devices that do support it, I propose a
solution where we provide a supplementary Worker file that is compiled
down to ES5.
I rel on webpack instead of esbuild for this because esbuild does not
target es5 easily.
I'm not very confident of my webpack skills - even more considering that
Worker environments have some constraints and I'm not sure of every
web+JS features that babel + webpack might use, but hopefully, this
should work (I'll test it).
There are several downsides coming with this commit:
1. Webpack takes several seconds on my PC to compile the worker files.
As our building process was before relatively fast, this "slowness"
is now visible during build, where "Bundling worker files..." is
the slowest step on my PC.
2. Because I'm not that confident on the file outputted, I decided to
re-run all integration tests running in `MULTI_THREAD` mode both on
the regular and the ES5 version of that script. This means that
integration tests will take much more time to complete.
Comment on lines
+408
to
+411
| - It is also available as `dist/worker.es5.js` from the root directory of the project | ||
| published on npm. As such, it might already be found in your project's directory, for | ||
| example in the `node_modules` directory (most probably in `node_modules/rx-player/dist/` | ||
| depending on your project). |
There was a problem hiding this comment.
We have made the choice to not build es5 build of the API because we though it's responsibility of an application to compile file with whatever tools they are using. Does building the embed worker in es5 is an exception ?
There was a problem hiding this comment.
Yeah the issue with the embedded worker is that it is usually not read by application bundlers (we even don't want to, as we fear those might bring syntax not authorized in a worker environment or introduce an outside scope).
I also brought another worker file in release notes, dist directory etc., as I guess applications would just use it directly without re-compiling it.
Florent-Bouisset
approved these changes
Mar 11, 2024
peaBerberian
added a commit
that referenced
this pull request
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
that referenced
this pull request
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
that referenced
this pull request
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
that referenced
this pull request
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
MULTI_THREADexperimental feature rely on a Worker file which use ES2017 features.The most relied on way to import this file is through its "embedded version", a stringified version which is thus usually not processed by bundlers/compilers used by applications so it could be translated to a more compatible (usually older) version of JavaScript.
Yet, we're encountering on the PlayStation 4 a case where the
MULTI_THREADfeature could be used as the device is compatible with the WebWorker web API, but fails to do so as it does not understand all of ES2017 features (let alone ES2015 features).For those devices, and because we could still want to be able to rely on ES2017 for the vast majority of devices that do support it, I propose a solution where we provide a supplementary Worker file that is compiled down to ES5 by us.
I rely on webpack instead of esbuild for this because esbuild does not target es5 easily.
I'm not very confident of my webpack skills - even more considering that Worker environments have some constraints and I'm not sure of every web+JS features that babel + webpack might use, but hopefully, this should work (I'll test it).
There are several downsides coming with this commit:
Webpack takes several seconds on my PC (like between 5 and 10 seconds?) to compile that worker file.
As our building process was before relatively fast, this "slowness" is now visible during build, where "Bundling worker files..." is the slowest step on my PC.
Because I'm not that confident on the file outputted, I decided to re-run all integration tests running in
MULTI_THREADmode both on the regular and the ES5 version of that script. This means that integration tests will take much more time to complete.