> Why not client side Ruby, Java, Groovy, Clojure, Scala etc. along side > JavaScript all running on the VBM (virtual browser machine, or keeping > in the spirit of a few of last pod casts you could misinterpret this > as , violent, bm).
The surface area that you're talking about is really really big. You will either end up with lobotomized implementations of these languages (like what Microsoft did with all .NET languages), or you end up with a huge surface for remote attacks. Can my java apps run Swing, AWT, Sockets, File IO, JNI? If so what dictates the permissions model? If not, can you really (not legally, but philosophically) call it Java? For example, I believe that VB died at 6.0 and some other language was born with the same name later on. You may call it Java, and it may basically have the same syntax, but that doesn't make it Java. > This would require way too much coordination between companies all set > on dominating the digital world to really happen. But ahhh, wouldn't > be nice to have client side, write once, in your language of choice, > run on anything that supports a browser. Having browser developers agree on HTML/CSS/JS standards are tenuous enough. Imagine trying to strong arm Microsoft or Apple into natively supporting language bindings for Java, Ruby, etc?? It will not happen. Its not in their interests and in fact it would probably hurt their proprietary platform development efforts. >From Reinier: > Something like iTunes (the music store part runs on HTML, or so I > hear), or Steam (which is all HTML running on top of an embedded > webkit). There are advantages and disadvantages to the strategy. The plus is that there are pieces of code that can be reused over the true web interface. Both examples cannot exist without an internet connection and cannot function without them. The same code running the web site is also power the client web browser engine. At least the steam version is not being served from the local application. There is possibly a little extra sugar into the steam HTML that allows for very simple primitive integration with the rest of the steam application, but make no mistake, there is still a ton of native code in steam and iTunes (I don't use the store, just the app, so I can't say anything about how itunes or its store work with web pages). They are not defacto portable in themselves, though it may simplify porting for specific areas of development. Positives: 1. Code reuse between the web page presenting the data and the integrated application means less coding and redundant work 2. Slightly easier time porting the application to other platforms (assuming the web engine of choice exists on all said platforms) 3. Easier to work with for experienced web developers Disadvantages: 1. Non-native feel -- Steam looks fine in general, but when you go to the web interface, you KNOW you're not running natively. In the old steam days I always giggled when I could right click and bring up the embedded IE's context menu. 2. Poor / difficult bindings with the rest of the system -- Unless you're truly writing an application from scratch on a system (assuming there was a an RCP HTML shell engine available) you will always need to worry about the web interface hooking back into the host application. I think steam gets it done using steam:// uri handlers and maybe some other magic, though I'm really not sure. That context shift really means a friction in interacting between the two layers of code on the platform. The web interface works well for Value because most of the web interface is mostly self-encapsulated. There is very little interaction between stream the windows client and the web site that is hosted from within the windows steam client that making and supporting these bindings was simple since there weren't many to be made. Do I believe that steam will eventually be a big webkit GUI with widgets and pages hosted from a local mini-server? I doubt it, but stranger things have happened. Even then, the run-time that would enable that would need a ton of systems access that one would never give to standard web browsers or cookie-cutter browser hosted local apps. 3. Basically no 'desktop integration' which one assumes is necessary since you wish to write a 'desktop application' using web tech. The caveat being as in the steam case where they use bindings to escape into a native layer for processing things which that cannot be done in HTML. As expressed in the previous point, this is not as straight forward as people may hope. Prediction: In 2012 the holy war over which RCP web engine of choice to run will be in the latest thing. If in fact this technique does get popular, not all will be portable despite the hope. You'll have a strata that will look and perform really well on specific platforms or for very specific purposes, and there will be others that are so jack of all platforms that you may as well call them web browsers (with the limited integration that goes along with it). It'll be just another layer of frameworks that everyone will have to learn 3 of. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
