It's not about converting stuff in the browser to the jvm, it's about converting existing c and c++ (and others) to the jvm via an intermediate format primarily

It's not about converting stuff in the browser to the jvm, it's about converting existing c and c++ (and others) to the jvm via an intermediate format primarily (but not exclusively) designed for the browser. There are real reasons to 'rewrite-it-in-java' beyond just NIH, to the degree that even without this automatic transpiling it's frequently done (grpc-c vs grpc-java, all jdbc drivers, etc): - Native transitions are expensive - not just through register saving and gc machinery but also because native code is opaque to the optimizer. Runtime virtual inlining is probably the single most important optimization hotspot does and the more frequently code it can't work with is called the worse everything gets. While it's almost certainly nothing to worry about with coarse-grained syscalls, and probably not too much to worry about with things like opengl calls, I'd be very skeptical of using, say, a native database driver involving native transitions to retrieve every field of every row of every query in a db-heavy app. This is much the same way pypy is usually much happier with pure-python code than with native code - the more your vm does for you the less happy it is when it can't do it. Furthermore, as these binaries are the compiled results of clang and llvm (just with a different backend) the normal static analysis and optimization passes are run on the c source and ir, it just gets compiled down to a simpler instruction set than most modern physical machines. - Native deps are anathema to most clean java projects. Our de-facto dep system, maven (and compatibles), is entirely jar-centric. The 'accepted' solution for distributing something like sqlite is some poor person having compiled the native libraries on (win|lin|osx)(32|64), zipped them all up into a big ol jar, and put that single blob on maven. On boot it sees what platform its on, extracts the lib to a temp dir, loads it, then imports a jni binding for it. Inelegant to say the least, especially when java people tend to be spoiled by the notion of there being no difference between an osx or linux build or binary. - Debugging is worlds nicer when everything's in the jvm, even before stackmaps. You only need one debugger, it's nice and graphical, you can run it remotely with no such thing as a 'debug build', it basically never segfaults, et cetera.