Web Bluetooth: https://developers.google.com/web/updates/2015/07/interact-w...
and Web NFC: https://w3c.github.io/web-nfc/
should start making a dent in hardware access.
Except now in a slower single threaded language with a worse GUI toolkit.
I agree with the broader point that web tech is basically playing catchup with years of lag compared to existing technologies. However the one benefit we get from all this is real security and true universal runtime.
We've seen this plenty with GWT and the likes, but this one is self-hosted in the browser to support dynamic class loading. As with Emscripten, the real struggle is the stdlib, not the translation. As an alternative, I would recommend people look at TeaVM.
0 - https://github.com/konsoletyper/teavm
I really wish we had a powerful virtual machine like the JVM in our browsers though... Client-side frameworks are making the web much slower and are eating battery life.
Web assembly is a step in the right direction, but the "not invented here syndrome" makes my head hurt.
I installed and went to https://www.java.com/verify/ on google chrome and still says "The Chrome browser does not support NPAPI plug-ins and therefore will not run all Java content. Switch to a different browser (Internet Explorer or Safari on Mac) to run the Java plug-in."
Am I missing something here?
Yup, they got the applet experience nailed down perfectly :)
(Somewhat joking. The technology behind it is still extremely impressive)
It's kinda fun to see Swing again...
I'm not advocating traditional applets, but the Swing paradigm is actually near-perfect for the job.
lol, so they're mutually exclusive?
Short summary of the steps:
1) First try to join a webex, let firefox download and install the webex plugin
2) Look in ~/.webex, you'll see a bunch of 32-bit binaries
3) `ldd` on the 32-bit binaries, and install the 32-bit requirements to satisfy the missing dependencies.
4) Restart firefox, join the webex, you're done.
The big issue is that the plugin they download assumes you are using a 32-bit OS, and will fail to load without much in the way of meaningful error messages.
It would be a shame to lose all of them (similarly for J2ME).
"without JVM" - providing what is necessary to run Java is a JVM in my book. That you compile Java to JavaScipt is just an implementation detail, isn't it? EDIT: Yeah, ok. It emphasises that you don't need an extra JVM on your computer.
"fully client side" - isn't that how Java Applets always have been executed?
"no plugins" - Not sure what you mean by "plugin". Installing an extension does not match that?
Hmm.. ok, ok I am nitpicking :)
Could you instead provide a bookmarklet that runs Java Applets on websites? That would be something I would use. I would not install an extension because I don't want your code to run outside of the browser sandbox.
"without JVM" means you don't need a "standalone" client-side JVM install (outside of this extension).
"fully client side" means it's not doing something like "execution on a server, streamed video to the client"
and "no plugins" means it doesn't require a "chrome plugin". In chrome plugins != extensions. Flash and java were plugins, extensions are written in JS.
So, it's advertising that this is no longer required, and that they haven't achieved it with any server-side tricks.