Jump to content
  • Advertisement
Sign in to follow this  
cignox1

HTML based GUI for desktop applications

This topic is 2537 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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 browsing. 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 not be implemented. 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

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.


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

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.


Actually that's not the case. Web Workers 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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!