I'd love to believe it. I'd be somewhat more convinced if there were libraries / frameworks out there that let you write a desktop app in the form of servlets and templates / static HTML/js/css files, and some hooks for app startup, shutdown, and some interaction for the very minimal "chrome" (UI elements) on the window edges, and then packages it up for you into a single executable which, when run, opens a webkit / gecko embedded browser, starts up an internal server, and makes it "just work".
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). As far as I know no such tool is available for java, nor for python, ruby, or the CLR. Personally I'd say such a desktop environment would easily be far nicer to write in than swing, and has the considerable advantage that you can share a lot of code between this desktop version and a web-based app. You also can use all the latest and greatest HTML5 features, because you know exactly what kind of browser you end up running on (though this conflicts with the "hey, I can turn this into a webapp in a snap" idea). On Nov 4, 5:19 pm, Ricky Clarkson <ricky.clark...@gmail.com> wrote: > The thread about server-side frameworks leads me to wonder; will the > current spate of evolution of web development ultimately bring us back > to desktop development, albeit with some changes? > > Clay observed that the focus is switching from server-side frameworks > to client-side frameworks. Google Gears (which I realise is going to > be replaced by Web Storage) gave applications the ability to store > data locally. JavaScript has been beefed up in terms of performance > to presumably be competitive with conventional desktop languages. > I'll imagine a couple of steps that could follow this: > > 1. Browsers start to allow other languages than JavaScript to run > code in web pages, in response to (my imagined) demand from businesses > to allow such code to be distributed as binary. > > 2. Browsers add yet more features that are traditionally the domain > of desktop apps, e.g., drag and drop between web pages or from native > file managers to web pages, clipboard access, CD/DVD/Blu-Ray burning, > printing, access to areas of the hard drive, managing their own window > positions and sizes. > > 3. The browser disappears into the OS (see Google Chrome OS), such > that there is no visible difference between running a desktop app and > a web app; the only real difference is that the desktop app can write > to anywhere the user can and requires installation but the web app can > only write to its own storage area or anywhere the user explicitly > gives it access to. > > 4. OSs allow desktop apps to sandbox themselves like web apps are, > and allow silent installation (java-web-start style) and update of > desktop apps that declare themselves 'sandboxable'. > > 5. Nobody gives a monkey's whether your app is a desktop or a web app > anymore, the difference is the toolkits you use to create the app > rather than what it can do. > > What do you think? -- 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.
