How Can Anyone Trust HTML5?

[R. Grimes]

My question is a bit more philosophical, rather than a "how do I?" question.

We (the company where I work) had been using Flex on the front-end since 2006. I liked the idea of an AVM interpreting the bytecode in the browser so that I could truly write-once and run-anywhere without testing on multiple browsers and multiple versions within each browser, such as I had to do in my previous DHTML days. But, Adobe has kicked Flex out the door to go live with the neighbors. So, I don't really feel like it (Flex), along with FlashBuilder, has a roadmap I can rely upon.

Consequently, we looked for a new client-side technology. In spite of Adobe saying it felt HTML5 was the future of enterprise web application development, it just seemed to me HTML5 is far from delivering what Flex can do right now. Further, I have a problem committing to HTML5, which, to me, is really nothing more than DHTML 2.0. And, the reason I abandoned DHTML is because I could not rely on browser manufacturers (hello Microsoft) to not try and co-opt things by going around/beyond the W3C specs.

So, now everyone is jumping back on the HTML bandwagon, apparently suffering from amnesia as to the hell it was to make your web apps work across all browsers and their multiple versions.

Finally, my question is, "How confident are you that HTML5 will not suffer the same fate as DHTML, and we'll be stuck in cross-browser compatability hell...again?"

As for us, we decided to go with ZK. I now feel the only way to insulate ourselves from these problems is placing on the server the scripting logic that normally breaks the browser on the client side.

Very interested in your point of view.

Ron Grimes

[Elisabeth Robson]

Hi Ron,
Wow, great question and I have to admit I hadn't heard of ZK before.

I understand your concerns with HTML5 - I've spent a lot of time stuck in "DHTML Hell" myself in the past, and it's no fun. I think memories of that hell provide a compelling reason for people to use Flash and Flex to build applications, and now that Adobe is shifting strategies, this is an interesting time for groups who have invested heavily in that platform and strategy.

I think you're absolutely right that HTML5 - in its current incarnation - cannot replace what Flash and Flex currently do entirely. So I think how you choose to proceed very much depends on a number of things: what you're trying to accomplish, your core user base, and the platforms you're targeting (among many other internal things like expertise in your group, etc.).

I also hear you with regards to "trusting" the browser makers when implementing to a standard. We've all been burned before. And, in fact, just a few days ago I read an article about concerns along these very lines with Chrome! As long as we have a browser ecosystem that includes more than one manufacturer, who are obviously trying to compete, then we are at risk for browser-makers not sticking to the standard.

I do think, however, if that if you stick to what's in the standard and don't use browser-specific proprietary implementations, then things are a lot better than they used to be; ECMAScript, the standard that JavaScript is based on, has come a long way, and browsers seem to fairly consistently implement it. In addition, I think this is where libraries like jQuery can really shine; jQuery (and similar libraries) can really help hide the cross-browser issues so you don't have to deal with them nearly as much. New libraries being developed for doing graphics and animation in HTML5 with canvas and SVG also help hide the complexities and add features that will eventually approach what Flash and Flex offer. But there's a way to go on that front.

I guess I don't really have a solid answer for you. Each company has to decide which basket to put its eggs in, and that obviously means investing with time and money in that basket. So, you need to feel good about that decision. No matter which technology you choose, there are risks; as you've discovered companies like Adobe can abandon technologies, so even going with a proprietary solution doesn't necessarily solve the problem!

I'm sure I'm not saying anything you haven't already been through in your decision making to use ZK, and indeed, to use Flex previously. Anyone investing in a technology strategy pulls their hair out as they make the decision, and then later as they discover the limitations of their decision later on! :-)

Elisabeth

[Eric Pascarello]

R. Grimes wrote:
As for us, we decided to go with ZK. I now feel the only way to insulate ourselves from these problems is placing on the server the scripting logic that normally breaks the browser on the client side.

You insulated yourself by putting the scripting logic in another developer/company's hands. The server is not running the code, that framework is outputting the code onto the client.

There are plenty of frameworks that do this, you have to hope that everything you need is supported by their framework.

R. Grimes wrote:
So, now everyone is jumping back on the HTML bandwagon, apparently suffering from amnesia as to the hell it was to make your web apps work across all browsers and their multiple versions.

If you have been away from the technology, you are basing assumptions on old facts. At one time smoking was good for you and recommended by 2 out of 3 doctors!

R. Grimes wrote:
Finally, my question is, "How confident are you that HTML5 will not suffer the same fate as DHTML, and we'll be stuck in cross-browser compatability hell...again?"

Your view is the classic developer view that got frustrated back when it was rough. A lot of the things that you hate about Internet Explorer comes from a time when there were no specs/standards. If Netscape and IE never had browser wars in the early days, we probably would not have had the innovations we have today. Other browsers have adopted things that IE does that are no in the specs and magically they became part of the spec.

The way around browser inconsistencies is to drop IE6 support. Say bye to a 12 year old browser. The next step is to find a framework that fixes inconsistencies for you so you do not have to worry about it. Most people today pick jQuery, but there are plenty of other options. There are always going to be differences in rendering, but it has gotten better and the tools for debugging are leaps ahead of things you used in 2006.

In this day in age there are plenty of developers that know how to develop for multiple browsers and deal with the issues. Hire one of them to help your team gain knowledge.

By using HTML/HTML5 you are not locking yourself into a certain vendor. It will work in multiple places/platforms with little effort.

* Flex, Flash, and Silverlight dropped support for mobile, have to pray people install needed software
* Google's Dart is not going to be implemented in browsers
* private company's software, got to hope they stay in business

Eric

[R. Grimes]

Eric Pascarello wrote:
You insulated yourself by putting the scripting logic in another developer/company's hands. The server is not running the code, that framework is outputting the code onto the client.

There are plenty of frameworks that do this, you have to hope that everything you need is supported by their framework.

I think you need to do a little more studying up on ZK. Your assumptions are false. First, it's open source. Second, read up on the difference between their script and zscript tags. You'll see it's not simply a matter of producing the code and outputting it to the client. Not to be insulting, but I don't think you have any experience with ZK to be making these assertions.

Eric Pascarello wrote:
If you have been away from the technology, you are basing assumptions on old facts. At one time smoking was good for you and recommended by 2 out of 3 doctors!

Again, you're mistaken. You've made an assumption that, just because I don't currently develop in HTML5, I'm not abreast of what it takes to do so. Take a look at elladesign.com, which is cited by 1stwebdesigner.com as the best example of an HTML5 website. Just love that code ...

if it's IE9, do this. If it's IE7, do something different. If it's less than IE7, do something else.

Yeah, modern HTML5, as evidenced by the award winning elladesign.com, sure has gotten us past that cross-browser compliance hell.


Ron Grimes

[Eric Pascarello]

You add a zscript tag to the page that runs code on the server. I understand that. It also generates a chunk of JavaScript, HTML, and CSS for you that magically works and hooks into the backend code. That framework writes the widget code for you. I understand how it works and have written a few of these libraries already [and currently write one based on jQuery.]

If you did not use the library, you would have to write all of that JavaScript/CSS. That is the layer you do not touch, they write it for you. That is all I was talking about.

if it's IE9, do this. If it's IE7, do something different. If it's less than IE7, do something else.

Like I mentioned, you find a low level library that helps to eliminate most of the headache. Get a good CSS reset to make browsers render stuff the same and you are most of the way there. With modern day browser IE9+, Firefox, Chrome, Safari, Opera, there is less and less need to do hacks.

The good thing about HTML5 is once you learn it, you will be able to write apps on multiple devices/platforms without having to learn different languages.

Eric