I haven't read the full thread, but I'll throw this in. The technical direction of the desktop will be shaped by the skill set.
If 'most of' the world knows CSS / JS / HTML etc, then it's going to drive the technical direction, and what ever short comings that are currently in these platforms will be eventually corrected. On Nov 5, 6:33 pm, ADRA <dche...@gmail.com> wrote: > > 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 javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
