3 ms·
Unfortunately, to take this approach you generally need it to be a new language, so it doesn't have existing ecosystem baggage to carry along, which means it is
by evmar 8y ago
Unfortunately, to take this approach you generally need it to be a new language, so it doesn't have existing ecosystem baggage to carry along, which means it is less likely to win on another axis you often care about: developer familiarity.
This is why the candidates in this space are only the upcoming ones like Dart, Elm, and maybe Kotlin. The other "compile to web" approaches that use more established languages (like emscripten for C++ or GWT for Java) tend to produce larger binaries due to carrying along their ecosystem.
This is restating GP's point, but to say it again, this tradeoff is kind of inevitable -- half the reason to want to transpile is to reuse knowledge and libraries, but then by reusing those libraries you kill your binary size.
(This dynamic reminds me of all the people who hoped they'd be able to reuse their existing web apps on mobile but ended up with bad mobile apps. I think it's possible to make a good web-based app work on mobile but it's often a rewrite from an existing web site, at which point you're often rewriting anyway and might as well use a mobile-native language.)