gagglestampInternet and Web Development

Jun 20, 2012 (6 years and 1 month ago)


Hype or Reality
by Michael K. Campbell, Daniel Egan,

Tim Huckaby, Michael Palermo
sponsored by
SF_MSDN_Fullpage.pdf 1 7/19/2011 1:20:04 AM
Brought to you by DevProConnections
HTML5: Hype or Real i t y
ComponentOne, a leader in developer productivity tools to build
enterprise-level applications for the desktop, web, and mobile
devices, now offers the ultimate tool for building rich user inter
faces (UI) in ASP.NET. Using the company’s new HTML5 and jQuery
Framework named Wijmo; ComponentOne has built a new gen
eration of Web controls. This new web development suite from
ComponentOne builds on top of jQueryUI, and easily leverages a
user’s existing skill set. From pure client-side development tools to
robust server-side development, all powered by Wijmo technol
ogy, this studio will help a team take on any style of web develop
ment all while using a single framework.
1.800.858.2739 | 412.681.4343
Founded by industry experts in 2001, Syncfusion, Inc. provides
the broadest range of enterprise-class software components and
tools for the Microsoft .NET platform. With Syncfusion, develop
ers can move beyond simply coding applications to delivering
real business innovation—the elegant
user interface
dashboards, and
sophisticated reportin
that today’s
business users need, in the formats they demand. Our
.NET components and controls are designed to meet your
evolving development needs, whether you’re working in Windows
Forms, WPF, ASP.NET, ASP.NET MVC, or Silverlight. At Syncfusion,
we uncompromisingly strive for excellence in order to offer the
very best value to our customers—from small ISVs to Fortune 100
Microsoft’s ‘native’
HtML5 strategy: Back
to the Future?

HtML5 and the Future
of silverlight

the World Is Big
enough for silverlight
and HtML5

Dr. Jekyll and Mr.

HtML5 ResouRCes
Brought to you by DevProConnections
HTML5: Hype or Real i t y
Kendo’s mission is to offer a different HTML5 and jQuery product to
empower you to build applications differently. Kendo is fast. Kendo is
light. Kendo is feature-rich. And, it is so much more than a framework.
It is here to take the latest web standards a step further. Backed by
the expertise of a major UI component vendor with tens of thou
sands of clients all over the world, Kendo is an end-to-end solution
for rich client-side development on all major platforms and devices.
Gizmox is the company behind the Visual WebGui, the first secured-
by-design .NET open source Ajax empowered Web/Cloud and
Mobile HTML and HTML5-based application platform. The Visual
WebGui solution offers features that build, migrate, and run Web,
cloud, and mobile applications. It removes the Ajax complexities and
limitations for business applications and enables applications of any
size and weight to be used on desktop, web, cloud, and mobile from
the same codebase. In three years, Visual WebGui has more than
1,000,000 downloads of its software and over 35,000 VWG applica
tions already in production at first tier organizations such as SAP, IBM,
Israel Aerospace Industry, Visa, Texas Instruments, banks, medical,
government, and military institutions.
Roy Goffer
HtML5 ResouRCes
wimjo_DevConn_0711.qxd 7/15/2011 4:12 PM Page 1
Brought to you by DevProConnections
HTML5: Hype or Real i t y
and programmable Windows desktop built in XAML. There
were even demos in early prototype form. I remember being
pretty excited about building XAML-based applications (WPF)
that actually “lived” in the desktop. Unfortunately it never hap
pened. So, if in fact Windows 8 is going to be skinned/built in
HTML5, then—cool; sounds awesome. God only knows why
that wouldn’t be done in XAML, but still it’s cool. However, I’m
skeptical because I have heard this tune before.
“Native implementations are just better.”
Hey, now. That’s
exactly the opposite of what was said at numerous Microsoft
keynotes over the last three years. In fact, we heard loud and
clear that runtimes, as opposed to native implementations,
were just better. Better, for numerous reasons, not the least
of which is that runtimes like Silverlight are cross platform.
That is what we were told.
And now I’m sitting in the audience watching native HTML5
applications built for the IE9 browser that are talking directly
to the GPU and getting awesome vector graphics and
performance, and I’m watching the Microsoft execs do some
Google Chrome bashing—and I’m thinking to myself, “Oh
my God, we are on a ‘back to the future’ collision course set
for 1998.” Back to when our web applications were basically
built three different ways to accommodate the three major
browsers of the late 90s. “He is not going to say it, is he? Oh
my God, he did”:
“Browsers that optimize for modern operating systems give bet
ter experiences.”
Translation: “You can only do this cool stuff in
IE on Windows Vista or later.”
Now, I know Microsoft is a public company in the business
of profitability. I understand that. I respect that. And they are
quite good at profitability. Microsoft is the number-two most
profitable company in the world surrounded by Exxon, num
ber one and Wal-Mart, number three. But, I wondered if the
majority of the audience watching live and on the Internet
understood the implications of that statement and of that
HTML5 implementation. The implication, simply said, is that
all that cool HTML5 stuff is Microsoft-only HTML5 stuff—stuff
that only runs in Internet Explorer 9+ in Windows. And not
just in any old Windows; only in modern versions of Win
dows. So, if you are building a website or application, only
Microsoft’s ‘native’
HtML5 strategy:
Back to the Future?
By Tim Huckaby
I attended the Microsoft MIX11 Conference in Las Vegas
recently and, as usual, sat in the two keynote addresses
eagerly waiting big announcements and cool demos. Sitting
with my buddy Richard Campbell of .
NET Rock
!, in the min
utes before the first keynote I jokingly said, “I sure hope we
have a little Silverlight 5 goodness in this keynote tsunami
of HTML5.” He replied saying something like, “Silverlight is
the future; but the future is not Silverlight… it’s HTML5.” We
laughed—but little did we know that, when all was said and
done in this first-day keynote from Dean Hachamovitch,
Microsoft corporate VP in charge of Internet Explorer, how
eerily poignant those statements were.
Don’t get me wrong, I’m very excited about the HTML5 thing.
It is just that:
We are so far away from the power and ease of use
in the tools and beautiful plumbing we have in
Because of the buzz... er... HTML5 hysteria for the next
year or so, until HTML5 becomes “real” we are going to
painfully have to explain the trade-offs, use cases, and
scenarios where Silverlight and HTML5 applications
live and don’t live from a solution architecture
Yet, I heard a few resonating quotes from Dean Hachamov
itch in the keynote that caught my attention:
“HTML5: native to Windows.”
Now, didn’t this VP—or perhaps
another—say essentially the exact same thing in a different
way at the MIX conference in 2007 before the Windows Vista
Launch: “XAML: native to Windows”? Well, it might not have
been that conference, but it was one of them. And Avalon,
as it was called, was going to be one of the Four Pillars of
Windows Vista. It was going to be a completely extensible
Brought to you by DevProConnections
HTML5: Hype or Real i t y
t hi s? That l at t er quest i on i s r het or i cal, but t he r eason f or t he
hyst er i a i s t hat HTML5 offer s a bol d pr omi se of r i ch cl i ent ap
pl i cat i ons f or t he web t hat ar e ubi qui t ous among br owser s,
pl at f or ms, and devi ces. And we ar e cl ear l y i n HTML5 hyst er i a
r i ght now. Do a l i t t l e I nt er net sear ch on HTML5. I t i s shocki ng.
The ot her r eal i t y i s t hat even when HTML achi eves ubi qui t y,
and i t wi l l; i t st i l l wi l l not measur e up t o Si l ver l i ght. I t won’ t
measur e up t o Si l ver l i ght 4 and God onl y knows ( al t hough
t her e have been a l ot of hi nt s) at what ver si on 5 of Si l ver l i ght
wi l l f eat ur e. For i nst ance, ar guabl y t he bi ggest and most ex
ci t i ng f eat ur e of HTML5 i s t he vi deo t ag: <vi deo>. The vi deo
t ag wi l l al l ow t he devel oper t o si mpl y embed vi deo pl ayback
di r ect l y i n t he HTML. “ The medi a f eat ur es of Si l ver l i ght ar e
f ar beyond what HTML5 wi l l pr ovi de and wor k consi st ent l y
i n user s’ cur r ent and f ut ur e br owser s,” sai d Br ad Becker. What
Si l ver l i ght does now and HTML5 wi l l not do i s:
Hi gh Defini t i on ( HD) H.264 and VC- 1 vi deo

Cont ent pr ot ect i on i ncl udi ng DRM

St er eoscopi c 3D vi de

Mul t i cast

Li ve br oadcast suppor t

( Adapt i ve) Smoot h St r eami ng

I nf or mat i on over l ays / Pi ct ur e- i n- pi ct ur e

Anal yt i cs suppor t wi t h t he Si l ver l i ght Anal yt i cs

Fr amewor k
And t he vi deo t hi ng i s j ust one use case. I coul d go on and
on, wi t h ar gument s r oot ed i n devel oper pr oduct i vi t y and
dat a access and such, but t he poi nt her e i s you cannot
compar e HTML5 t o Si l ver l i ght. I t i s not f ai r t o HTML5 t o do
t hat. For t hat mat t er you cannot compar e HTML5 t o Fl ash f or
many of t he same r easons.
the Probl em
The real problem is that today we have completely differ
ent implementations of HTML5, and we will for a long time.
With excitement, a few weeks ago I installed IE9 because of
its HTML5 implementation. Once I installed it, I marveled at
all the cool demos and HTML5 apps at

. Then, for kicks I went to the same sites in
Safari on the Mac…yikes. Then I went to the same sites in
a HTML5 implemented browser on Windows that is not
Microsoft—even worse! Then I suffered the next two weeks
the IE9s+ on Windows Vista+ will see the cool stuff, and you’ll
have to build at least two other HTML versions of your site/
application to accommodate the other browsers… which
undoubtedly are going to have their own cool stuff that only
run on their browsers.
Maybe I’m getting old (I am), but I’m dreading the next four
to five years or so for this whole thing to shake out into some
type of parity and standards. That’s how long it took in the
late 90s. And it most certainly seems like we are headed for
that same era of pain again. I worked on an Internet server
product team at Microsoft in the late 90s. It was painful. I
cannot believe we are doing this again. The software indus
try brings new meaning to the word recalcitrant.
Watch the full
MIX11 keynot
, recorded on April 12, 2011.
HtML5 and the
Future of silverlight
By Tim Huckaby
Recently I sat in Redmond, WA at Microsoft headquarters
for one of the councils I serve on and listened with absolute
fascination to Brad Becker (Director of Product Management,
Developer Platforms) and Brian Goldfarb (Director, Developer
Platform Product Management team) honestly and candidly
describe the challenges, opportunities, and confusion the
HTML –Silverlight “thing” has created.
“In about half the time HTML5 has been under design, we’ve
created Silverlight and shipped four major versions of it,”
said Brad. Brad was the product manager for Flash and Flex
at Adobe before taking his role at Microsoft. He has a career
and reputation rooted in rich client applications for the web.
the Reality
The reality is that, even though the major browser platforms
already have HMTL 5 implementations in beta (including Mi
crosoft’s IE9), the specification for HTML5 is not even close to
being completed/ratified. It could be years. Adoption could
be years after that. So why all the hysteria? Is it just the tech
nology industry that gets sucked into hysteria situations like
Brought to you by DevProConnections
HTML5: Hype or Real i t y
app to a CIO/CTO that has been sucked into the hysteria
is even harder. Trust me. I have already been there and
already failed.
For more details on Microsoft’s position on the HTML5/Sil
verlight thing, I strongly encourage you to read Brad Becker’s
blog post titled
“The Future of Silverlight.

It is very well writ
ten and really helped to clear things up for me. Articulating
Brad’s vision, the reality of the HTML5 situation and explain
ing it to technologists who have succumbed to the HTML5
hysteria is a totally different challenge for me.
the World Is
Big enough for
silverlight and
Silverlight for web apps, HTML5 for
By Michael K. Campbell
A recent fight between HTML5 and Silverlight developers in the
blogosphere/Twitter-verse recently made me think about some
of the mixed messages that web developers might be sending
to Microsoft and other core web-technology companies.
Pandora’s Box at PDC
To date, Ian Smith has one of the best “blow-by-blow”
reviews of what precipitated this flame war within the
development community—which he outlined in a blog
post called
Silverlight Shenanigan
. As Ian points out, this
problem actually started to surface a few months ago. It
didn’t, however, come to a head until a lack of coverage of
Silverlight 5 (at the expense of extensive coverage of HTML5)
at PDC was coupled with a
statement by Bob Mugli
Microsoft’s change in strategy for Silverlight.
From here, heavily invested Silverlight developers became
worried, some Silverlight zealots naturally then lashed out
at HTML5 as not being able to meet their needs, and some
with all the Windows client applications I use that embed
a browser control which were now broken. I really under
estimated the pervasiveness of the browser control in the
Win32 and WPF applications I use that are now all broken
because of my IE9 installation and consequent incompat
ibility with HTML5. Two examples are my United Airlines
timetable application and my Verizon cellular modem
application—both broken by IE9 because of the embedded
browser control’s incompatibility with HTML5. I’m glad there
is an uninstall for IE9 or else I would have had to wipe my
box and start over.
But, are we really headed back to the days of 1998 where we
had to fork the code base for every one of our web applica
tions and web sites? Where we had 3 different versions of
every web application we built because each of the three
main browsers behaved differently? A decade ago, we used
to have to do a browser sniff to determine which codebase
to run, and we had to maintain 3 codebases. I do not want to
relive that. But, the iPad has forced many to do just that: the
Flash or Silverlight version and the non Flash or Silverlight
version. And with HTML5 looming, it could . . . I mean it will,
get even uglier. Even though ubiquity is the bold promise of
HTML5. Until all the browsers implement HTML5 with some
resemblance of parity it is going to be an incompatibility
nightmare. And that incompatibility could last for years. Over
a decade ago I worked on that server product team at Mi
crosoft which was Microsoft’s very late entry to the Internet. I
really don’t want to live that pain again.
Consistency between implementations of HTML and CSS has
always been a challenge. And because of this, these tech
nologies have traditionally had a lot of issues with variation
between browsers. Therein lies the problem. It’s like we can
see the tsunami coming and have plenty of time to react,
but we won’t be able to.
It is interesting (and encouraging) to me that HTML5 in
tends to adopt features as standards which were innova
tions first introduced by browser plug-ins like Flash and
Silverlight. But another reality of the situation is that the
solution architecture decision by which we decide how
an application is manifested has become harder. Explain
ing why “it’s a Silverlight app” as opposed to an HTML5
Brought to you by DevProConnections
HTML5: Hype or Real i t y
which technology is better. Which is dumb, because both
technologies are better. Meaning that, in general, Silverlight
is a better technology for web apps, and HTML5 will end up
being a better option and platform for websites.
Put differently, site development tends to be heavily focused
on attracting, maintaining, and converting (i.e., to sales,
change of opinion, action, whatever) the widest audiences
possible. Site development, therefore, places a huge amount
of focus on SEO—because indexable content can help sites
accomplish their goals of reaching and impacting the largest
audiences possible. Rich media on these kinds of sites has
traditionally been handled by Flash (and to an increasing
amount by Silverlight). But each time a decision is made
to add increased media (or other) capabilities, it has been
juxtaposed against the potential to diminish audience, reach,
or conversion.
With web applications, however, there’s a totally different
focus, which (typically) is primarily on functionality, capabil
ity, and the need for agility in terms of adding new features
and capabilities. More importantly, though, discoverability
and a focus on growing audience sizes are typically not a
consideration when it comes to most line-of-business ap
plications. Yes, these apps need to be able to be accessible
from a wide variety of different hosts or platforms/browsers,
but the focus of that need isn’t upon increasing reach or
audience in most cases. Instead it’s a question of availability
and productivity for the end users. Similarly, with most web
applications, it’s safe to say that some conditions (such as the
specification of minimal browser versions or the requirement
of “plug-ins” like Silverlight) are not only acceptable but go
hand-in-hand with meeting primary goals and consider
ations (instead of coming at the expense of those goals and
Why this latest little tussle Mattered
Yet in the case of site or app development (as I’ve outlined
above), we’d still be talking about web development being
done by web developers—because everything would be
client-server oriented and rendered in a browser. From there,
the similarities quickly fade, though. And problems creep in
when application developers fear that they may lose their
productivity tools, features, and capabilities to something
HTML5 zealots, in turn, were only too quick to point out why
they aren’t that enthused about Silverlight.
The problem, of course (other than the fact that Microsoft is
not deprecating Silverlight in the slightest), is that this would
be like an argument between carpenters about which is bet
ter: a hammer or a saw.
Hammer or Saw?
For heavily invested Silverlight developers, I can understand
why they would be aghast at the potential prospect of being
“forced” to use HTML5 for their applications. To many of them,
I’m sure that HTML5 really looks like a franken-tier of compo
nents and technologies that is stretched too thinly across far
too many browsers that lack any semblance of homogeneity.
For these web developers, the prospect of having to “drop” to
a mismatched bag of different tricks, tools, and technologies
to build their applications would be a huge productivity hit
compared with what they’re capable of with Silverlight today.
On the other hand, most site developers have spent a fair
amount of time looking at Silverlight (and Flash), and found
it wanting—or even undesirable for their needs. Among
other things, as cool as something like Flash or Silverlight
may be in terms of User Experience (UX), it comes at the
cost of SEO/SEM—something most site developers can’t
afford to ignore. That, and while Flash still has impeccable
market penetration, Silverlight just hasn’t been able to reach
the same level of ubiquity, despite some seriously amazing
growth over the past few years.
Will the Real Web Devs Please Stand up?
I’ve long maintained that that there is a huge difference be
tween building websites and building web applications. Yes,
there are some huge commonalities between both types of
development—and the people who do both kinds of devel
opment call all call themselves web developers. Some web
developers are also just fine moving back and forth between
both types of development. But most web developers tend
to focus on one kind of web development (at least for long
periods of time): app development, or site development.
In other words, the silly thing about this whole HTML5 vs.
Silverlight issue is that it somehow became a question of
Brought to you by DevProConnections
HTML5: Hype or Real i t y
Dr. Jekyl l and Mr.
Silveright is alive and well, thank you very
much—alongside HTML5
By Tim Huckaby
When I wrote my column recently on the
confusion of
HTML5 and Silverligh
, I thought that was it. I thought I could
move on from all the hysteria, but sure enough in late Octo
ber the monster came back . How naïve of me. It came back
because of some “interesting” statements made in a keynote
and to the press by Microsoft’s Bob Muglia, President, Server
and Tools Division, at the PDC conference on the Microsoft
campus in Redmond, Washington, which frankly were ini
tially a bit depressing for a Silverlight fan like me:
“Silverlight is our development platform for Windows Phone.
Silverlight also has some “sweet spots” in media and line-of-
business applications.” Muglia said. But he also made some
vague statements in the context of Silverlight like, “Our strat
egy has shifted.” Those statements, coupled with the lack of
any Silverlight-next discussion or sessions at the PDC, caused
a firestorm of Internet fodder, speculation, and discussion
on internal and external Microsoft aliases about the death of
Silverlight…. Ultimately all false.
In reading an internal email thread on his reaction to the
messaging at this year’s PDC keynotes, I couldn’t help but be
riveted by the statements made by Bob Kreha, founder of
Fifth Disciplin
, on the HTML5/Silverlight confusion. In fact,
this article is titled “Dr. Jekyll and Mr. HTML5” because that is
what Bob Kreha titled his email. Bob went with a sobering
statement: “I am concerned, however, that Microsoft vacil
lates on whether Silverlight really is a prime time competitor
to HTML5 or not. It leaves us all in a strategic lurch.”
A few days later, on November 1, Bob Muglia made a
blog post
to the Silverlight Team Blo
clarifying his statements at the PDC:
that just doesn’t meet their needs in the same way (HTML5,
CSS3, and jQuery). The same can be said when application
developers try to argue that HTML5 just isn’t rich enough
to handle “true” web development—because site develop
ers are currently building REAL web solutions and sites with
HTML5 today.
Consequently, until our industry at large can learn to
more readily distinguish and elucidate the differences
between application web development and web site
development, I think we’re doomed to endure two painful
First, we’re doomed to more flare-ups like the one we just
saw, as this whole HTML5 vs. Silverlight scuffle perfectly
reinforces the fact that there are two primary types of web
development out there today (along with variations or
“blends” of these two techniques in various shades and
Second, and much more important, I think we’re also
doomed to not being able to communicate our specific
development needs for tooling, platforms, and patterns
as readily as we should be able to vendors and industry
“shapers” like Adobe, Apple, Google, Microsoft, the W3C,
and so on. Meaning that if we’re going to erroneously fight
about which single tool or technology is best for both kinds
of development, then we risk sending very mixed messages
to the very companies and powerhouses that build the
browsers and tooling that we all need to stay gainfully, and
professionally, employed and viable.
To that end, I think it’s important to point out that not only
do I think that the world is big enough for both technolo
gies, but I actually think that there’s a need for both HTML5
and Silverlight. And, happily, it looks like Microsoft is going
to be heavily investing in both of them. So, hopefully, we can
all get back on track and do a better job of communicating
just what it is we need from Microsoft, instead of trying to
convince them (or ourselves) that a hammer is better than a
saw, or vice versa.
Brought to you by DevProConnections
HTML5: Hype or Real i t y
the Past, Present,
and Future of HtML5
Take a quick journey through the evolution
of HTML and learn about basic HTML5
By Daniel Egan and J. Michael Palermo IV
Stop and think for a moment about how long you’ve been
a developer. For some of you, that journey started recently.
For others, it has been years. However long it’s been, do you
realize that less than a decade ago, the .NET revolution had
not officially started? Classic ASP was the primary way we
developed for the web, and HTML was at version—wait a
minute—is still at version 4.01!
Despite sluggish transformations regarding HTML overall,
small to very dramatic changes in technologies that are based
on HTML have occurred. Think of the changes that have
occurred in web browsers, JavaScript, and Cascading Style
Sheets (CSS). Think of how AJAX has changed the way many
web developers approach communications between the
browser and server-side resources. The web has seen many
changes but with virtually no change to its core language,
HTML. However, that logjam is about to bust with HTML5.
A Brief History of HtMl5
Before we discuss what HTML5 has to offer, we should note
that attempts have been made to change HTML. Note the
word is
But what does that
mean? Why is it important to consider the failed attempts
to change HTML? So that you can appreciate why HTML5
is worth investigating and why it is here to stay. For these
reasons, let’s take a brief journey down memory lane and
consider the series of events that led to where we are today.
Then we’ll discuss where we’ll be tomorrow.
You probably already know who Tim Berners-Lee is and that
HTML came into existence as far back as 1989. You also prob
ably know that the Internet took off in the 1990s, and so on.
“I understand that what I said surprised people and caused
controversy and confusion. As this certainly wasn’t my intent,
I want to apologize for that. I’d like to use this post to expand
on what I said, and talk about the very important role Silver
light has going forward.”
He went on: “In the interview, I said several things that I want
to emphasize:
Silverlight is very important and strategic to Microsoft.
We’re working hard on the next release of Silverlight,
and it will continue to be cross-browser and cross-
platform, and run on Windows and Mac.
Silverlight is a core application development platform
for Windows, and it’s the development platform for
Windows Phone.”
It is amazing how a few somewhat innocent comments turn
into snowball of speculation in the form of an article in the
press, then a number of blog posts, and a ton of traffic in the
email aliases. And consequently, an ecosystem of Silverlight
developers become immediately depressed and/or threat
ened. In the comments to Bob Muglia’s retraction blog post
I found it amazing how many Silverlight developers thanked
him for the clarification, as if they had bought into the notion
that Silverlight had died and were relieved it was not true.
That was yesterday. Well, as I write this, I am sitting here
listening to Scott Guthrie’s keynote at the
in Las Vegas. Scott started his keynote with a
slide showing the Silverlight logo and the statement, “The
Reports of My Death Are Greatly Exaggerated.” Scott went on
to explain that Silverlight is still crucial to Microsoft’s strategy
and emphasized that not only is it not dead, but he has more
people on the Silverlight Product team working on Silver
light-Next than at any other time in Silverlight history and
that Silverlight adoption is soaring with the runtime installed
on over two-thirds of the computers on the Internet.
But Scott Guthrie made one statement that rang more true;
more poignantly than anything else in his keynote: “Do not
believe everything you read on the Internet.” Boy is that
true—now more than ever.
Brought to you by DevProConnections
HTML5: Hype or Real i t y
So now what? Exactly. WHAT was born. The Web Hypertext
Applications Technology (WHAT) Working Group, actually
known as WHATWG (, came into existence
in 2004 to put life back into HTML. This group’s intent was
to move forward in a manner consistent with how the web
was actually being used and to spearhead innovations in
HTML while maintaining backward compatibility. Instead of
breaking 99 percent of the web, why not embrace the way
in which web pages are actually served? Browsers have been
forgiving. Why make page-breaking changes?
Therefore, the WHATWG came up with Web Applications 1.0
while the W3C worked toward version 2.0 of XHTML. How
ever, near the end of 2006, it was clear that the WHATWG
was gaining momentum while XHTML 2.0 was lacking
support by any major browser. Thus, the W3C announced it
would collaborate with the WHATWG. One of the outcomes
of this union was to rename Web Applications 1.0 as HTML5.
Is there a lesson in this for us? Absolutely. Despite noble aims
and grand ambitions, whatever the masses choose to adopt
wins. The growing adoption of HTML5 makes it the winner.
HTML5 cannot be ignored. Our brief history lesson demon
strates that HTML5 is here because we willed it to be here.
(For more in-depth coverage of the history leading up to
HTML5, check out
Start using HtMl5
HTML5 is not an official specification yet, but it will likely have
a prominent place in website development, given that the
major browsers are gradually incorporating HTML5 features
and Microsoft’s recently stated intention to incorporate “na
tive” HTML5 in Windows. So it’s a good idea to start getting
familiar with HTML5 now—and you can do so without mak
ing dramatic changes to the pages you already have. Let’s
consider a minimalistic HTML5 document, such as in Figure 1.
Notice the omission of the <html> and <head> tags. Accord
ing to the current specs, this is still a valid document. If these
tags are omitted, the browser will still parse the document,
and the tags will be implied. This represents a shift from the
strict conformity imposed by the current HTML standard.
So instead of strolling through a step-by-step timeline, let’s
focus on the attempts to replace HTML with something else.
Fast-forward to January 2000. The World Wide Web Consor
tium (W3C) recommended Extensible HyperText Markup
Language (XHTML) 1.0. For an XHTML document to be
served correctly, the author had to use the new applica
tion/xhtml+xml MIME type. However, Appendix C of W3C’s
XHTML 1.0 specification made provision for pages to be
served by using the common text/html MIME type.
More than a year later, in May 2001, the W3C recommended
XHTML 1.1. The abstract of the recommendation stated,
“The purpose of this document type is to serve as the basis
for future extended XHTML ‘family’ document types, and to
provide a consistent, forward-looking document type cleanly
separated from the deprecated, legacy functionality of HTML
4 that was brought forward into the XHTML 1.0 document
types” (
According to the abstract, XHTML was prepped to be the
future of the web. The abstract boldly referred to HTML 4 as
“deprecated, legacy functionality.” And version 1.1 of XHTML
removed the Appendix C version 1.0 provision that allowed
a page to be served with the text/html MIME type. So why
didn’t this recommended standard replace HTML altogether?
The answer is simple: Developers didn’t implement it.
To be sure, many developers tried to implement XHTML in
their websites. XHTML mandated a well-formed XML docu
ment using the classic HTML tags. To be well-formed, a web
page would need to be served with no overlapping tags
and no missing end tags, and the values of all attributes had
to be enclosed in quotation marks. The notion of cleaning
up our web pages wasn’t unpopular, but it wasn’t strictly
enforced either. And even if a web developer created a well-
formed web document, was it served with the application/
xhtml+xml MIME type? Likely not. In fact, it is estimated that
99 percent of web pages on the Internet today contain at
least one violation of the XHTML standard, which, if enforced,
would cause the page to stop rendering and post an error to
the end user. Ouch!
Brought to you by DevProConnections
HTML5: Hype or Real i t y
<html xmlns=””
Look at how much was removed. There is no longer any
need to specify the namespace of the document because all
elements in HTML5 (unless otherwise noted) belong to the namespace. The xml:lang
attribute is left over from the XHTML era. So, once again,
HTML5 presents a simpler way to do things, but for what it is
worth, the older syntax is still acceptable.
Now, how about that <meta> tag? This is how we used to
handle it:
<meta http-equiv=”Content-Type” content=”text/html;
And as you have noticed, it is now this simple:
<meta charset=”UTF-8”>
Of course if you want to use the old style, that’s still okay. It’s
a good practice to make this meta charset tag the first child
of the <head> tag because the specification states that the
character encoding declaration must appear within the first
1024 bytes of the document. Why set the encoding for the
document? Failing to do so can cause security vulnerabilities.
Although the encoding can also be set in the HTTP headers, it’s
still a good practice to declare the encoding in the document.
These subtle differences clearly confirm the WHATWG’s com
mitment to maintaining backward compatibility while allow
ing changes that simplify or enhance HTML. However, not
everything from the past is preserved in HTML5. For good
reason, some tags, such as those in Figure 4, have been given
a proper burial. Tags such as <basefont>, <big>, <center>,
<font>, <strike>, <tt>, and <u> are purely presentational in
their function and are better handled through CSS. In addi
tion to these retired elements, a number of attributes have
been removed for similar reasons. All absent or removed
items in HTML5 can be found at
new Features in HtMl5
But what about the changes that give us new features in
HTML5? Let’s briefly consider some of the more popular ad
ditions that you can start using today.
Here is another example of how easy it is to adapt to HTML5:
<!DOCTYPE html>
The doctype syntax has been simplified. Compare this to
examples of what we have been accustomed to, shown in
Figure 2.
The doctype declaration is required. Although it is clearly
easier to type the normal HTML5 doctype, the deprecated
doctypes in Figure 2 are still accepted formats. By the way,
the doctype declaration is not case sensitive, so any of the
following are acceptable:
<!doctype html>
<!doctype HTML>
Now take a look at Figure 3 to see a more realistic starting
point for an HTML5 document.
You might find slight differences in this HTML5 document
compared to what you are used to. Apart from the doctype,
you might notice the attribute on the <html> tag and the con
tents of the <meta> tag. Let’s focus first on the <html> tag:
<html lang=”en”>
The lang=”en” attribute informs the browser that the con
tents of this document are in English. This is much simpler
than the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
Figure 2:
Doctype examples
<!DOCTYPE html>
<html lang="en">
<meta charset="UTF-8">
<title>Getting Started With HTML5</title>
<p>Simple text.</p>
Figure 3:
Simple HTML5 document
<!DOCTYPE html>
<title>A relatively minimal HTML document</title>
<p>Hello World!</p>
Figure 1:
Minimalistic HTML5 document
Brought to you by DevProConnections
HTML5: Hype or Real i t y
started is very easy. Observe the following markup and the
screen shot in Figure 7:
<video src=”big_buck_bunny.mp4” controls>
Sorry, your browser does not support the video
With just a few lines of code, you can have a video up and
running with interactive controls for your users to manage!
The controls attribute can stand by itself, or you can use
controls=”controls” to provide the XML-friendly approach.
Also, note that within the tags you can provide optional text
that will be displayed if the browser does not support the
video tag. As you select your video formats, remember that
not all browsers support the same video types.
First are the new elements that are in line with how the
web works today. These new tags, shown in Figure 5,
are structural or semantic in nature. A good number of
websites today have very similar structures. Think of foot
ers, for example: Many sites display footers, which usually
contain author information, links, and copyright informa
tion. A typical approach to footers would look something
like this:
<div id=”footer”>&copy; Copyright 2011 Egan &amp;
How many <div> tags would you guess there are on the
web functioning as the container for footer information?
Well, the count is so high it became obvious that a tag was
needed to represent this information. In HTML5, the tag
looks like this:
<footer>&copy; Copyright 2011 Egan &amp; Palermo</
The main purpose of semantic elements is to provide con
text to the data. These tags are not about how the content
looks. Rather, they are more concerned about the substance
of the content. You modify the appearance of these ele
ments through CSS.
The <input> tag in HTML5 supports new attribute types,
shown in Figure 6. Although not all browsers support these
new attribute types, it is clear that these types will map
nicely with our modern entry forms.
Audio and Video Capabilities
Support for multimedia via the <audio> and <video> tags is
another welcome addition to HTML5. What used to require a
plug-in is now accomplished with simple HTML tags. Getting
Figure 4:
Elements absent from HTML5
For independent content, such as a blog post or article
For content slightly related to primary content on page
For grouping a section of standalone content, such as
video or an image
For use with <figure> (optionally) to provide a caption
For providing author, copyright data, etc.
For introductory content, could include navigation
For grouping <h1> to <h6>
For content intended to provide navigation
For a section in a document; similar to sections in
Figure 5:
Semantic elements in HTML5
Input Attribute
Type Value
Hexadecimal color value
Date and/or time
Local date and/or time
Email address(es)
Numeric range
Intent to search
Telephone number
Week number
Figure 6:
New input attributes
Brought to you by DevProConnections
HTML5: Hype or Real i t y
To begin your artwork, you need calls in JavaScript are
needed. Using the canvas from the preceding example,
Figure 9 shows how to draw a simple blue square.
To what degree can the <canvas> tag enhance the user
experience? You really must try it yourself to experience the
difference. However, to give you an idea, Figure 10 pres
ents a screen shot of the game “Pirates Love Daisies” (www. This tower-defense game is packed
with action, animation, and stimulating sounds. It is so well
done that you might find yourself doubting it is a pure
HTML5 page.
Another striking demo that showcases a variety of HTML5
features, including Scalable Vector Graphics (SVG) support, is
found at This page, shown in Figure 11,
allows a fan to drag and drop clips onto a circular timeline,
add effects, and publish a custom Bon Jovi video.
Web Storage
Web storage represents another nice addition to HTML5.
Web storage is a highly anticipated feature that allows larger
If adding video seems easy, HTML5 makes it just as easy to
add audio to your site. The markup is fairly similar:
<audio src=”music.mp3” controls>
Sorry, your browser does not support the audio
Like the <video> tag, the <audio> tag contains a controls at
tribute for visual display to manage volume and positioning
of audio, as Figure 8 shows. Although this example features
an MP3 audio file, be aware that not all browsers support the
same audio types.
A very exciting addition to HTML5 is the <canvas> tag.
With this new feature, developers can add rich graphical
experiences to their web pages. Think of a canvas as you
would visual art in the real world. A painting canvas is
usually a blank rectangle waiting to be drawn or painted
upon. Likewise, in your web page, a canvas is a designated
section of the page that you can draw on. By using the
<canvas> tag, you eliminate the need for plug-ins that
provide animations. Here is an example of how to declare a
simple <canvas> tag:
<canvas id=”myArtwork” width=”200” height=”200”>
Your browser does not support the canvas
Figure 8:
HTML5 audio control
Figure 7:
HTML5 video control
<script type="text/javascript">
var art=document.getElementById("myArtwork");
var ctx=art.getContext("2d");
Figure 9:
JavaScript for canvas
Figure 10:
Pirates Love Daisies game
Brought to you by DevProConnections
HTML5: Hype or Real i t y
when the browser session ends, while local storage has no
time limit. This web-storage feature is available through
objects in JavaScript. Here is an example of how to store a
display name in local storage:
<script type=”text/javascript”>
Note that in the preceding example, DisplayName was made
up on the fly. The property name can be whatever you want
it to be.
no Better time to Be a Web Developer
What we have covered so far is just a taste of the new fea
tures in HTML5. In upcoming articles in this series, we will
demonstrate how to leverage specific features in greater
This is an exciting time to be a web developer! Whether
you are developing publicly for the web or creating
internal sites for your company, HTML5 has much to offer
in providing sorely needed features that are native to
the browser. With growing support among all the major
browsers and with new sites emerging that consistently
use it, HTML5 is a must-visit technology for any serious
web developer today.
amounts of data to be stored locally in the browser without
generating a performance hit on round trips. The primary
way developers handle local storage today is through cook
ies. The disadvantage of cookies is that the data is passed
back and forth with every HTTP request or response.
In HTML5, developers can use one of two options: local or
session storage. The difference is that session storage expires
Figure 11:
Custom Bon Jovi video
See the future of client-side development at
HTML5 and jQuery.
Taken a Step Further.
HTML5 and jQuery.
Taken a Step Further.
Build modern web apps for every browser and device with a pure client-side development
toolset that simpli￿es HTML5 adoption. Enjoy quick development and deployment with a
single, complete toolset built on jQuery. Rich web UI and the latest web standards made easy.
Brought to you by DevProConnections
HTML5: Hype or Real i t y
: Secur i t y vul nerabi l i ti es,
no separati on of busi ness
l ogi c f rom webpages, com
pl ex and er ror-prone data
bi ndi ng bet ween ser ver and
cl i ent, transmi ssi on of al l var i
abl e page content due to the
statel ess nature of the ser ver, thus i ncreasi ng ser ver l oad.
Cl i ent-Based Pl ug-in Frameworks
Compi l ed appl i cati on code i s run i n the browser by a dedi cated
runti me envi ronment cal l ed the pl ug-i n. Database access i s done
through statel ess web-ser vi ces or acti ve ser ver pages. Adobe Fl ex,
Mi crosof t Si l ver l i ght and Java appl ets.
Useabl e for data centr i c LOB
appl i cati ons. Excel l ent for non- data centr i c apps such as games,
medi a, edi tors, l ocal tool s etc.
OO development, free from browser incompatibilities, good
debugging, availability of developers, management of client state,
implementation of permissions, access provided to local devices.
: Dependency on plug-in installation, load time overhead,
high bandwidth requirements due multiple threads creating a
run-time overhead, competes with HTML5, no server-side state,
questionable IP and data security, performance limits for large
numbers of users.
Hybrid Frameworks
One company -
Visual WebGu
(VWG) - has built a hybrid approach,
taking something from each of the above. It is strictly server driven
and doesn’t put the application or data in jeopardy by allowing
distributed clients to interfere with the application flow or data
content. Its client layer is pure display without hidden identifiers and
all actions and data entered are controlled by the server application.
Excellent for data centric LOB applications.
: High security, visualized data binding at design time,
automatic HTML5 code generation, cross-browser compatibility,
maximum use of current developer skills (.NET and Java), high
performance for a large number of users, strong debugging, a
visualized component-oriented development process and efficient
run time data interactions.
: Overhead for websites and applicative sites.
VWG client is a static AJAX / HTML5 code that acts as a thin but
flexible client; the static nature of the client code block enables
coding the entire application as a single layer of .NET code that
runs on the server and therefore, facilitates debugging. It uses a
single channel of communication to handle all browser-server
requests for a session. In other words, the client speaks to the
application server only and the server speaks to any other services
required. This gives a kind of server-client hybrid. That is the VWG
concept - visual .NET power for rich HTML5 web, cloud and mobile
An increasing number of organizations are including HTML5 in their
development plans. Even Microsoft seems to be moving away from Sil
verlight in favor of HTML5, as indicated by a recent Windows 8 preview,
which showed a developer platform based on HTML5 and JavaScript.
The trend of browser-based front ends for data-centric, cloud-based,
AJAX-rich applications is supported by all major vendors. However, the
architecture brings with it numerous problems and, to date, one offer
ing - Visual WebGui - stands out from the alternatives for data-centric,
security driven enterprise applications.
the Challenge of implementing Rich Web Enterprise

vulnerabilities - exposed client end points due

to data/
logic that needs to be transferred to the client.
State Management - The synchronization of state between server
application and browser is one of the biggest challenges facing
web architecture.
Performance issues when large amount of data is transferred back
and forth from the server to the user via a network.
Cross Platform Compatibility as one application must serve clients
running on at least 4 major operating systems, tens of browser
types and versions, numerous display configurations and new
devices every day.
implementing HtMl5
HTML5 offers benefits of a RIA user experience, native performance and
multi-browser compatibility but brings new challenges:
Suitability of the development framework for producing HTML5
Existing development skills and the cost of learning.
Screen size, layout and style.
Getting JS and HTML5 to make finger-touch operation work.
Frameworks for Building HtMl5 Data Centric
Server-Based Frameworks
The coding is Java, processed into AJAX. Page design is done
separately by client-side developers. Example: Google GWT.
for non-LOB applications; security complexities with data centric
LOB applications.
: OO development, good debugging tools at the Java stage,
optimized for HTML5, fair data binding capabilities, plug-in free.
: Multiple programming skills required, security vulnerabilities,
no separation of business logic from webpages, complex and
error-prone data binding between server and client, debugging
difficulties in run-time, cannot handle state.
Client-Based Ajax Frameworks
Code is written for the client in JavaScript and HTML5. Stateless
web-services or other types of stateless dynamic backend are used
for database updating.
Good for static websites and non
LOB appli
cations; insecure for data centric LOB applications.
: Developer-written HTML5 code for maximum HTML5 usabil
ity, native client debugging, handles state, plug-in free.
Visual WebGui - The Solution for

Rich Web HTML5 Enterprise
Live Dem
Free Download
Brought to you by DevProConnections
HTML5: Hype or Real i t y
Daniel Egan
Michael K. Campbell
Michael K. Campbell
is a contributing editor for
SQL Server Magazine,
a regular columnist for, and an ASPInsider. Michael is the president of OverAchiever Productions, a
consultancy dedicated to technical evangelism, mentoring, and quality solutions. He specializes in SQL
Server, ASP.NET, and related technologies. Michael has been a professional developer, web master, and
production DBA for several well-known companies. He enjoys learning, problem solving, teaching, and
creating free videos for
Daniel Egan
( is a Microsoft Developer Evangelist based in Los Angeles and
the man behind the award-winning Windows Phone 7 Unleashed events. Learn more about Daniel at
his blog, or follow him on Twitter @danielegan.
Tim Huckaby
tim Huckaby
) is Founder and Chairman of InterKnowlogy, experts in
Microsoft .NET and Microsoft platforms. Tim has worked on and with product teams at Microsoft for 25-plus
years, has authored books and several publications, and is a frequent conference speaker.
Michael Palermo
J. Michael Palermo iV
( is a Microsoft Developer Evangelist based in
Phoenix. Michael’s current passion is all things HTML5. You can find Michael blogging at www, or follow him on Twitter at @palermo4.
About the Authors