• 0

Does HTML, CSS and Javascript technologies give an


Question

Hello everyone,

I wanted to get your thoughts on HCJ (HTML, CSS and Javascript) and why it is not yet implemented as the GUI engine by some of the industry leaders out there (e.g. Java, .NET, etc?).

From my experience I had an awesome time developing user interfaces using HCJ and the things you can design or do with HCJ are truly remarkable. Compare that to Java Swing, JavaFX, C# WPF, your experience will be polar opposite if not painful.

I am curious whether there is some kind of technical limitation that is forcing us to rely on these old GUI libraries or it?s just due to business reasons that these folks (Oracle, Microsoft, etc?) are not yet making it possible to code/design the front-end of the desktops with pure HCJ?

I guess the main questions is? why are we not using HCJ for our GUIs rather than learning something new like FXML, WPF, JavaFX, etc?? All the web applications and some of the hybrids of a desktop apps are running a browser engine which uses HCJ, so why not create a native HCJ rendering engine on a matured platform like Java, .NET, Cocoa? Thus, eliminating the need to embed a third-party web browser engine!

Adobe AIR, NodeWebkit was almost there but the libraries provided by .NET/Cocoa/Java/PHP/Python is a huge advantage to most developers. And having a native support for something is always desirable!

The Mobile world is primarily HTML/CSS anyways, so I don?t know why the desktop apps cannot use pure HCJ natively :)

Link to comment
Share on other sites

9 answers to this question

Recommended Posts

  • 0

You already have this option with Windows 8+/WP/Xbox 1, it's already native out of the box.

Obviously for older platforms you'd have to embed, say ChromiumEmbedded, the IE engine, etc if you want to do it for "classic" software, and that's usable from quite a few platforms, dotNET, Python and Java included.

Link to comment
Share on other sites

  • 0

You already have this option with Windows 8+/WP/Xbox 1, it's already native out of the box.

Obviously for older platforms you'd have to embed, say ChromiumEmbedded, the IE engine, etc if you want to do it for "classic" software, and that's usable from quite a few platforms, dotNET, Python and Java included.

 

Ah, this is interesting. I will have to look at Windows 8 and see how well HCJ is supported. For the older platforms or other technologies I am already aware of the embedded frameworks, etc... but they have huge drawbacks too. For example, the Java webkit works only on JavaFX. And JavaFX presents some serious blow to the users who run their OS on a VM or do not have a good enough system. Also, the runtimes provided by Java, Qt (let's not forget the confusing license terms), are huge! Python is cool in its own ways but the HCJ GUI is still not natively supported. You have to download hacks, etc... to make it work. My bias would be to see Python, .NET releasing its next GUI engine with the ability to design the layout using pure HCJ ;). So, if the users are still on Windows XP, they can just install the latest framework and everything works flawlessly!

 

Also, I wanted to add is that some of the embedded framework solutions have a mixbag of licenses that makes the binary distribution very confusing and limited. But if things are natively supported then we wouldn't have to worry about it. JavaFX in my opinion is already miles ahead in terms of its support for webkit, etc... but the JRE size is always frawned upon and the operating systems nowadays don't include the JRE by default. And in many cases you don't want to make your HCJ sources available to the end users. So, if these industry leaders supported it natively, compiled everything to bytecodes, most commercial developers would feel more comfortable coding apps in HCJ for the desktop!

Link to comment
Share on other sites

  • 0

It's coding for the lowest common denominator of all platforms. It's difficult to make your app look and feel native when you don't have access to any native widget that the OS exposes. You also lose all platform-specific functionality: can you code a JS app that does Direct3D? Link to third-party native libraries? Can you get administrator permissions on the machine? You're restricted to a very small subset of the things a native application can do. Plus you pay a big performance cost, Javascript performance is anywhere between 5-50% the speed of native code depending on platform.

 

So, it's always a tradeoff, what you get in convenience and portability you lose in integration, flexibility and performance.

Link to comment
Share on other sites

  • 0

I'm not a fan of HTML5 development. It's a major pain in the ass compared to working with native toolkits. HTML and CSS were not designed for applications. They were designed for document rendering, and that shows. I mean, how is it acceptable that third party CSS and JavaScript can stomp all over your stuff? How can you build non-trivial software and not lose your sanity if you don't have that guarantee? The Shadow DOM aims to fix that, and it is long overdue.

 

While there is a constant churn of new libraries and frameworks in the HTML5 space, the underlying technologies move at a glacial pace. The concurrency story has sucked for the longest time. There are heaps of shiny new layers, but the process of fixing things that are fundamentally wrong with web development - that takes ages.

Link to comment
Share on other sites

  • 0

I prefer Desktop GUI development to be honest with you. I can't stand the hackiness (imo) of CSS and JavaScript (although I find jQuery has vastly improved JS).

 

I've had fairly significant experience in both Desktop and Web development and C#.net beats the heck out of HTML/CSS/JS. Python+Qt was a bit of a chore, I'll give you that, and that's without taking into consideration its retarded licensing terms that I still don't fully understand. I'm still considered new with C# though, so perhaps the excitement will wear off after the honeymoon phase. For right now I'm really enjoying it.

 

My favorite part of Web Development is the back end, and a lot of the magic of my WebDev comes from PHP and not JS as most would expect. Mostly because I'm far more confident in PHP than I am in JS/jQuery.

Link to comment
Share on other sites

  • 0

Having been a Winforms apps developer for years, I'm currently learning HJS as my employer has decided the web is the way to go with future projects.

 

I friggin' hate it, with a passion!  The inconsistencies between rendering engines irritates the hell out of me, and don't even get me started on cross-browser incompatibilities!  If I had to use this crap for Winforms, I'd go nuts.  This stuff is designed for document rendering, not application interfaces. Whoever thought it was a great idea to start doing app UI's in it needs dragging out back and shooting.

 

With Winforms, I can drop a control on a form, position it exactly where I want, control its appearance exactly how I want, know that its appearance will always be consistent with the rest of the app and environment its running in, and that it will always behave the same way.

Link to comment
Share on other sites

  • 0

Having been a Winforms apps developer for years, I'm currently learning HJS as my employer has decided the web is the way to go with future projects.

 

I friggin' hate it, with a passion!  The inconsistencies between rendering engines irritates the hell out of me, and don't even get me started on cross-browser incompatibilities!  If I had to use this crap for Winforms, I'd go nuts.  This stuff is designed for document rendering, not application interfaces. Whoever thought it was a great idea to start doing app UI's in it needs dragging out back and shooting.

 

With Winforms, I can drop a control on a form, position it exactly where I want, control its appearance exactly how I want, know that its appearance will always be consistent with the rest of the app and environment its running in, and that it will always behave the same way.

 

Hi,

I do agree that HCJ has some rendering issues on different web browsers and despite the efforts by W3C the web browsers are not adhering to certain standards (e.g. browsers that still add unnecessary padding to the HTML tags).

I wasn?t suggesting to use HCJ in a web browser environment but actually create an engine that behaves or works like WinForms. You know how you drag and drop the controls on a WinForm and mess with its style? And no matter whether you are on Windows 7, 8 or 10? it still ends up looking the same? I am suggesting the same thing. If Microsoft created a technology that rendered HCJ as a Desktop app then it could really speed up the process of designing GUIs that not only looks good but does some really cool things.

I am aware that animation and 3D stuff doesn?t blend well with HCJ like WinForms, etc? but what are the odds your application uses serious 3D or animation for all its projects?

As FloatingFatMan mentioned, since most companies feel that the web is the way to go then why can?t we just use a common rendering engine (similar to WinForms) and create desktop apps out of HCJ :). From my experience, convincing people to launch a desktop app is much easier than convincing them to let go of their favorite web browser just because your web app uses non-standard HCJ.

There are certain solutions out there but they are basically ?crap? in my opinion for the following reasons:

1. Codes are exposed. I want to compile my HTML, CSS and Javascript?s to byte codes, period! No exception!

2. I want Webkit. She wants Tridant. Oh, why not Chrome? Just like on Java you are pretty much stuck with Swing or JavaFX, on Windows you are stuck with Winforms/WPF, etc? So, I feel that this constant need to make your applications work in all web browsers is distracting too many people from being productive. It drives the developers nuts, and customers are frustrated when the app doesn?t work on their favorite web browser whether it?s due to bad coding or some stupid security settings.

FloatingFatMan I do want to add that if cross browser issues is something you are struggling with, consider incorporating a cross browser compatible framework. EXTJS, Bootstrap are my primary choices when I?m building a cross platform app.

I am not suggesting Microsoft or Java or Apple do away with their existing technologies but I feel that people can build very good looking apps in a short amount of time with HCJ than programming languages that require more technical commitment. Ever tried customizing a JAVA Swing theme? Now, compare that to a HCJ document.

Like I said Adobe AIR is already there but the issue is that the codes are still exposed. If they would compile the actual HCJ codes or keep it tightly hidden/secured from the users, then I probably wouldn?t even start this thread.

Link to comment
Share on other sites

  • 0

Oh, I'm not "struggling" with the cross-compatability issues... I can code around them once I find them; but there wouldn't BE any sodding issues if the browser makers would quit doing their own ###### and stick to the standards!

 

As far as using HCJ for Winforms apps, MS have "decreed" that this is how ModernUI apps will work.  It's here now and it's not going anywhere.  With the improvements in Windows 10 allowing proper windows apps instead of full screen, it's going to be the way forward from now on.  

 

For actual Winforms itself, this is always going to be as it is now.  MS tried alternatives with XAML and Silverlight, but just how many commercial apps do you see out there that use either of these technologies?  They're dead ends, and MS know this because they've essentially killed them off.

Link to comment
Share on other sites

  • 0

WPF is still the best supported GUI framework for Windows desktop applications. It gets modest updates with each version of .NET - not much evolution but healthy maintenance yes. Killing WPF would essentially mean killing desktop apps and since Windows 8.1 Microsoft has made it quite clear that desktop apps aren't going anywhere.

 

Silverlight, well, that's another story.

Link to comment
Share on other sites

This topic is now closed to further replies.