rescript-compiler
rescript-compiler copied to clipboard
Generate es6 arrow function
As of 2020, the arrow function syntax is widely supported and performance is almost identical, so IMO it's time to switch to this syntax for smaller bundle size. At least it make sense to use arrow function when module is set to es6. People can still use babel if they need it otherwise
the size should not matter when gzipped?
I generate test code using following script
let str = ''
for (let i = 0; i < 1000; i++) {
str+= `window.f${i} = () => {
console.log(${i})
return ${i}
}
`
}
and after terser and gzip it's 8.3K vs 7.8K, so I'd argue it still matters
@Austaras this is an extreme case, it's a tiny function which happens rare in practice. We will compile to es6 features selectively.
At least it make sense to use arrow function when module is set to es6.
This makes sense
At least it make sense to use arrow function when module is set to es6.
I think it's useful to keep it like it is. This way, you can use a bundler such as Rollup that understands es6 modules and does tree-shaking, while not having to involve something like Babel to process the JS output.
If you have a bundler already it's just a loader/plugin away for using a transpiler and babel isn't too bad as a dependency.
I was able to drop IE11 as a requirement so I switched to terser
for bundling, it's an ES6 fork of uglify-js
. It has an ecma
compression setting to convert ES5 code to ES6+, and an unsafe_arrows
option which converts most BuckleScript function
s to arrows. Not all, because some of them still can't be converted based on static analysis.
https://terser.org/docs/api-reference#compress-options
Saved me about 24kb on my minified bundle.
@TheSpyder, how much does it save after gzip ?
@hhugo I was working off comments in the code, so I had to recompile and check
The app I'm working on isn't finished, but right now terser's ES6 conversion options save 24303 bytes minified on a 307028 byte bundle, after gzip that's 2233 bytes from the 89082 byte bundle
but as much as I agree that gzip is what matters for network latency, we don't generally ship gzipped files and perception is a huge factor here. There's also an argument that smaller bundles will parse faster in browsers, although the savings there are probably insignificant at this scale.
Other cases es6 syntax may have benefit:
- optional parameter
- es6 class
In ES6 they're default parameters, not optional, and the semantics are different to OCaml optional params. However it would work for OCaml default parameters, avoiding the need for a !== undefined
check inside the function. It would even line up well with how they're implemented at the call site today, where unspecified parameters are passed as undefined
.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
No keep it open, please.