More Commentary on Windows 8 and HTML5

Arstechnica has another feature on the aftermath of the Microsoft’s game-changing Windows 8 + HTML5 announcement.

First, a quote:

The lack of broad platform support meant that Silverlight could never quite rival Flash on this front, but it was there, and it worked well on those platforms that were supported. With Internet Explorer 9, however, Silverlight took a back seat. HTML5 became the way forward. If Silverlight were to be used at all, it should only be used for those things that HTML5 couldn’t do very well, such as streaming video. For anything else, the message was that developers should use HTML5.

Microsoft did have a point. If you’re really wanting to target people on any platform, HTML5 is the way to go. For Web-facing applications that don’t have any special needs such as DRM video, HTML5 is the long-term bet.

Excuse the smugness, but I’ve been saying this from the day Silverlight was released (you know, because it’s basically Flash and we all know how everyone loves the Flash website experience…).  It’s plain silly to suggest using Silverlight for anything other than an intranet environment where DHTML could do the job.

While Peter Bright opens the article with a discussion of the teeth-gnashing that many Windows platform developers are going through, I — for one — could not be happier that we’ll finally see HTML5 on the desktop.  I think it’s a beautiful thing  Finally: the richness and variety that we’ve seen in web based applications will manifest on the desktop because the skills and techniques that folks have used for over a decade to build beautiful web applications will now finally translate.

However, I do disagree with a few points that Bright makes:

Where Silverlight programs can deal with buttons, icons, list boxes, tree views, and other interface controls, HTML5 applications must generally deal with boxes of text, with no higher-level concepts to work with.

There are a few points to address here.  The first is that — obviously — HTML has buttons and icons (<a class=’icon’><img /></a>)  😉  The second is that, to a large degree, deficiencies in the area of higher level UI abstractions in the DHTML world have largely been handled by any number of open-source UI script and widget libraries which provide even better alternatives to those on the Windows native platform.  jsTree is one example of an excellent tree view library that is incredibly rich.  Third, having worked with tree views via DOM and tree views via WinForms and WPF, my personal feeling is that it is many, many times easier to deal with the creation, manipulation, and styling of HTML than it is with Windows forms controls.  And finally, I believe that Bright misses the point of HTML+CSS; it’s really not much different from the concepts put forth in WPF and Silverlight: that of applying visual styles to otherwise generic controls.

I also take issue with this assertion from Bright:

Another weak area for HTML5 is tooling. Design and development tools that work with HTML5 are not as developed or as robust as those that exist for Silverlight, making HTML5 development more complicated

Uh….HELLO?!?  The term “HTML5” is a bit misleading as it’s really nothing more than HTML4 with some new tags (and some new skills required to take advantage of those new tags).  Why are current HTML tools insufficient?  I’m not getting his point here as HTML development tools have been around for WAAAAAY longer than Silverlight or WPF development tools.

Bright closes the article with more doom-and-gloom and a bit of hope for going back to the good old days of the same-old, same-old:

The prospect of being stuck with HTML5 and JavaScript for their development is encouraging them to jump ship.

The details aren’t clear yet, but next time we’ll take a look at the pieces of the puzzle we have, and we’ll learn why Windows 8 won’t be a HTML-driven horror after all.

Apparently the reaction of Windows platform developers to the news that Windows 8 will promote HTML5 and JS as one alternative to building applications for the desktop

Contrary to Bright’s doom-and-gloom, I’m fairly optimistic and I really, really, really hope that Microsoft sticks to its guns here.  I can’t be the only person who, while working with WPF, longed dearly for a jQuery-esque framework to traverse and manipulate XAML the same way that jQuery enables in web applications.  I can’t be the only person who’s turned to using the WebBrowser control in Windows applications from time-to-time because it offered the simplest way of handling complex document layouts and, in some cases, interfaces that would require developers to resort to low level drawing of rectangles and custom painting of the UI controls and dozens to hundreds of lines of code that could be accomplished by HTML in a few lines of markup.

As a developer who has worked with DHTML, WinForms, and WPF, I — for one — look forward to an HTML5-on-the-desktop future.

PS  — Is it just me, or are MS developers — generally speaking — a particularly whiny bunch that can’t handle radical shifts in technology or methodology very well because Microsoft and Visual Studio has been holding their hands and enabling their ineptitude for so long?  The comments on that Arstechnica article shows the straight FEAR that this news has instilled in the hearts of those legion developers.  I love it.

A couple of commenters hit it right on the mark:

slogger: If you have a CS degree and you can’t functionally use a new language within a couple months, you fail and are worthless. Switching to preferring some sort of JS API is hardly the end of the world.

jaman4dbz: First of all: Man up MS developers. This is why you should pay attention when you get your formal education. If you did you can switch languages easily. The language and libraries should not matter much.

Maybe now all those retarded MS developers can learn some theory, rather than what buttons to hit in their program maker.

deet: Nobody’s talking about using HTML to write drivers, for fucksake.

emn13: I’ve written apps in Silverlight, WPF, and HTML+javascript. They obviously have their own pro’s and con’s, but this articles’ assertion that Silverlight/WPF are more high-level is complete nonsense.

One of the huge problems of WPF/Silverlight is that they’re very *low-level*. WPF doesn’t have a sane styling system. In fact, styles are implemented as effectively side-effect laden getters+setters. This means it’s quite hard to separate the content and behavior from the presentation.

WPF comes with a widely-used grid-based layout scheme (as opposed to HTML’s tables). This is nice in some ways since it’s easy to precisely specify where something goes on that grid (i.e. it’s low-level). It’s a terrible pain to use by hand however, since grid-alignment is done by row/column *number*; moving things about generally means renumbering everything.

WPF/Silverlight as general UI-specification language, I’d say: good riddance. And as a special-purpose tool to make particularly intricate, tightly controlled UI’s? Well, it’s not disappearing, is it; if you want more control but with helpful automatic layout system to do the basics, WPF/Silverlight will still be around.

This comment by bouncing deserves its own shoutout:

Hmm. Peter Bright makes an interesting case.

In fact, a crack team of usability experts, computer science PhD candidates, and Seth Godin impersonators recently compiled an exhaustive list of native apps which are, to any reasonable observer, far superior to web apps:

• Photoshop
• Various CAD programs

Although only two native Windows apps that do not suck were ever found, researchers believe the third “non-sucky .exe file” may one day be discovered. Unfortunately, locating the mythical trifectapp has proven a daunting task, as finding it requires digging through tens of thousands of incredibly crappy, hard to use, slow, confusing, mind-numbing, rage-inducing, serial-killer-inspiring “line-of-business” apps that IT managers force their interns to use on their behalf after booting a USB thumb drive flashed with a version of Windows 98 that’s compatible with the version of Microsoft’s far-superior C++ libraries the IT department develops on.

Perhaps Peter Bright, who wrote this passionate defense of the unnamed third native application which does not suck will tell us as to what, if any, business application is better in native Win32 than HTML 1.0. While he’s doing so, a 22 year-old Ruby programmer will create a superior product using “primitive” technologies in exactly 1/100th of the time it takes a team of Certified Win32 Development Professionals to follow a stack trace in Visual Studio.

I’d also like to point out one of the stupidest comments that simply perpetuates this myth that JavaScript is inadequate:

VoodooTrucker: Is JS as mature as C#? No way. In fact its totally painful, which is what I think developers are afraid of. No strong-typing, no obfuscation, no refactoring, no generics, no direct casts, no direct disk access, minimal properties, no LINQ, no IEnumerable, no interfaces, crappy inheritance, crappy dictionaries….

This kind of makes me chuckle a bit as my own perspective has been that as C# has developed from 1.0 to its current iteration, it has taken more and more from JavaScript.  Take collection and dictionary initializers in C#.  Looks familiar?  Because it was already done in JavaScript ages ago.  Trucker’s assertions are also completely off.

It’s true that because JavaScript is interpreted, there’s no obfuscation, but there is typing in JavaScript, you can clearly refactor in JavaScript, you don’t need generics in JavaScript because an array can hold anything, you can perform direct casts by creating a new instance of a type (i.e. var five = new Number(“5”)), no direct disk access is a matter of the platform/runtime rather than the language itself, no IEnumerable is a misnomer because really, you can iterate over anything in JavaScript, crappy dictionaries make me laugh because JavaScript dictionaries are incredibly sexy and flexible.