I basically agree with you, I think HTML 5 will eventually draw everyone together. Microsoft is going to have to bite the bullet as not to long from now Google will start to catch up

The 3 technologys will be totally basic

As someone who has more or less staked his career on the triad in question, I''m inclined to agree from a self-preservation standpoint... but I think I also truly believe. I was out of the game briefly studying business from 2005-2007, and it was during this time that the JS frameworks emerged in concert with more powerful browsers and processors to show what was possible with the open standards. In part because of this, spanking new MBA in hand, I gravitated back to the creative and technical side and haven''t looked back. Certainly for those new on the scene I would think the standards you mention are the starting point as they are driving the web today.

I think it will take some time. Back in the late 90''s CSS 2.1 were already there but webmasters only began to use compliant code in the mid'' 2000. Even if social networks, blogs and forums do communicate about HTML 5 and CSS 3 a lot and make it a buzz on the web.

...I''m with Microsoft to the end. ;-)

Unfortunately, standard doesn''t always mean better.

Look, IE is the only browser that doesn''t fully support it. This is survival of the fittest. Kill it off!

Well, I agree HTML5 is something students and newcomers to the web should take some time with... but for someone who doesn''t know a meta tag form a link tag, I think they should start by comprehending HTML4 first. Get to know the semantics and why they matter. After that, grab a bit of basic javascript knowledge to be able to play with all HTML5 has to offer.

Then, jump head first into the HTML5 spec and have fun. And don''t just use HTML5 stuff because you can. Be responsible and use it when it makes sense. :)

Yes, I agree. Html5 is the future. But, it''s not ready right now (but very soon, as long as all browsers are committed to it). At the moment, using it requires a lot of effort to build elegant fallback, which somewhat destroys the simplicity of using html5 technologies. Also, there are not a lot of resources and libraries to speed up the process. Nonetheless, things will be better very quickily (hopefully, thanks to the push from ipad). When, things are getting more mature, interesting things will happen. And gradually, it''d be a prefered choice for even building really fancy interactions.

Also, as a side note, I always think that most good flash developers have great knowledge in JavaScript development and semantic markups. Rarely, web developers only know flash development only. But, the reverse might not be true. Anyway, learning as3 is still not a waste of time because it does teach students how to apply effective design patterns and solve complex interactive problems. But, html5 technologies will be a must.

I fully agree. Get a firm handle on HTML4 / CSS2.1 / and some flavor(s) of javascript. Heavy on CSS, for my taste.

Then with a shiv and some "graceful degrading" you can put out some mobile-ready HTML5/CSS3 websites right away.

The biggest problem with HTML5 is the name. The uninitiated think it is much, much more exotic than it is. You have to keep explaining to people "it''s HTML!" and in fact the W3C has basically changed the name of HTML5 to "HTML" now. There will be no HTML6.

The key thing to understand is that this is the first HTML specification that not only tells the author how to write HTML, it tells the browser author how to write a browser to read HTML. It''s more like the specification for CD or DVD, where there''s a right way to make a disc and a right way to make a player, and the consumer can expect to put any disc into any player and it just works.

The other key thing to understand is that HTML5 standardizes what is currently going on in the browsers. When it gets into the spec, it''s already out in the world. It doesn''t get written down and then added to browsers.

> I think it will take some time. Back in the late
> 90’s CSS 2.1 were already there but webmasters
> only began to use compliant code in the mid’ 2000.

CSS 2.1 is mid-2000''s. CSS 1.0 was 1998.

We are well into the HTML5 era. It''s not just starting. The browsers are already decoding the Web by default as HTML5. If you don''t specifically ask for HTML4, your page is treated as HTML5.

> Unfortunately, standard doesn’t always
> mean better.

Yeah, it does. Just a different kind of better than you may be thinking of.

The entire point of the Web is to be the 1 universal part of the Internet. Before the Web there was gopher and archie and now there is Twitter and BitTorrent. None of those are universal. It''s the Web that acts as the common place to tie all those other Internet features together. The fundamental feature of a Web document is to be universally readable. We achieve that through standardization. Same as the universality of the CD/DVD came from standardization. The universality of H.264 video came from standardization. Now, we''re doing that to the Web via HTML5 because consumers use the Web now, not just computer nerds. It has to just work. Without updating a plug-in, downloading a different browser, or any kind of I-T work at all. The Web is growing up and we''re supposed to work like the adults in consumer electronics, not like the kindergarten kids in the PC industry.

For the last year, all I''ve done is convert Flash to HTML5, because I have both skill sets. I''m cleaning up a mess left by irresponsible developers who were making things "better" by putting Flash into a Web page with no fallback content for non-Flash users. The publishers I''m working for are pissed at the original developers. They thought they were buying Web content and they were very disappointed to find out they got something that is not universal. They don''t want a single user of their site to see a big empty box, no matter what platform they are on. It''s not "better."

The year before that, I converted a bunch of IE6-only websites to HTML5, again, for publishers who were also pissed at the original developers, because they also thought they were buying Web content, not IE6 content.

The nonstandard Flash and IE6 content on the Web has cost publishers billions and billions of dollars. It''s not "better." None of this was worth what little gain may have come from it in terms of more smoothly animated dancing gophers.

The Y2K bug was all about short-term thinking. So is the IE6 bug, the Flash bug, and the entire browser plug-in bug.

Nonstandard content on the Web is a bug. Plain and simple.

> Well, I agree HTML5 is something students
> and newcomers to the web should take
> some time with… but for someone who
> doesn’t know a meta tag form a link tag,
> I think they should start by comprehending
> HTML4 first.

I think that is 100% exactly wrong.

First, HTML 5 is just HTML. It''s always evolving. There is no point in learning the obsolete practices.

Second, HTML5 is easier to learn than HTML4. It''s standardized, there is a right way to do many common things. There is no right way to make HTML4. The spec does not match the browsers. During the HTML4 era, we made IE6/Flash apps. HTML4 standardization was a failure. XHTML was a terrible failure.

Finally, any HTML4 that you make today is just broken HTML5. All of the browsers except IE are already modified to act as HTML5 browsers, with HTML5 browser behaviors. IE will catch up soon in IE9. All the old browsers are essentially low-fidelity HTML5 browsers now because HTML5 has backwards compatibility built-in. So when you write a video tag, you put a hyperlink inside it pointing at the same video, with a poster image inside that, and now you''ve made a universal presentation of that video. In modern browsers, the video plays inline, in older browsers, it opens in a helper app.

And yes, you respect the ISO MPEG-4 video standard, you don''t express your creativity by choosing to use nonstandard video your readers can''t see.

> Yes, I agree. Html5 is the future. But, it’s
> not ready right now

No, you are making a common mistake of thinking it goes 1) spec, then 2) browser support. It''s the other way around in HTML5. By the time something gets into the spec, browsers are already doing it.

If you don''t put a DOCTYPE on your page, modern browsers will interpret your page as HTML5 by default. Further, mobiles are all HTML5 and there are no browser plug-ins. If you are serving them browser plug-ins, your pages are obsolete and need to be updated.

In other words, if your pages are not HTML5 right now, they are breaking in today''s browsers. They are already obsolete.

> At the moment, using it requires a lot of
> effort to build elegant fallback,

Wrong. There are only a handful of new tags, and all of them have built-in backwards compatibility, you can put an older tag inside them for legacy browsers.

> which somewhat destroys the simplicity
> of using html5 technologies.

No. There is no elegance to the HTML5 spec other than it matches the real world. It is not an academic standard as in the past. There is no pristine markup you are waiting for browsers to one day support. That never happens.

You will be writing video tags with hyperlinks inside that point to the video for the next 10 years. There is no reason not to get started. You are working with 2 browsers in mind: HTML5 compliant browsers, and legacy browsers. There will be legacy browsers around for a long time. They will see a lower-fidelity presentation but they will be able to get the content out.

> I always think that most good flash
> developers have great knowledge in
> JavaScript development and semantic
> markups

Most Flash developers know more Photoshop than Web development.

> Anyway, learning as3 is still not a waste of time

It is if you want to make Web content. FlashPlayer is dead. I do both Web and Flash development, and have the Flash authoring tool on my Mac, but even I don''t have FlashPlayer installed in my browser. The security risks are too much, and there is no conceivable way FlashPlayer will be universal again now that the Web runs on 20 platforms.

If you want to make a game in Flash and publish as a Mac/PC app, then by all means. But if you want to develop for the Web, learn HTML, CSS, JavaScript and the DOM. That is HTML5.

@Hamranhansenhansen -

Well, please take a chance to re-read what I wrote. I''m actually saying Flash will fade away soon and HTML5 is the future. I just want to clarify few points.

''But, it’s not ready right now (but very soon, as long as all browsers are committed to it)''
Did you just ignore what I wrote in the parenthesis so that you can do some Flash-bashing? I agree, people will use HTML5 technologies even when they are in draft mode. But still it takes time. Have you considered that: Many clients are still using IE6. Not everyone''s using Safari. Gecko browsers still don''t have as much support as Webkit. What about the video codec (H264/OGG) issues? Canvas support in IE? Javascript rendering speed in older browsers? There are still a lot of concerns that need to be addressed. Don''t you agree it takes time for HTML5 technlogies to be fully adopted? Don''t you agree if there''s anything that''s uncertain, you need to build fallback? I know there''s backward compatibility. But you know, it takes time/money/effort to build fallback - not just sticking a link in. For example, HTML5 video players need Flash as fallback... CSS needs to be reconsidered for different browsers depending on their HTML5-readiness (full/mid/low/none). So doing all that extra stuff to achieve graceful degradation would add more complexity to the website. Don''t you agree we have to do a lot of those kind of preparations right now? And perhaps by the end of the year, we will do less? That''s all what I''m saying - I encourage everyone to start using the new features. But there would be a lot of degradation to do (and you want the degradation to look acceptable and function well). And for complex interactivity, which Flash excels in (I''m not talking about accordion menu/slideshow), would take more effort to build because of those degradation considerations.

By the tone of your post, I know you''re a die-hard open-standard preacher. But, next time, before you do the bashing, please be more open-minded. You used the word ''reality'', but I don''t think you fully understand it.

"Most Flash developers know more Photoshop than Web development" - Well, take a chill pill - it''s not okay to attack individuals. I''m sure most flash developers are proficient with more things that you could think of.

There''s security problems involved in html 5 - local storage, etc. Before they fix that there''s no reason go HTML 5. I like Douglas Crockford - he brings a lot of common sense to html, css and javascript.

I would think XHTML and Javascript are the most basic you should learn for the Web. Anything beyond that, like CGI, PHP, Flash, AJAX, XSLT is secondary.

HTML 5 is not the end all of the web, you can''t do half the stuff you need to do with it. Remember html5 is 100% stateless and Web 2.0 was / is all about being full state. People want interactivity. Try writing a web based chat system with html5 and javascript alone? You can''t there is no interactivity. Now you could try and jimmy rig the system, and have it use try and save information to a general location that is read by other users constantly, but the bandwidth used on empty requests would kill the efficiency.
So you can''t say just go with html5, javascript, CSS. They will get you a great start but won''t get you anywhere on the web. They are the fundamentals, they are the alphabet you must learn before you can read and write that novel. However they are nothing more than your core. You will have to learn a higher level language, PHP, ASP.net, Jscript, flash, silverlight, etc the list is a mile long.

Now for the whole plug-in fight, sorry to say it but plug-ins are here and will be here for now to the end of time. Cause they provide standards that don''t take 10 years to update, and incorporate. Silverlight comes out with new abilities, functions, and standards every year sometimes twice a year. As a developer my ability to do work and be efficient is much greater with a plug-in. A prime example of html vs plug-in is the google pac-man. Took html standards 30 years to recreate a game that ran on machines with little more than 256k ram. Also go download all the code, its a coding nightmare.

Yes you can animate with html5 and javascript, but its a ton of code to do basic animations and they all have to be handled by the browser''s javascript engine and we know they are all very different. Even if everyone went to using the same javascript engine, (never happen its where you get your browser speed) its still a bunch of work to make a simple button or piece of text slide across the screen. Cause plug-ins have their own standards and how they animate they have great GUIs and programs that do the work behind the scenes without the need to animate through the space.

Also security plays a huge huge role with why html5 is not going to be the end all ever. There is no way to protect your code with html5. You write an application and the world can just copy and paste all the code and add it to their site. Proof of concept, I played around the other night with turning the Google pacman game into a facebook app. If I was one to "steal" I could post the app on facebook with a note saying thanks Google for the hard work.

Not to mention the evils of local storage and the fact there is no real cross domain security around the local storage. html5 is a nuclear landmind of security issues. Look at all the malware almost all of them use javascript to change the browser to point to proxy servers, and create fake pop-ups that clikcing on X causes you to install the virus. Imaging the web when its a requirement to always run javascript. I will once again be gainfully employed by repairing malwared machines.

now I am all for open standards and html5 needs to come. As plug-ins have a ton to gain from the added core. Just don''t think for a minute plug-ins are going away. I see them going more of built into browser mode more than going away. Just like google is doing with flash where you get the new version of flash via doing a chrome update. Basically I see a CDN (content delivery network) setup for plug-ins where you browser just checks on start up for out dated plug-ins and updates them, for you. Just like Firefox does for its add-ons, its painless and takes no time at all. You open the browser get a request to update add-ons and poof you have the latest and greatest plug-in version.

Hi Nishant,

I''m not sure it''s accurate to say to that JS is a bridge to C#. The base syntax may be similar in some ways (it''s similar to C and Java as well, but only on the surface), Syntax similarities is as far as the JS to C# bridge will lead you (you''ll arrive in a happy village of curly braces, semicolons and parentheses - but the languages spoken are very, very different - you''ll need a translator).

C# is strongly and statically typed, imperative and object oriented. You already know this, of course. JS, on the other hand is essentially the untyped lambda calculus, dynamic (no types) with functional characteristics and no notion of OO (classes, interfaces, etc). You get objects and prototypes (and exceptions, continuations, lists, etc).

JS is in fact a better IL than IL (for the web), but that''s another story.

Thanks for the post. Hopefully, I''ve not added any confusion to this opinion cocktail.

C

Ah, come on. This web thing is never going to catch on anyway.

Once upon a time there was this language that promised it would be able to run everywhere and was the cure for all that ails you...

About the same time came along a markup technology that claimed that one day it would run on everything from your PC to your refrigerator and which was *also* the cure for all that ails you. Big, smart tech companies of that time poured bank vaults full of cash into both technologies, but especially the second, based on the (sane) belief that they should get some skin in game just in case it really took off.

It did really take off, and spawned whole new tech giants, but the second technology was dogged by a paucity of capability. Many egregious, and some creatively brilliant, workarounds were devised to overcome the second technologies shortcomings, but even then most agreed that new standards with new capabilities were required. Even as these new standards emerged, the client technology had to be upgraded to support these new standards, and many standards took so long to emerge that clients just implemented their own proprietary standards. Many hacks were devised which relied upon sniffing out the client''s capabilities so that code specific to the client would run and other code would be stepped over or not even sent down the pipe. Some decided that more discipline was required, (it was), but each client manufacturer soon realized that they''d rather opt out of following standards or permit their clients to devolve to looser standards rather than commit suicide because they didn''t support what some painfully slow international standards body thought was proper.

"Looser standards are what''s required now", the body eventually concluded via some byzantine collective thought process, and decreed a new standard that would be more forgiving than the "correct" one they had touted before.

Many acolytes proclaimed that at long last this was it! Nirvana will arrive soon! It will have complex, client side data persistence to make up for it''s lack of state! It will have many new features, and support only the best of all the previous features that came before. We just have to wait for those same client development houses to catch up and implement the finalized set, because very soon everyone will agree that it''s good enough and no new capabilities will be required.

If this sounds likely to happen, would you be interested in buying a vital transportation asset in the NYC metro area I''d like to unload?

The solution is not to make the web as good as a native app, because native apps scratch different needs and requirements which are specific to and tuned for the form factor of the device they run on. This is why developers balked when Apple said that only they would be allowed to write native iPhone apps. (And some people think Jobs is infallible?)

We don''t need more powerful web apps that will run on everything with ever expanding ripples of technical compromises. We need the capability to make native apps as easy to create as web apps. No compromises, no hacks, no limited capabilities. How would that be done? By adopting an architectural model and development methodology that makes the native UI an afterthought. By permitting multiple native clients to use the same common backend. The future is thin "fat" clients, not ever more complex thin clients. The future wants competent UI designers and *professional* developers. Cut and paste programmers and web scribblers need not apply.

HTML5 is great an all, but by the time it becomes wide spread enough that you can invest in it as a platform, the idea of page centric web content will be history.

Seriously, do you really think that the web will stay with this old technology for much longer? 20 years of web pages. RIA is the direction things are heading.

Couldn''t agree more with the sentiment of this article. Brilliant and honest. I have been saying exactly this to my students for years now. With HTML CSS and Javascript what is there that can''t be done on the web?

@Charles—Valid point. I think I should have been clearer. You can''t do real OOP in JavaScript, but faking it through the prototype chain is often way more complex; take a look at the "jQuery source":http://code.jquery.com/jquery-latest.js, for instance. I am simply saying that if you have the aptitude to fake OOP in ECMAScript, then you most likely have the aptitude to play in a real OOP environment. I actually saw this play out in the Flash community. I watched ActionScript go from being a collection of functions like gotoAndPlay() to fully object-oriented. That in itself was pretty amazing, but what was truly interesting to watch was how the community went from writing disjoint code attached to frames to writing OO ActionScript complete with strong-typing, namespaces, design patterns, etc. In fact, it was the community that drove the need for AS 2.0 because of the popularity of __proto__ and prototype chaining. "Here''s an example":http://www.actionscript.org/forums/showthread.php3?t=4536 of Penner talking about it in 2001 when ActionScript was still in v1.

HTMl5 is definitely gioing to be the future, but I think adding fallbacks for non-supporting browser for every HTLM5 feature isn''t the right way.

Html 5 will be pretty good, however, what makes anyone think that browsers will embrace/render this wonderchild of markup remotely the same? Browsers have been around how long? And they can''t agree on the color of shite--and I''m thinking they never will-which is fine. I''m sure I''ll use it, but to think it''s a game changer, well, I doubt it. Didn''t a brain trust comprised of similar people say the segway would change the world? Yeah, thanks for that...