Sign in to follow this  
cignox1

HTML based GUI for desktop applications

Recommended Posts

Hi all, I'm just curious: today, html(5), css and javascript with Ajax are really powerful tools to create beatiful and customizable layouts. Wouldn't it be interesting to have all this for desktop applications as well? I mean, the app GUI is just a local 'website', where controls are implemented as javascript components, and layouts as HTML/css pages. An application or os level engine will run the pages and the application interacts through events.

I can think of several interersting benefits of such approach: applications can interact though html pages: serializing GUI elements (i.e. windows) will then be just a matter of sending the related html/javascript code. Applications can host web components, or web sites can host applications components.
100% cross platform gui's.
100% cross language gui's layouts.
Reuse of elements is enhanced thank to the nature of the components and the fact that a simple update of the css can drastically change the aspect.

I think that this is a nice idea to play with, so I'm pretty sure somebody already did that: does someone know of such a tool?

Thank you!

Share this post


Link to post
Share on other sites
I don't know of any existing desktop applications, but WebOS was developed around the idea of apps being written with javascript, css and html. Windows 8 is heading this direction with Metro UI. HTML 5 has its disconnected mode. This is the new trend these days, and I am happy with this. I have always liked the idea of writing standalone applications UI with HTML, CSS and JavaScript.

Share this post


Link to post
Share on other sites
It's fairly easy to implement start with the Chromium source; it's basically the core of the Chrome webclient you just need to write the mouse/keyboard/bitmap display part of it.

We used it in a project to pull web interfaces off remote devices and drop as textured quads into a 3D environment. Worked really well. Also allowed us to write most of the apps UI as javascript/html.

I believe some of the tech is also available in Qt which may be a simpler packaging to look at.

Share this post


Link to post
Share on other sites
An interpreted language like Javascript is too slow and not powerful enough to do the work expected of a thick client. I do not want to have to deal with postbacks and stateless applications either. That being said, layout and styling could definitely be done in HTML5 and css. I would still want a non-interpreted language to do all of the heavy lifting such as c# or c++. Of course, Microsoft already has XAML for c# and basically does what you are looking for only it appears to do more with layout than HTML5. I think it would be neat if it was cross-platform supported as well but as far as I know, it is not currently. I am sure the Mono team is working on it though.

Share this post


Link to post
Share on other sites
I totally disagree. JavaScript is a very powerful language and anyone who says otherwise has either not touched JavaScript since 2003 or has never used it at all. Also, modern JavaScript VMs are very fast and even use JIT techniques to compile the JavaScript natively. No, an application written with JavaScript will probably never be as performant as the same <b>well written</b> application compiled with C or C++. But who will really care? Will anyone notice if their drop-down menu takes two milliseconds to begin animating instead of .5 milliseconds? No. Will a user notice if their application crashes with unsaved changes, likely due to some access violation caused by memory mismanagement, or if the application hangs because of some poorly written threading code? Most definitely they will.

Share this post


Link to post
Share on other sites
The issue is that you can't change the html page without the visual hiccup of page load. Users don't expect this of thick clients.

I work on a winforms app whose sole control is a web user control that we call from in C# and catch callbacks from javascript. It works, it's nice for some things, but keeping things in sync is awkward. And what can be done is limited by the fact that the browser expects to be [i]browsing[/i]. And it expects that interaction with the system is to be treated as a likely malicious attempt by the site to own your machine. Users can easily 'break out' of your app and go to browse some random site; or worse some site that sends erroneous callbacks into your C#. To counteract that you can disable all the input to the page, but you've just neutered most of the benefit of your ui.

And let's be realistic, you're not getting 100% cross platform; you're not getting 100% consistent layouts. Different platforms have different browsers, different browsers have different capabilities with different rendering quirks. Add to that the quirks of how you're tying javascript into your core language and I suspect you'll not gain too much over say... java.

Share this post


Link to post
Share on other sites
I agree with what you're saying Telastyn, but these problems can be overcome, for the most part. We can throw out the idea of embedding IE within a Winforms application. It's not necessary. We build an application platform using a layout and rendering engine, and a powerful JavaScript engine. Browsing away from the application will never be an issue because that function will simply [i]not be implemented.[/i] If the page isn't local, it doesn't load. Also, there's no reason why changes to the window have to be displayed before layout is complete. Besides, all content is local. The page load "hiccup" would be so minimal it would be negligible in almost all cases, not to mention the DOM of the page can be altered without a complete redraw. And any jarring effects of changing a window would be no more or less jarring if the window were developed using Winforms, Qt, gtk, or anything else.

Share this post


Link to post
Share on other sites
[quote name='smr' timestamp='1317392453' post='4867580']
I totally disagree. JavaScript is a very powerful language and anyone who says otherwise has either not touched JavaScript since 2003 or has never used it at all. Also, modern JavaScript VMs are very fast and even use JIT techniques to compile the JavaScript natively. No, an application written with JavaScript will probably never be as performant as the same <b>well written</b> application compiled with C or C++. But who will really care? Will anyone notice if their drop-down menu takes two milliseconds to begin animating instead of .5 milliseconds? No. Will a user notice if their application crashes with unsaved changes, likely due to some access violation caused by memory mismanagement, or if the application hangs because of some poorly written threading code? Most definitely they will.
[/quote]

The one thing JavaScript in browsers lacks is multithreading/tasking. Even thick clients in modern languages have issues with GUI responsiveness without the use of local asynchronous routines. Add this to JavaScript (no easy task), and then your browser/HTML/JS/CSS is just as good for thick clients as it is for modern thin clients.

Share this post


Link to post
Share on other sites
Great, then you're writing/modifying your own rendering & layout engine and maintaining that beast. Even less than Java cross platform compatibility.

I understand that these problems can be overcome, but until they are overcome in some nice way you've got a lot of overhead for (imo) fairly limited benefit. Or you're stuck making your entire app in JavaScript, which is simply unsuitable for most fat client apps.

And frankly the visual artifacts of page change (not DOM change) are more significant on any non-trivial html renderer (even for local content) than winforms and WPF at the very least.

Share this post


Link to post
Share on other sites
[quote name='arbitus' timestamp='1317399289' post='4867632']
The one thing JavaScript in browsers lacks is multithreading/tasking. Even thick clients in modern languages have issues with GUI responsiveness without the use of local asynchronous routines. Add this to JavaScript (no easy task), and then your browser/HTML/JS/CSS is just as good for thick clients as it is for modern thin clients.
[/quote]

Actually that's not the case. [url="https://developer.mozilla.org/en/Using_web_workers"]Web Workers[/url] enable you to utilize a kind of safe multithreading using JavaScript. Of course, no multithreading is truly 100% safe as long as one thread can affect another through some sort of shared state or resource, but web workers are a good compromise. With web workers tasks can be completed asynchronously in the background while the main thread handles updates to the UI.

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1317399586' post='4867635']
Great, then you're writing/modifying your own rendering & layout engine and maintaining that beast. Even less than Java cross platform compatibility.

I understand that these problems can be overcome, but until they are overcome in some nice way you've got a lot of overhead for (imo) fairly limited benefit. Or you're stuck making your entire app in JavaScript, which is simply unsuitable for most fat client apps.

And frankly the visual artifacts of page change (not DOM change) are more significant on any non-trivial html renderer (even for local content) than winforms and WPF at the very least.
[/quote]

We're talking about pie in the sky here. I don't think anyone is saying that we want to do all this work ourselves. For my part, I'm just saying that if such a platform existed, I'd probably use it.

And as far as the visual artifacts, I'm just not convinced. In my job I spend about 90% of my time developing software, and about 75% of that development is using HTML, CSS and JavaScript. I just don't see this as being an issue.

Share this post


Link to post
Share on other sites
[quote name='smr' timestamp='1317399808' post='4867636']
Actually that's not the case. [url="https://developer.mozilla.org/en/Using_web_workers"]Web Workers[/url] enable you to utilize a kind of safe multithreading using JavaScript. Of course, no multithreading is truly 100% safe as long as one thread can affect another through some sort of shared state or resource, but web workers are a good compromise. With web workers tasks can be completed asynchronously in the background while the main thread handles updates to the UI.
[/quote]

Web Workers are resource intensive and are not supported in the most used browsers for business applications (IE 6/7). I am talking about the issues that JavaScript has as a thick client platform [i]today, [/i]as I already know there will be a solution [i]tomorrow[/i].

Share this post


Link to post
Share on other sites
[quote name='arbitus' timestamp='1317407258' post='4867674']
Web Workers are resource intensive and are not supported in the most used browsers for business applications (IE 6/7). I am talking about the issues that JavaScript has as a thick client platform [i]today, [/i]as I already know there will be a solution [i]tomorrow[/i].
[/quote]

That's true: they are not supported by shitty old browsers. But your OP is about a hypothetical "what if" platform. We could just assume that Web Workers would be a necessary part of it.

Share this post


Link to post
Share on other sites
[quote name='smr' timestamp='1317418883' post='4867740']
That's true: they are not supported by shitty old browsers. But your OP is about a hypothetical "what if" platform. We could just assume that Web Workers would be a necessary part of it.
[/quote]

Not my OP; also, as I said, Web Workers are resource intensive and generally prescribed to be used sparingly. This is unlike a lot of the lightweight task and async options available to those developing native thick clients. Also, IE 9 is not a shitty old browser, neither is Safari on iOS.

JavaScript was never intended for thick client development, so I am not sure why you take such issue when people point out its drawbacks in an arena it was never intended to compete.

Share this post


Link to post
Share on other sites
Using a basic HTML/CSS renderer for a game GUI could be an interesting idea. Granted, there may not be any viable frameworks or libraries available currently that would make this sane (or there may be.) In my opinion, optimally, you wouldn't be using Javascript at all. You would only be using pure HTML and CSS for the layout itself. All logic would be handled by your host application (C#, C++, Java, whatever.) You could add event handlers to call functions in your host application just like you would add handlers for calling JS functions in a standard webpage.

I do some "play" projects with Javascript once in awhile. One thing I think when I'm working on JS projects is how easy and quick it is to whip up a GUI in HTML/CSS.

For this scenario, you wouldn't want to just embed a standard browser control, like IE, into your application. A lightweight HTML/CSS renderer would be better. It wouldn't have to support all the intricacies of the full HTML5 and CSS3 specs. Even the most basic HTML/CSS features would probably be pretty useful for an average game UI.

Then again, maybe I'm just completely crazy. I haven't thought too deeply about this or considered all of the implications.

Below are a few libraries I turned up after a quick search that could possibly be used.

[url="http://htmlrenderer.codeplex.com/"]http://htmlrenderer.codeplex.com/[/url] (.NET)
[url="http://www.terrainformatica.com/htmlayout/"]http://www.terrainfo....com/htmlayout/[/url] (Native DLL)

Edit: Corrected some grammar.

Share this post


Link to post
Share on other sites
[quote name='landagen' timestamp='1317391856' post='4867576']
An interpreted language like Javascript is too slow and not powerful enough to do the work expected of a thick client. I do not want to have to deal with postbacks and stateless applications either. That being said, layout and styling could definitely be done in HTML5 and css. I would still want a non-interpreted language to do all of the heavy lifting such as c# or c++. Of course, Microsoft already has XAML for c# and basically does what you are looking for only it appears to do more with layout than HTML5. I think it would be neat if it was cross-platform supported as well but as far as I know, it is not currently. I am sure the Mono team is working on it though.[/quote]

postbacks? Statelessness? HTML 4 called, they'd like their words back.

HTML5, CSS and Javascript are quite a powerful set of tools. As for JavaScript being interpreted and "slow" -- languages can be neither of these things, only [i]language implementations[/i] can. Have you heard of Node.js? Its a Javascript run-time that Google runs on their servers -- it runs a little application you might have heard of, called "GMail". Now, its a harder problem to optimize an untyped language like javascript (whether statically or JIT) but its not impossible and Node is already fast enough for Google. I'm not advocating that entire applications be written in javascript, at least not currently, but its certainly more than capable of handling the presentation layer -- it's managed all this time in the browser, and it only stands to be quicker when it can throw off the shackles of HTML DOM parsing.

Share this post


Link to post
Share on other sites
[quote name='Avictus' timestamp='1317425495' post='4867777']
For this scenario, you wouldn't want to just embed a standard browser control, like IE, into your application. A lightweight HTML/CSS renderer would be better. It wouldn't have to support all the intricacies of the full HTML5 and CSS3 specs. Even the most basic HTML/CSS features would probably be pretty useful for an average game UI.
[/quote]

This is why you have XAML, MXML, and the JSON-like JavaFX (which I assume is dead now?). While RIA GUIs are easier with HTML5 now, it is still much easier to work with a full dedicated GUI widget toolkit (and yes, why not get to use a backing language of your choice then?). However, it looks like the intent is to compile all of this down to HTML5/CSS in the future anyway, which is fine with me.

Share this post


Link to post
Share on other sites
[quote name='cignox1' timestamp='1317368689' post='4867495']
Hi all, I'm just curious: today, html(5), css and javascript with Ajax are really powerful tools to create beatiful and customizable layouts. Wouldn't it be interesting to have all this for desktop applications as well? I mean, the app GUI is just a local 'website', where controls are implemented as javascript components, and layouts as HTML/css pages. An application or os level engine will run the pages and the application interacts through events.

[...]

I think that this is a nice idea to play with, so I'm pretty sure somebody already did that: does someone know of such a tool?
[/quote]
There's [url="http://awesomium.com/"]Awesomium[/url], which I discovered last night via someone's recent GD.net journal entry. (I forget who's, sorry.) One of the things you can do with it is create an html5/css3/javascript UI with a transparent background, and then render it over your application window.

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1317393860' post='4867588']
The issue is that you can't change the html page without the visual hiccup of page load. Users don't expect this of thick clients.

I work on a winforms app whose sole control is a web user control that we call from in C# and catch callbacks from javascript. It works, it's nice for some things, but keeping things in sync is awkward. And what can be done is limited by the fact that the browser expects to be [i]browsing[/i]. And it expects that interaction with the system is to be treated as a likely malicious attempt by the site to own your machine. Users can easily 'break out' of your app and go to browse some random site; or worse some site that sends erroneous callbacks into your C#. To counteract that you can disable all the input to the page, but you've just neutered most of the benefit of your ui.

And let's be realistic, you're not getting 100% cross platform; you're not getting 100% consistent layouts. Different platforms have different browsers, different browsers have different capabilities with different rendering quirks. Add to that the quirks of how you're tying javascript into your core language and I suspect you'll not gain too much over say... java.
[/quote]

Web Applications are spreading so fast, that I suppose that people are used to Html/CSS/JS interfaces. If those GUI's can work online, with different browsers, I can't really see reasons why they shouln't be fast enought to work locally. A framework could take care of the incompatibilities, or simply, the engine can be one of the open source cross platform engines available today.

In addition, I never suggested this to completely replace native GUIs: just as an additional tool, which IMHO would provide several advantages.

And I did not mean JS to do anything else than drive the presentation (so controls, events and not much else). Everything else would be done by the underlying language (which would just need a thin binding with js interface).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this