As I understand, client side must always load the kotlin.js file first, then our application js files. I guess, client will never need kotlin.meta.js (123 KB) and this file is only used when transpile kotlin to js, is that correct?
Don’t you think it is too big when using for web frontend because user needs to wait to download a big js file? Is there a plan to separate into smaller modules and only include what we need? Or does anyone have ideas to improve startup time when user visit our website the first time?
Sure, we are working on it. There are several possitble solutions to reduce kotlin.js size:
Write our own tool that removes unnecessary parts of JavaScript files produced by Kotlin compiler.
File-to-file compilation, when each Kotlin source file compiles to single JavaScript file. Tools like WebPack should remove unnecessary JavaScript files.
Generate code for Google Closure Compiler. It’s very specific way, since GCC in advanced mode imposes restrictions on the code, and not all JavaScript libraries follow these restrictions.
Compile program as a whole. This allows to perform dataflow analysis during compilation and derive which code is ever used.
I think we need all four options implemented someday. However, the easiest way for now is (1). We have a prototype of such tool that is capable of reducing miminal Hello Word application down to ~60 kilobytes. Another approach that we can implement in the near future is (2), it’s important, since modern JavaScript ecosystem uses file-to-file compilation.
Let me adress the elephant in the room, instead of a fancy transpile and glorified minification system how about grouping by purpose all functions in different js files in a class like fashion and using AMD (RequireJS for example) this will require files async allowing fast loads no matter how absurdly big kotlin.js becomes.
Kotlin should take lib size seriously, come on 1mb file just for a cleaner syntax, no one besides heavy single paged enterprise apps (and not even them) is willing to make the webapp that heavy, is simply unacceptable especially when EcmaScript 6 is about to become de facto in all browser.
I belive Kotlin has a bright future but this kinds of decisions will determine its path at least in the near future, and imo the weight of kotlin.js is a con that currently wins any posible pro and I belive there is many more people on the same boat.
it is 300kb pre minified so about angular 1.x size (minified) or 2x jquery
current js output is nowhere as good as say GWT output but i would argue after GCE tool and minification code size is not that big of a problem already.
the more complex app gets the larger part of it is app code itself.
current js compiler output looks like very direct translation of classes which is good for in browser debugging with sourcemaps or not. I yet to see other way to debug js targeted solutions without browser that actually works good. GWT had one few years ago but it was way too slow, tricky to use and very complex inside for non trivial projects.
Since it’s been a while since @Alexey.Andreev posted possible solutions, I thought I’d ask if there is any progress on this issue? (I’m pretty new to the community, so I’m not sure whether “near future” means months or years!)
Has anything happened to the pruning tool prototype you spoke of, Alexey?
One more data point: I work for a prominent tech. company. Our Web Tools team considered, and ruled out the use of Kotlin specifically because of this issue. It seems that until the Kotlin team gets minimal overhead in the 20K range minified/gzipped, Kotlin/JS will be ruled out everywhere but the edge cases.
I didn’t check the last version of the dead code plugin, but it looks promising.
I’m wondering, though, since tree shaking is something that is not specific at all to kotlin, what is the state of the art nowadays in generic tree shaking tools in the nodejs community ? I don’t mean standard ones based on import and export, but advanced ones that use a symbols dependency analysis.
I’m also wondering if there is a way to generate DCE statements using code coverage test cases. The tree shaking would keep everything which is used by the tests (plus the ones declared in the gradle build file).
Since previous posts are quite old, it would be great to have an update of the situation.
Would for instance a tool like rollupjs produce interesting results compared to the DCE plugin? How would you invoke rollupjs from gradle.kts to be able to compare the results?