https://kotlinlang.org logo
Join Slack
Powered by
I had been under the impression that ES2015 would ...
# javascript
c
I had been under the impression that ES2015 would reduce Javascript bundle size, although it increases my bundle size by about 15%. I realize there are likely project-specific things—this is a Compose for Web (not WASM) app with Ktor. Before enabling ES2015 the Javascript is 2.1mb and after it is about 2.5mb. Are others seeing similar size increases?
i
I don't know if we saw a size increase but regardless the bundle size is massive which is our biggest pain point.
t
Are others seeing similar size increases?
It's highly recommended to use 
webpack-bundle-analyzer
for such problems.
Which granularity do you use?
c
How would I check granularity?
I think things are mostly default Kotlin settings
t
For compact bundle please add to 
gradle.properties
:
Copy code
kotlin.js.ir.output.granularity=whole-program
i
I don't know what the default granularity is but this seems to be incorrect advice. Seeing whole-program takes me from 4.2MB bundle size to 7.3MB
😐 1
t
Default - 
per-module
i
then per-module is a significantly smaller bundle size
t
It doesn't expected 😞
What about 
per-file
? 😉
i
without explanation I don't really want to use it, why would I use something other than the default for the field?
I also think this is off topic to the original question
🚫 1
t
In all cases it's required to call 
./gradlew clean
before check
c
I don’t think it’s off-topic – I’m open for any suggestions to reduce bundle size. I had originally hoped ES2015 would help and only just got to try it with the Ktor 3.0 release (there was a bug in Ktor 2 that broke with ES2015). I did clean builds for my ES2015 tests in my original post. I’ll try the granularity options and report back.
Are there any Kotlin specific recommendations for the webpack-bundle-analyzer?
t
Also looks like Ktor 3 doesn't support ES2015 right now. I provided 3 fixes for this issue.
Which features of Ktor do you use?
c
I have a pretty basic REST client. ContentNegotiation, Logging, HttpTimeout. I’m managing authorization on my own without a Ktor feature
t
Probably suspend fetch is what you need? Last time when I replaced Ktor with 
fetch
it was 
-500KB
approximately.
> Are there any Kotlin specific recommendations for the webpack-bundle-analyzer? 1. Apply 2. Check results
c
That would be a pathway to reduce my bundle size. I have avoided it so far because I’ve been writing multiplatform code to run on JVM, iOS, JS, and eventually wasmJs. I can swap out the JS implementation with Fetch instead of Ktor at some point when the API I’m writing against stabilizes.
Anyway, I will try some of the suggestions and follow up. It will probably be tomorrow
In order of increasing size in bytes: ES5, per-module, 2,199,604 ES2015, whole program 2,336,447 ES2015, per-module, 2,474,851 ES5, whole program, 3,069,551 Per-file fails to compile with errors for Kotlinx datetime like this:
Copy code
Execution failed for task ':browser-app:jsBrowserProductionWebpack'.
> Module not found: Error: Can't resolve '../../../kotlin-datetime-library-kotlinx-datetime/kotlinx/datetime/jsjodaexceptions.mjs' in '~/project/build/js/packages/Sigma-browser-app/kotlin/Kotlin-DateTime-library-kotlinx-datetime/kotlinx/datetime'
t
webpack-bundle-analyzer
reports required
c
For each? Or just the smallest?
t
Any with same granularity
In common case expected: 1. ES2015 < ES5 2. 
whole-program
< 
per-module
Do you measure JS file from distribution? 😉
c
Yes from dist/js/productionExecutable
t
For each? Or just the smallest?
For full picture first 3 required
m
I did not test how big the bundle size was when switching from commonJS to es2015 without lazy loading. But if lazy loading is an option for your use case, then I can highly recommend going that route. See our results here.
c
How does one enable lazy loading?
m
c
As a followup to this thread, the upgrade to Ktor 3.0.3 solves my original issue of ES2015 paradoxically increasing bundle size. With Ktor 3.0.3 and ES2015 enabled, my bundle size is now cut in half!
🐕 2
m
Seems like your decrease in the bundle size is mostly likely 
Compose
related because the bundle sizes of our projects stayed the same after updating to ktor 3.0.3 (from 2.x.x) FYI @Carter
c
Mine went from 2mb+ down to ~1mb. A Compose Web app is still large but a 50% reduction makes a big difference.
👍🏼 1
i
looks like ktor 3.0.3 doesn't blow up useEsModule() anymore but I still see a size increase going to per-file so opposite experience of what some of you seem to be seeing. 
whole-program
seems to be the smallest output size by about 1MB for me
c
Yes, I should have said whole-program rather than per-file is what I’m also having success with.
👍 1
4 Views
Open in Slack
PreviousNext
Powered by