Apparently HTML5 applications are the best thing after sliced bread.
HTML5 is the first platform any mobile vendor supports: iPhone, Android, Windows Phone, BlackBerry, Symbian. All of them.
Windows 8 is said to promote HTML5 as the preferred application development solution.
I used to look kindly at that. But about a month ago I started to get worried: is HTML5 good for everything?
Long-lived applications
In military, industrial, warehouse management, medical, etc is not rare that bespoke applications are developed and stay in use for many years (and I really mean many: 10, 20 or even more!) with barely an update. It’s not rare that those applications only receive very small updates once very 5 years. Those applications, not Angry Birds, are what keeps the world running: troops know what supplies they can count on, iPhones are manufactured, FedEx is able to deliver your package and your doctor is able to check your health.
But now that everybody seems to be moving to HTML5 webapps, what happens when my warehouse management application is a webapp and the additions in the newest browsers make the webapp no longer work?
Are vain upgrades the future?
Say my webapp is released in 2014 and it works fine with Firefox 14.0 and Chrome 26.0, the newest browsers when I release the application in 2014. Fast-forward to 2020 and Firefox 14.0 and Chrome 26.0 do not even install on Windows 10 computer! What’s the solution?
Should the customer pay for a huge update and redesign to make it work with Firefox 27.1 and Chrome 41.0 in 2020?
A virtual machine with Windows 8 and Firefox 14.0? A portable Mozilla Firefox 14.0 on Windows 10 in 2020 to be able to use that line-of-business application that only requires a small update once or twice every 5 years? How are the virtual machine and/or Portable Firefox 14.0 different from or better than a fat client? What’s the advantage? I’d say none!
Native applications usually do not have that kind of problems because APIs are much more stable. You can still run Win16 applications on Windows 7!
You don’t believe me? We may soon be developing for 76 browsers!
While HTML5 may be fine for applications which are updated very often, it makes me feel very uneasy to see it used in environments where applications will be rarely updated, such as SCADAs, warehouse management, control system, medical records, etc.
A solution is needed
It looks like that choice of technology is going to make those applications much more expensive in the medium and long term, paying for “adaptations to new browsers” (sorry, I resist to call “update” or “upgrade” to something that adds zero value other than being able to run on a newer browser).
Or maybe it’s about time to define actual “HTML5 profiles”. ACID3 seems to be too weak of a profile: two very different browsers may pass ACID3 yet a webapp would work with one browser and fail with the other due to bugs, missing features/added features, etc.
Something needs to be done.
The HTML5 spec is designed to standardise and document quirks and oddities of HTML parsing that date back to the oldest versions of Netscape and Internet Explorer, nearly a decade ago. The HTML5 doctype just says “HTML” not “HTML5” because the WhatWG believe that every future change needs to be compatible with existing content.
It’s not just embedded and bespoke applications that would be affected by an incompatible change in browsers; the entire Internet is filled with personal homepages and corporate sites and other documents that depend on things being the way they currently are. Even if most users don’t care about most of those web-pages, there’s a lot of users that each care about some of them, and any browser that changed its behaviour such that it could no longer render existing web-pages would very quickly die off.
So yes, I wouldn’t worry about the long-term compatibility of HTML5 – any system you make that goes live in 2014 will be a decade younger than most of the websites that browsers are worried about.
In theory you are right.
In practice, you are not
Browsers do break compatibility. That’s been a fact in the past, is a fact now and, unfortunately, will still be a fact in the future. When looking for a JavaScript library, first thing you do is looking for the features you want. Second thing you do is checking compatibility with different browsers. There is a reason why every HTML5 toolkit out there is advertising “works fine with Firefox 3.0-9.0, Chrome 11.0-18.0, etc”.
Webpages (Facebook, MSNBC, Google,etc) adapt quickly because they have millions of users and they have a dedicated development team. The kind of webapps I’m talking about do not have a dedicated development team, thererefore they are not updated daily. But even when they do, they usually are not updated by the customer because it takes time and is a risk. Why should the DHL upgrade their perfecly-working app for delivery men just to support a new browser, no other added functionality? It’s a huge risk for no real benefit!
It smells like a wrong design choice. If such a system is designed to operate for the long future, it would be unwise to rely its usefulness in the “run-time environment” that does not last that long.
If the goal is to leverage HTML5 for other reasons (faster development cycles, leveraging existing rich frameworks), there is a solution that always exists: hybrid apps.
Ariya,
The problem is this is not always a “design choice”.
Many customers are requiring webapps because they have this illusion that “webapps are better just because they are webapps”.
We have been trying for years to convince customers a webapp is not the right choice for a train control system that lasts for decades with virtually no updates. We started developing the webapp version two months ago. It was that, or no more sales in the future.
And no, there is no other reason to use HTML5 in this kind of applications. Qt/C++ or WPF/C# are lightyears ahead for this kind of applications.
So WPF/C# doesn’t update and break backward compability?
You need to rely on technics that has been around for long. You should rely on older technics in web browsers, as it will not change as fast as the newer thecnics. Use plain forms, not AJAX submited forms. Rely on the server giving and handling user events, not the client. You have not much controll over the client, unless you specificly specify version of components in clients.
So plain simple HTML, even in modern web browsers.
So WPF/C# doesn’t update and break backward compability?
.NET is the prime example of a platform that does not break compatibility.
If your application is compiled for .NET 3.0, it will always execute against the .NET runtime 3.0 and never change behavior.
Microsoft got sick of the “multiple DLLs with the same name but slightly different behavior” game at least a decade ago. What they do since DirectX 7 is they coinstall all the different versions, much like soversioned libraries on Unix.
So yes, you are 100% wrong.
Source compatibility is a different issue, and it’s not what I was talking in this post. Not at all.
In what way is “will always execute against the .NET runtime 3.0” different from “will always with with $old_browser”? What makes you think it’s any easier getting the .NET runtime 3.0 running on a modern Windows release ten years from now than getting an older browser working?
I do maintain old software (15+ years, laboratory equipment) and I really don’t see the benefits you speak so highly of here. Care to enlighten me with some real-world examples?
I don’t see the problem. If you don’t want to depend on the browser, ship your web app in a thin native layer that loads it in a web window. There you go, one fixed version of Webkit that will never change.
How is that better than a fat client? It is not.
Why develop a webapp, then? Native applications are easier and faster to develop and run.
I can see a bubble here, and people will only notice years after they have made their investment.
It’s not better, it’s just another option.
The point is that your central complaint of having to support multiple browsers is invalid. You don’t if you don’t want to, and it’s fairly trivial to not use a browser.
As for advantages? Well as a web app you have the option of doing both. You can migrate between a true webapp and an installed web app very easily.
Sure native APIs are more powerful, but for certain apps that’s not needed.
I don’t see the problem with HTML5 compared to other GUI framework. See what changes happened to other frameworks: Transition from QT 3.x to 4.x from Trolltech to Nokia and then dropped by Nokia. GTK 2.x deprecated and transation to GTK 3. MFC no longer developed by Microsoft, instead transition to WPF.
In worst case a newer version of the framework can’t compile the old code. But have you ever seen a website, that was unable to be shown by a webbrowser?
Your comparison is wrong.
HTML5 is comparable to WinAPI or .NET CLR, not to Qt or Gtk.
PhoneGap, Sencha, etc are comparable to Qt or Gtk. Except they do not compile to code which runs on a stable API, but they run on browsers, which are a moving target.
See the problem? The webapp is not updated but the browser is, therefore at some point in time (not too far at the pace new browser versions are being released) the webapp does not support the newer browsers.
In the case of native applications, neither the application nor the platform it runs on are updated, so there is no problem.
So .NET has not been broken?
HTML is a good choice. Latest and greatest are not. And if you follow the specs, less browsers will have bugs in the specifications.
So .NET has not been broken?
No. See my answer above.
I agree that the longevity of web apps is an issue for concern. Perhaps VVms have a role to play in keeping them running.
This whole argument stems from the fallacy that operating system APIs are somehow fundamentally more stable than Web APIs. I don’t actually see any evidence presented to indicate that a standards-compliant Web page written at some point in the past no longer works because someone changed the standard: indeed, as Screwtape suggests above, a major goal of HTML5 is to ensure that pages which already work continue to work as they were intended where possible.
– Chris
Case in point: VMware Console.
I installed it 5 years ago and it does not work with any modern browser. I keep a Portable Firefox 2.0 just to be able to admin this.
On the other hand, I can still run Windows 16-bit applications from 20 years ago on my Windows 7.
So yes, operating systems APIs *are* more stable than web APIs. And a lot more.
Another example: Solaris. You can take a Solaris 2.x driver from 20 years ago and it will still run on Solaris 11.
By the way, operating system APIs are more stable even if only because a new version of Windows, Mac or a “major” version of Linux is only released every 3-4 years.
Browsers, on the other hand, are being updated every 4-5 months. Crazy.
How much Linux operating system API has changed between 2.2.x and 3.2.x versions?
A lot…. but not a problem
But application programmer does not need to relay to operating system API’s at all, only important is to focus to software platforms or system programs and libraries API’s.
Like how much UNIX API’s has changed since 1970?
You can still run scripts and compile with GCC that time programs.
Next time when Linux operating system jumps one marker from 3.x to 4.x…. It has again changed a lot but it is still compatible by most ways.
And there is LSB (Linux Standard Base) what is designed for Linux operating system so every system program and software platform are available to be used by higher layer software at least 6 years and it can be then easily be modified to be kept still when compared to browser (what is just one application program running top of software platforms, using system programs and libraries and all those ran by operating system many layers under) and “web app”.
The whole “web app” is just marketing skim to sell and re-sell to customers what they paid in the first place.
Even that WWW is two decades old technology, we are even today having lots of problems with it.
Even when it comes to E-mail, it is as well problematic when it comes to HTML emails instead just text emails.
Right now there is no HTML5…. it is not ready and it will take long time (in IT timeline) to get it as standard. Developing now anything for it and releasing is just stupid.
The old UNIX philosophy “Everything is a text file” is even today more valid than then.
We should forget all kind HTML formating, move away from runtime scripting and back to compiled and effective binary low level systems.
Like how many layers there are between operating system and application program on typical modern computer? Too many…. And the complexity is located at upper layer, where programmers has been playing like kids in sand box last 15-20 years.
Don’t confuse the internal Linux Kernel Apis and the userspace apis here. The internal apis will change for almost every release but the userspace api will not, except for new added functionality!
You should be able to compile a really old application with a current linux and it should just work.
I have exactly the same opinion with the too many layers problem. We got way too high level. I think things like scripting is good for business logic, but not to write libraries that will be used by another higher level app adding another level of complexity. Then add the clustering and cloud computing and you get complexity on a level where it will be hard to track down problems.
Whenever people espouse “HTML5 for everything” they seem to forget that it has no real threading model. Web Workers don’t count.
We’re supposed to be past the point where users will put up with blocking UIs.
I understand what you say, I have worked with SCADA for 20 years and there are factories that are still working with old systems.
For years, the problem was hardware and communications, thanks to the vm I keep running some of them. Any modification is slow, difficult and expensive.
I have the same doubts about the future of HTML5.
“ACID3 seems to be too weak of a profile”
Maybe because Acid3 has nothing to do with HTML5.
It only tests DOM, CSS2, SVG, HTML4 and a few CSS3.
This argument is silly. I can take _any_ modern browser and load up the page to the HTML3.2 spec ( http://www.w3.org/TR/REC-html32 ). It looks almost exactly the same as it did in 1997. All of the elements described on it still work as described. That’s fifteen years ago.
I can also bring up pages older than that (e.g. this form http://cgi-lib.berkeley.edu/ex/fup.html ) and they also work _perfectly_.
HTML5 will continue to work in all future versions of browsers, too. Javascript library versions (which appear to be your complaint) *don’t count* because they’re not HTML5, but old versions of JavaScript also *continue to work the same* in newer browsers, because Javascript as a language has deprecated almost nothing over the years. Let’s look at the complete list:
Objects
=======
Property: __count__ and __parent__
Methods: eval
Functions
=======
Properties: arity
Wow. That’s it. But as I said, JS isn’t the problem, because your local app could have been written in it, too, and then any browser problem would also mean that you need a version of the toolkit compatible with your JS.
You know why none of the complaints you’ve laid out matter? For the same reason that straight C from 1990 still compiles. The only problems we have ever had with web apps are the ones that were sloppily written for a single version of a single browser, counting on the non-standard features, which generally means the Netscape 3 to IE 6 era. IE 6 was especially heinous, as we all know.
In short, write standard code and it will continue to run for decades. This goes for both local and web apps.
It’s a funny thing to hear after spending whole day yesterday upgrading jQuery and other javascripts at a client’s site because the ones installed 2 years ago don’t work with latest IE or iOS anymore. It’s not a misalignment by two pixels, the app was fundamentally broken.
This is happening every 6-12 months – random HTML/JS apps stop working and need upgrading. Luckily for me, I’m the one making money on this, not the one having to spend it for no good return.
If they all use well-defined, open, cross-vendor standards, then there shouldn’t be any problems, and those apps should work fine for most stuff you can do.
The real problem is that the hyped word “HTML5” actually means something different for just about any vendor putting it on their flags. Many even include a lot of proprietary APIs in that. So far, I’m not sure if anyone other than Mozilla actually means open, cross-vendor standard when talking about this buzzword.
Unfortunately this holds true for native APIs as well. We are experiencing the exact same problem with mission critical applications that we have developed a mere 5 years ago using… Qt3.
We are a research lab. We distribute our code under the GPL. Dozens of labs throughout the world are using our applications and have come to depend on them. Unfortunately, our applications can no longer run on e.g. the latest Kubuntu, which has abandoned Qt3 compatibility libraries. We do not have dedicated developers to port the code to Qt4.
Worse, even Qt4 is already becoming obsolete: I understand QWidgets will no longer be the main focus in Qt5 and later versions.
Years of work (and our future research) are at stake, and we do not know how to proceed (keep outdated virtual machines?)
Any suggestions or helpful contacts are welcome. Thanks!
Qt is not native APIs, therefore all your answer is wrong in the first place.
You are talking about source compatibility, which is a completely different problem. Source compatibility does not bite the final user: it bites the developer. And it only bites the developer if a new version of the application is needed.
In the case of native applications, “I need a new version” means “I need a new feature”, which would justify some investment.
What I am talking about this my post is about an already existing application (i. e. something akin to “binary code”) which stops to work because the runtime platform (the browser) has changed. Totally different from source compatibility problems.
Also, Qt 3 was released in 2001 and support terminated in 2007. Qt 4 was released in 2005. Writing a new application using Qt 3 in 2007 was a very wrong decision.
But as I said, source compatibility is a different problem and not was I was talking at all: your Windows 32-bit Qt3 application from 2007 still runs perfectly on Windows 7 64-bit and will run perfectly on Windows 8 in 2017.
My point was not to argue against your post about HTML. Rather, it was about how the same problem can occur with native C++ apps, and more precisely how this happened to *us* as both developers and users.
More importantly, it was an opportunity to ask for advice about how we can handle this situation. As a KDE/Qt insider, you may have access to helpful information and/or contacts. Thanks for your help.
Below, I provide more detailed explanation of my former comments.
> Qt is not native APIs, therefore all your answer is wrong in the first place.
I agree that this is true for Windows or MacOS, but as far as KDE is concerned, isn’t Qt is a native API?
> Source compatibility does not bite the final user: it bites the developer.
Of course, but in the end the user is also bitten because the application no longer works if there is no developer to port the existing code. In our case, the developer moved to a different lab: we are left with apps that we may no longer be able to install on future machines, when hardware requires more recent GNU/Linux distributions that do not ship KDE3 libs.
> And it only bites the developer if a new version of the application is needed.
In our case, it is the same “old” version that no longer works.
> What I am talking about this my post is about an already existing application (i. e. something akin to “binary code”) which stops to work because the runtime platform (the browser) has changed.
I believe this is also what I am talking about: the very same binary no longer works because the libraries are no longer provided.
> Also, Qt 3 was released in 2001 and support terminated in 2007. Qt 4 was released in 2005. Writing a new application using Qt 3 in 2007 was a very wrong decision.
Actually, work started much earlier, in 2002, way before Trolltech made Qt4 available.
As a side note, at the time a colleague indeed called this a “wrong decision”, because he believed you should never use toolkits as support for toolkits vanishes too quickly (he used to code directly against X libs).
> But as I said, source compatibility is a different problem and not was I was talking at all: your Windows 32-bit Qt3 application from 2007 still runs perfectly on Windows 7 64-bit and will run perfectly on Windows 8 in 2017.
This is good for Windows users. But our programs are GPL and run on GNU/Linux, and unfortunately our binaries no longer run e.g. on current Ubuntus.
Again, my goal is not to argue. I saw this post as an opportunity to mention the problem we are facing, and ask for help and suggestions.
as far as KDE is concerned, isn’t Qt is a native API?
No, it’s not.
To KDE, the native API is POSIX + X11/Wayland (Unix), POSIX + Cocoa (Mac), WinAPI (Windows), etc.
we are left with apps that we may no longer be able to install on future machines, when hardware requires more recent GNU/Linux distributions that do not ship KDE3 libs.
Sadly, operating systems form the Unix family tend to focus on source compatibility instead of binary compatibility. Solaris is the exception. This is one of the reasons there are very few shareware developers and microISVs developing Linux versions of their sofware, even if they are using Qt or Gtk on Windows and Mac: it’s not easy to provide a binary that works on all distributions (Autopackage and Listaller make this easier, though, you may be interested).
If you want long-term binary compatibility, you should distribute compiled libraries yourself. This is what Adobe does for Flash, for instance: they compile their libraries with RPATH/RUNPATH, provide wrapper scripts that set LD_LIBRARY_PATH, compile against an old version of glibc (libc6 promises forward-compatibility), etc. Maybe that’s what you’d need to do. You can see an example of this in the scripts that build Qt Creator, for instance.
A quick solution for you now may be to use KDE3 libraries from Trinity (the continuation of KDE3).
If you need more details, do not hesitate to contact me directly over e-mail.
he used to code directly against X libs
Crazy.
Developing any serious application using only X libs directly is a nightmare.
You may need to mix some bits of low-level X11 code in your Qt/Gtk/etc code, but only X? I’d need more information about the project but at first sight it looks very wrong.
Thanks for all this interesting and helpful information.
> If you need more details, do not hesitate to contact me directly over e-mail.
Yes, I would definitely like to contact you over email. I do not know your address though, but since I had to enter mine on the site to post a comment, could you please send me an email so I can reply?
> Crazy. Developing any serious application using only X libs directly is a nightmare.
I can only agree, and this is why we decided to use Qt ;o)
Pingback: Programa 2×13 – Motores libres para juegos viejunos | Pánico en el Núcleo
Pingback: Inyección de dependencias en Javascript (y otros lenguajes dinámicos) « Koalite's blog
What about Line of business apps that were written on windows 95, or windows 3.1. Or DOS?
Your argument just doesn’t hold. The world changes and people expend effort to update those systems.
Of course a web app is a poor choice for a warehouse management system in any case, but even if it were the right choice, I have far more faith that html5 will be around in 20 years, and still run a correctly-developed web app from today, than will be the case with apps for iOS, windows8, gnome-linux, mac OS, etc etc.
On top of that there are ways to code you app so that it uses a conservative portion of the specifications.
Jack,
Believe it or not, those DOS, Windows 3.1 and Windows 95 applications still work on Windows 8, which proves my point: native applications live longer thanks to native APIs being more stable (broken less frequently).
Solaris’ ABI compatibility is astounding, with device drivers written 15 years ago still working on the latest version of Solaris.
Microsoft has a dedicated team for backwards compatibility. Raymond Chen is a living legend:
http://blogs.msdn.com/b/oldnewthing/
You would be surprised to know how many LOB applications have not been updated in 10, 15 or 20 years. Damned if I’m not seeing people accessing 3270 applications at least once a week.
When someone writes an piece of writing he/she maintains the thought of a user in his/her mind
that how a user can know it. So that’s why this piece of writing
is perfect. Thanks!
Fabuloso porfin un sitio donde se ve lo mejor y te puedes enterar de
cosas nuevas y comentar
Here is my web site :: samsung tv led 46