Sure, there's boatloads of non-'web' (html/css/js) code in steam and iTunes. But the *GUI* is *ALL* html/css/js. It's also true that both require the internet to function, but there is absolutely nothing stopping you from having the embedded webkit access servlets running in the same process space as the webkit itself. With a very simple tweak to the webkit's URL scheme resolver, you can even do this without opening any TCP ports, routing it all in-process. Just because (AFAIK) no app exists that uses this scheme doesn't make it impossible, and doesn't make it a bad scheme. I'd use such a thing in a heartbeat to build all my future desktop GUIs. Sure, it won't be portable by default, but porting relevant sections between the web and this app will be very simple.
The non-native feel bit: Well, yeah, but, the web certainly doesn't suffer from this. On the contrary, your average modern web app has _vastly_ better user interface design than your average modern desktop app. Also, the more complicated modern desktop apps seem to reinvent the UI wheel anyway - photoshop hardly looks native. Neither does the Microsoft Office suite, even. That should tell you all you need to know about the value of looking like the rest of the OS (i.e: very overestimated). I've also seen plenty of web apps that manage to recreate the look of a certain OS rather well. I ascribe to the theory that either (A) you lock the UI look down so its the same across all invocations of an app, or (B) the UI is shit. In java, I always strongly suggest to set the LnF to something specific, and most apps do. The pipe dream of writing an app once and having it magically look "native" on all platforms the VM runs on is worthless. So, on this point, I emphatically do not agree. Non-native feel is a non-issue. Note also that *ALL* "RIA" schemes (javaFX, AIR, and Silverlight) haven't really gone the native LnF route either, so evidently I'm not the only one that has come to this conclusion. Poor bindings: That's spanning the cart in front of the horse, isn't it? I see no technical reason for why an embedded webkit + servlet packaging tool has to use awkward stream URI handlers. If you feel the steam UI is badly built (and its certainly not great, I'll gladly give you that), that's probably the fault of Valve, not of the concept. Take for example Firebug on firefox: It looks fantastic, integrates extremely well with firefox, and yet its mostly written in js, html, and css. What kind of interaction are you thinking of? Drag and Drop? Check out Mailplane for the mac. It runs gmail in a custom browser window and fully supports just about everything you expect from a mail client, and such clients really push the envelope on OS interaction: You can drag and drop files, you can register mailplane as the handler for 'mail:' URLs and other send email requests, and when such a request includes a subject and a 'to', etc, it's all filled in for you in a new actual window that is showing the gmail new message page. It does offline too, seamlessly, and takes care of logging in for you. It also ships with a little badgy thing (similar to the notification icons at the bottom right on a windows machine) which shows a count of unread messages and which you can click to quick-open new mails. Mailplane is also integrated with growl (a mac notification thing that pops up little boxes when things happen), and clicking on such a growl notification opens mailplane and loads the email. It's perfect. In other words, your points 2 and 3 are just flat out wrong; Mailplane proves it. I think the mistake you're making is thinking that an app is a mishmash of everything it does. You have a GUI which is entirely disconnected from all the other things the platform does - you know, the basic idea behind MVC. This is a _good_ thing. In other to let the controller drive the GUI here and there you need some way (easier than websockets) to force new URLs / new windows out of the webkit wrapper, but an API for this is trivial, and as I mentioned, mailplane shows this can be done well. You also need to hook into the OS interaction which is primarily GUI driven, such as cross-app drag and drop, hooking into "app responsible for opening items of type X" system config, and possibly the copy/paste buffer. There's really not much more than that. Want a notification badge device? Code that natively, separate from the GUI. I'd do that even if I was writing a swing app, because that's how you're supposed to do it. Need to, I dunno, show up in the context menu of files when right clicked? Same deal. The responsibility for registering that is surely not the job of the GUI layer and therefore has nothing to do with html/css/js. The java- written backend takes care of that. And when clicked, it sends a message to the controller which in turn has the job of telling the GUI layer to start rendering whatever is appropriate for that. On Nov 5, 8:33 am, ADRA <[email protected]> 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 [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.
