JVM & CLR runtimes probably account for 75% of all enterprise backend apps running on server gear in production right now. Both have been beaten on for so long that they're both fairly reliable, which is not to say either bug free (reliable or secure), resource efficient or maximally productive, just more usable in production on average.
On the client side (browser-land), JavaScript (and HTML & CSS) is ubiquitous. The issue of course is that every browser is "especially" different. So it makes no sense to deploy browser extensions unless things need to talk to other local apps. It makes more sense to develop hybrid native apps which are mostly html5 using something like QtWebKit and add your own per-platform goop rather than try to use something like node-webkit, phonegap (cordova) or appcelerator, because, inevitably, system-specific code will be needed, and not having direct access to APIs because of limited proxy/thunk/trampoline code doesn't make for happy developers. Java tried to do the hybrid way using JNI, which could load dll's, dylib's and so's dynamically (I wrote a custom, cross-platform (Linux, Windows), CD-ROM-based app installer using Java + JNI in 1995 by the way, it was trivial.. And then I wrote a Java source to MIPS binary, direct, non-JIT compiler in C++ in 1999.).
It was written clean-room in some client's office (no NDA, but still, engineering ethics), but I may have a copy somewhere on a backup in offline IRL storage, but it was written for JDK 1.2-1.4 IIRC so it won't run and it's chocked full of confidential / proprietary apps (which it installs). It called a few C Win32 APIs to create icons and write registry entries, on Linux I think it just wrote files and maybe ran `ldconfig`. It was super dumb, fugly but it shipped and worked consistently. There was even Swing (pre-AWT) skinnable branding background images. It was probably 450 lines of Java and 80 lines of C. Autoplay even worked decently on Windows and it came up in under 8 seconds because I optimized the ISO image for file load order to minimize seeks, and that's booting an entire 1.4 JRE from a 4x CD-ROM drive to a usable, interactive state.
On the client side (browser-land), JavaScript (and HTML & CSS) is ubiquitous. The issue of course is that every browser is "especially" different. So it makes no sense to deploy browser extensions unless things need to talk to other local apps. It makes more sense to develop hybrid native apps which are mostly html5 using something like QtWebKit and add your own per-platform goop rather than try to use something like node-webkit, phonegap (cordova) or appcelerator, because, inevitably, system-specific code will be needed, and not having direct access to APIs because of limited proxy/thunk/trampoline code doesn't make for happy developers. Java tried to do the hybrid way using JNI, which could load dll's, dylib's and so's dynamically (I wrote a custom, cross-platform (Linux, Windows), CD-ROM-based app installer using Java + JNI in 1995 by the way, it was trivial.. And then I wrote a Java source to MIPS binary, direct, non-JIT compiler in C++ in 1999.).