Category Archives: HTML5

Book Review: The Modern Web

After reading The Modern Web: Multi-Device Web Development with HTML5, CSS3, and JavaScript (Peter Gasston, No Starch Press) I am glad I am not a user interface developer. Over the years HTML has evolved into an entirely different beast from 5-10 years ago. That said, the book is excellent at explaining all the options you have in HTML5, CSS, and Javascript to create good looking, responsive, and adative web applications. Peter Gasston managed to make the book easy to read through the writing style and simple examples that effectively demonstrate what a feature is about and how it works. Despite the simplicity, the samples are very detailed.

Besides meticulous explanation of what a feature does and how it works, Peter Gasston also discusses the material at a higher level, giving you insight into why and when you would want to use certain features, and when there are multiple options which one to go for in your particular situation.

One thing I particularly like is the appendix at the end of every chapter pointing you to more reading material related to the chapter’s content. The book in itself is already very useful as a reference, but this makes it even more useful. Even though it works very well as a reference, I recommend reading it from cover-to-cover to get a good understanding of the possibilties. You can do that at high speed, and then later use parts as needed.

Book Review: Programming Windows® 8 Apps with HTML, CSS, and JavaScript

Windows 8 App development is a must have skill if you favor the Microsoft platform, and if you want to learn how using HTML, CSS, and Javascript (as opposed to C#), Programming Windows® 8 Apps with HTML, CSS, and Javascript (Kraig Brockschmidt, Microsoft Press) is the book for you.

The book is written in tutorial style, encouraging to learn by working along with the author. This is backed up by detailed explanation of what’s going on and why this is important. The book covers a lot of ground, from the anatomy of an application to using device capabilities, audio & video playback etc. I personally don’t like the “trying to be funny” writing style of the author, but it wasn’t too annoying considering the wealth of information and good explanations.

Book review: Building Hypermedia APIs with HTML5 and Node

Building Hypermedia APIs with HTML5 and Node (Mike Amundsen; O’Reilly Media) is an interesting little book. It covers designing an online system that operates well in a browser, but works equally well when talking to
from another type of application, which also has positive impact on automated testing. The strength of this book is absolutely the design theory, which is explained very well. The theory applies to pretty much any web development platform, which is where the weakness of the book comes in. If you are not an HTML5 or Node developer, and many of us aren’t, reading through the practical part of the book is somewhat tedious. That said, the book is only 244 pages, and the theory is an easy read. That means that if you are only interested in that you can get through pretty quickly. The examples in itself are simple, but already add up to quite a bit of code you need to wade through. Understanding all that’s going on takes a while.

Is HTML dead?

Yes, HTML is great. HTML5 (now just known as HTML) is going to be great. It will finally bring that much needed functionality it’s been lacking all these years, and cross-platform to boot. All the major browser vendors are saying HTML is great, and that their browser supports it best. So what could possibly be wrong? Well, for one the browser really seems to be an out-of-date mechanism to provide rich functionality. As an application platform it’s coming apart at the seams, because users want applications that work awesome on their device of choice. Forget the clunky, lowest common denominator browser-based interface, users want Apps with a capital A!

So while one side of the industry is focusing on standardizing on HTML, the other side (within the same companies) is moving in an entirely different direction. The amazing number of apps available and the growth rate in the Apple AppStore, and the Android and Windows Phone equivalents, is the best evidence that this is actually working better. Cross-platform? Forget it! Cross-platform is slow(er), one size fits all, and most important… not sexy.

Don’t underestimate the importance of being sexy. Let me explain by example. The Dutch government has all laws published on the web at That means it works in all modern browsers on all platforms, including tablets and phones. There’s no flash involved or anything, so it is truly cross-platform. Also, this is very much in line with efforts of recent years to have the entire government use open standards and open source (see NOIV at With mobile touch devices on the rise, the user interface of might need an update to be more suitable to touch and smaller screens. Since the website is all HTML, CSS, and JavaScript, the obvious and NOIV route would be to make adjustments to suite the upcoming devices. But what happened instead? An iPad App was built. Is this a logical choice? Nope, not even close. Even if you don’t look at NOIV and look at reach. The website has a far wider reach, and if you wanted to do something beyond that, well there’s a whole lot more Windows PCs out there than there are iPads. Not to mention that it leaves other devices out in the cold. So really, that much effort (and tax payer money) to build an App that adds nothing? Yep, that’s what “sexy” does.

But wait, isn’t Microsoft betting on HTML with Windows 8? Maybe, but I’m not 100% sure about that one yet. Also, Microsoft isn’t known for its choices when it comes to mobile devices. Microsoft sort of invented the tablet almost 10 years ago, but Apple has taken the credit. Microsoft phones haven’t done particularly well, although Windows Phone shows promise. I love mine actually, but I rarely open the browser on that thing. It’s all apps (yup, guilty!)

Where does this leave us? Well, HTML is going to be around for a long long time, but as things are going it will go back to its original purpose: browse information, and primarily for PCs. PCs which are some are already saying are “legacy devices” (I personally believe we’ll move more to hybrid devices, and different devices connected like with Dropbox, Skydrive, iCloud etc.) For the development community this is actually great. Where previously users were complaining about stuff not being cross-platform, they are now actually demanding customized apps for the specific platform they are using, and the government actually tramples over its own guidelines. This means developers have an excuse to have to build an app for at least two or three platforms, so we won’t be out of a job anytime soon. That said, it means that what’s going on at the server is getting more important, because we have to reuse functionality at some level for the costs not to get out of hand. Enter cloud computing, which is great for developers like me: graphically impaired. This by the way is also great for internet providers, providing they can keep up with the bandwidth demand.

As a developer all I can say is thank you Mr. Jobs for putting users with their nuts in the bear trap, and loving it.

IE9 Developer Tools

In recent years the development story for Internet Explorer wasn’t particularly appealing. If you wanted to fix CSS and JavaScript errors, IE was definitely not the tool you wanted to use. Also, seeing what was going over the wire wasn’t possible with IE, and as a result developers flocked to FireFox and other browsers offering (plugins) to help with these issues. You don’t have to be a genius to understand that in the long run this wasn’t helping IE in terms of market share. And with the renewed focus on webbased (HTML5) apps, Microsoft has stepped up and produced built in developer tools, also known as the F12 developer tools. So, what’s in there and what can you do with it?

What’s taking so long?

As with IE8, there are inspector tools for HTML, CSS, and script. Since I am by no means an HTML/CSS guy, I’m not the best judge when it comes to these tools, but for what I need from those I’ve been pretty satisfied. For me, the new profiler and network tools are much more interesting, because they respectively hook into the browser rendering engine and what’s going over the wire with HTTP. If you’ve been using tools such as Fiddler or HttpWatch, the latter of the two should be more or less familiar. As you can see in the image below, it shows all the HTTP requests going out to the server, when in the timeline these requests were going out, and how long that took. If you’ve never seen something like this, you can see that this provides great insight into what goes down under the covers.

If you need more details about the timing information, you can select one of the items, and see more. As you can see below, that information doesn’t only include HTTP information, but also information about the time it took to render and JavaScript to fire. If there’s a page that is slow to appear in the browser screen, this will give you great insight into where your time is going.

Is this functionality better than commercial tools such as HttpWatch? Not at this time, but I have a feeling Microsoft isn’t done yet. Tools like that are specialized, and Microsoft is playing catchup. One annoying thing I found is that if I have multiple requests bouncing back and forth, filling in a form, etc. IE9 tools will only show me the last interaction. It could be I’m missing something, but I haven’t been able to figure out how to see the whole list of requests since I started capturing, and I’m too lazy to figure it out. That means I find myself going back to HttpWatch for that (at the moment). That said, the tooling is good, so if you don’t want to spend the extra dime for other tooling, this will do in most cases. Except of course that this only works in IE9, whereas some of the tools out there work in multiple browsers. But wait… there’s more.

What I’m I getting?

An interesting question is always: what HTML will a certain browser actually get. This is where the F12 tools have another nice new feature. You can change the user agent string the server is receiving, and as a result inspect what happens on the HTML, CSS, script side when other browsers come in. Obviously this doesn’t make IE9 behave itself as one of the other browsers, but it can provide nice insights nonetheless, especially to tweak what robots are seeing.

How will it look?

The last thing that I fond really useful is the ability to change the browser so you can check the user experience for users with different settings. As you can see from the image below, you can disable css, script, and the pop-up blocker. In the environment I’m working in now, there’s often the need to see whether everything still works if JavaScript is disabled, and there this is a great tool. It definitely beats going into the browser settings and changing these settings every time you have to test.

Last but not least, you can easily resize the browser screen to fit a certain size. I always used Windows Sizer for this, but having this built in is better, because I rarely use it for anything but webdevelopment.

What’s more?

There’s a whole bunch of stuff I haven’t gone into here, so I advise you to play around with the F12 tools for a while. I’m also betting we’ll see a lot more where this came from in the not too distant future. Microsoft is investing heavily in HTML5, and is actually trying to use “the best HTML5 support” as a unique selling point for Windows.