The random utterances of David Arno

HTML5 must not become the future of the web

HTML 5 LogoIn the beginning there there was simple HTML, which sought to define documents in an abstract way, leaving the browser free to render it as it saw fit. Whilst a great idea in theory, it didn’t work in practice as designers of web sites wanted their sites to look the same on every browser, rather than be at the mercy of the browser’s rendering engine.

Fast forward twenty years and things are very different. These days the humble HTML page has been pummelled into submission and supplies the designer with pixel-perfect rendering via CSS, JavaScript and a range of ACID-tests that encourage all browsers to behave the same. Yet beneath all this, the HTML at the heart of the page remains largely unchanged. Even the near-mythical HTML5 – which will likely take twelve years to become fully adopted – seeks to add just a few tags to the HTML specification.

HTML5 by itself offers very little as it simply defines a few new tags. For the full power of HTML5 to be utilised, one must turn to CSS and JavaScript. This combination of HTML, CSS and JavaScript is a messy framework that has evolved over time. In the context of the MVC model for example, HTML is the model (as it is supposed to only contain data), CSS is the view (as it is supposed to define the page’s appearance) and JavaScript is the controller. In practice this separation of concerns is a prestidigitation, as – for example – HTML tags such as <EM> form part of the view, for they define appearance and a simple HTML page can form the entire view if one chooses.

Whilst the HTML CSS and JavaScript framework has many problems, its biggest problem is JavaScript. Few people would argue that it is anything other than a half-baked toy language that does not scale well. Part of its problem is that pages serve up JavaScript source code to browsers, so any changes to the language require all browsers to be updated to support those new changes. Further, any changes to the language have to either remain backward compatible with older versions of the language, or browsers need somehow work out which version they are being served, without there being a way of annotate the code with this information.

These limitations of JavaScript resulted in the progressive ECMAScript 4 standard for the language being abandoned. In its place, a half-hearted bodged update was offered up first as ECMAScript 3.1, then – disingenuously in my view – as ECMAScript 5. Not only is this source-code based delivery of JavaScript a huge impediment to the development of the language itself, it also forms a huge barrier to browsers adopting support for other programming languages.

There is an alternative to serving up source code that works well in a growing number of situations, eg the JVM, CLR and Adobe’s Flash Player. All of these technologies serve bytecode to the execution engine, rather than source code. As the bytecode specification of each is open and published (or mostly published, in the case of Flash), any number of source languages can be used to generate code that will run on these virtual machines (VMs).

One of these VM technologies – Flash – has become a web hot topic of late due to Apple deciding it was a threat to their business model. This has given rise to much talk of HTML5 being the Flash-slaying future saviour of the web. Folk who talk of HTML5 replacing Flash are missing the point completely though. The web doesn’t need more gradual – near-stagnant – evolution, it needs revolution: we need to kill off HTML and replace it with an open-standards Flash equivalent.

The DOM lies at the core of this. The DOM is at the heart of a browser’s representation of a web page and so the DOM would remain. Currently HTML, CSS & JavaScript are the only way of controlling the DOM within the browser. Flash SWFs offer an alternative solution to this. A SWF is a package of assets (images, sounds, components etc) and bytecode. By expanding browsers to support some open-standard package-based web content, we could pave the way for both a true replacement for Flash and a more modern, flexible and scalable web specification.

Whether these packages are binary or text-based isn’t important. What is important is that we stop talking about tags and start thinking in terms of components within the DOM and attributes of those components. Having <table> and <em> as equal-class citizens would finally make no sense (it actually makes no sense anyway with the “HTML describes the data, not the layout” argument of CSS-philes). Instead we could have a sensible hierarchy of layout components – which would end the ridiculous tables vs divs/css for columns war for example – and content components, which would replace the current HTML. We could keep the idea of CSS, as it works just as well for Flash as for web pages. The biggest benefit though would be the long-overdue retirement of JavaScript as the only web programming language.

Many people talk of HTML5 as being the future of the web. Some do so as a result of having won the war against Microsoft over HTML being an open standard. It makes sense that this people now want to see an end to the use of the proprietary technology – Flash – within HTML pages. Others do so simply because they are Apple fan-boys, which is another topic altogether. The open standards crowd have a valid argument, but from the perspective of a web developer, Flash is a true joy to develop with compared with HTML, CSS and JavaScript, so their argument is tempered by the ugly technologies they promote. So in conclusion, I really do hope that HTML5 isn’t to be the future of the web, for we will have missed a chance to really make the future web great if it turns out to be so.


Share This Post...
41 comments so far, click here to read them or add another

41 Comments so far

  1. RobMcM May 12th, 2010 14:44

    Interesting read David.

    However, some thoughts.

    There is a need to understand the difference between web resources such as documents marked up as HTML through to applications built using web technologies.

    The flash player and the canvas tag are essentially doing the same thing. You could write a framework to render components to a canvas tag, just as flash does to the area of the screen it is rendering too.

    JavaScript is fine as it is, just as C is fine. However you can extend and create super sets of these languages to add functionality, like C++, C# or Objective-C. Look at Objective J for example. You can also compile down to JavaScript, look at GWT…

    Taking GWT, or Capuchino you need not know anything about HTML, CSS and JavaScript in order to make applications for the web. Just like you don’t for creating Flash applications.

    Imagine if we had the competition with the flash player that we do with Webkit, Trident, Gecko, Opera, not to mention the JS engines, etc etc. Perhaps we wouldn’t still be waiting for 10.1

  2. George Bashi May 12th, 2010 15:02

    This all holds true, until we start to remember some facts. For instance, let’s forget that there’s not one holy version of Flash; in fact, we’re now on the 10th release, which has to be backward compatible enough to support three entirely different languages (AS1/2/3), all with different bytecodes / VMs. Then if we factor in hidden APIs to support Flex, major features (codecs? security restrictions?) added, removed, and subtly changed between minor versions, we’ve got a huge mess on our hands. Not exactly the handful of well documented versions of the JS spec.

    I’m not sure how familiar you are with HTML and the DOM, as you seem to miss the distinction between block and inline element (hasLayout, in IE parlance) – table and em aren’t equal class citizens and aren’t intended to be. Also, I think the internet got over tables vs divs around about the time when we figured out how to float and position correctly. If having elements like these cause you too much pain, you can just create a canvas the size of the page and start freeform rendering to your hearts content.

    If your argument is that you’re locked in to writing in Javascript, then go ahead and use something like GWT that will compile down to Javascript – this is no different to compiling C# down to .NET CLR for example. If you’re concerned that HTML / CSS / JS takes away some flexibility, remember that one of those HTML5 tags you’re glossing over is canvas, which allows completely freeform rendering, which is already being hardware accelerated in some browers (soon to be most), something that Adobe are just now getting round to in their 10th release.

    Unfortunately, we don’t (yet) have a GUI tool for animating kittens like Flash does, so for the time being you’ll have to roll your sleeves up, learn Javascript, and write some code, but I can’t say that’s a bad thing. Moving away from a buggy, proprietary GUI based tool towards a standards-defined, open spec seems like a no-brainer to me really.

  3. Rich May 12th, 2010 15:09

    I agree for the most part that a revolution would be the only solution…however not necessarily in the way you suggest. These technologies, all of them, work or else there would be no need for them. The blurring of the edges between presentation/control and data is not the making of these technologies but those people that develop in them who are too lazy to ensure they do keep them separate.

    As you’ve said we should stop thinking in terms of tags e.t.c. well why?? It represents exactly what it is meant to, changing to a different language is essentially just changing the factory used to create the representation.

    As for not needing to know anything of html/css/javascript e.t.c to make apps for the web that is true, but without this knowledge your doomed to repeat the inadequate drivel that lazy developers produce who simply can’t be bothered to learn about the forum for which they are writing to.

  4. Andreas Rønning May 12th, 2010 15:26

    HTML/CSS/JS is an abomination, and it blows my mind that not more people instantly see this. Even in the Flash community we all realized that putting our logic in animation frames was absolutely bananas for any developer, moving towards more traditional development methodologies. On the flipside, the HTML/CSS/JS community (if you can call it that) seem adamant in their belief that the clusterfuck in which they operate is somehow good because it is open.

    Version control of an open standard is the achilles heel of any open source attempt to break into the mainstream. This is why there are shit tons of Linux builds, and why jQuery (admittedly brilliant as it is) changes the JS linguistics to an almost unrecognizable state; “You may know JS, but do you know jQuery?”

    HTML/CSS/JS is eating itself from the inside out. Its “platform shareholders” attempt time and time again to wrap the core tools in non-standard methodology, which is just as prone to deprecation as the core tools change over time. They KNOW their basics, like C++, is a pile of shit to work with, and rely on libraries to produce the best content possible within the confines of the paradigm. It is ironic to be so obsessed with standards, yet pursue non-standard implementations at first opportunity. Say what you will of Flash; We have been working within our framework, and happily so, for every consecutive version update. Relatively speaking, it’s been heaven. Ignoring Flash, why do you prefer less than heaven, when HTML/CSS/JS stands squarely in the way of that?

    I am MORE than ready for an open standards Flash replacement. But the HTML/CSS/JS “empire” needs to be toppled, and hard. It’s holding us back. Looking deep into the future, I’m hoping canvas/JS will become a new standard, and we can murder CSS/HTML once and for all, with JS maturing into an actual developer’s language.

  5. RobMcM May 12th, 2010 16:28

    @Andreas

    You say, “I’m hoping canvas/JS will become a new standard, and we can murder CSS/HTML once and for all”

    yet Adobe are trying to push MXML (HTML), FXG (SVG), CSS (CSS), AS3 (JS), which is more or less the exact same stack.

    Also remember you can have an HTML page with nothing in it other than JS to create elements directly on the DOM. You can apply style in a style tag, without having to worry about the C or the second S is CSS.

    I do like your comment that, “t is ironic to be so obsessed with standards, yet pursue non-standard implementations at first opportunity.”

    However this is due to poor and varied implementation of standards, not just because lack of features, and although something like JQuery is not a standard it is open source. In much the same way Flex is.

    Also remember your views seem to be entirely based on HTML/CSS/JS as a development platform for applications. It also is responsible for a lot more than that. Perhaps if you are looking for just a development platform you should look to just the Canvas tag and JS, or a superset, but respect the rest of the stack and leave it for those that need it…

  6. David Arno May 12th, 2010 16:47

    @Rob,

    I do not see the canvas tag and flash as doing essentially the same thing. Rendering text in a canvas tag would be an odd thing to do for example. Flash and the web page are essentially the same thing: a way of presenting information to the user within the browser.

    You claim you need to know nothing about JavaScript to use Capuchino. This is fine in theory, until something goes wrong. At that point you not only need to try and debug JavaScript, its JavaScript you didn’t write, which makes it an order of magnitude more complicated.

  7. RobMcM May 12th, 2010 16:56

    @David

    Rendering text in a canvas could be done, it’s up to libs, tools or frameworks to implement, look at bespin for a great example :)

    True that debugging Capuchino without know JS would be a pain, but then so would debugging MXML without knowing AS3. Ideally Capuchino and it’s IDE (Atlas) would take care of this for you, more like GWT would. Any bug in either, you could argue, is easier to resolve than a bug in the Flex as you could fork the project ;)

  8. David Arno May 12th, 2010 16:58

    @George,

    You raise a good point with regard to Macromedia and Adobe changing the bytecodes on a whim for successive versions of the flash player. Such is the nature of a closed, proprietary product like Flash. The Java Virtual Machine offers a far better model for maintaining a backwardly compatible VM as very few features added between Java 1 and Java 6 have needed bytecode changes. Whilst I suggest we replace HTML with something like SWFs, I’d not propose we copy the bad aspects of SWFs, instead we should learn from those mistakes.

    GWT is a bodge and is nothing like writing an application in C# and running it on the CLR. One develops and tests a web app/ page in a Java-like language against the JVM, then one crosses ones fingers and hopes it all works the same when converted to JavaScript and run on a browser. If it doesn’t then one is screwed as there is no practical way to debug the resultant JavaScript. It would be far better to have browsers support any language compiled to a bytecode as one can then debug the source language directly (assuming the language author creates a suitable debugger of course.)

    To me the true no-brainer is that moving away from a crappy, difficult to work with, toolset of HTML, CSS and JavaScript to a high quality, scalable, flexible and powerful toolset akin to Java, C# or ActionScript is a blindingly obvious thing to do.

  9. Paul V May 12th, 2010 18:41

    Hmm… If we got to choose the “Future” technology based on what was a “pleasure to develop with” we would still be be plowing our fields with mules.

    Innovation is born out of necessity not preference. HTML5 is the future because it breaks down certain barriers and limitations that we have with current technology. Flash is great, I love it, but it is a friggin plugin and has a huge amount of limitations, most of them with accesibility… for instance blind people cannot use a site built in flash, nor can the search engines figure out the importance and order of content within a flash movie.

    Sorry MVC pattern cannot be applied to HTML/CSS/JS… it just doesn’t fit not by true definition of MVC anyhow.

    I’ve always said, “Don’t align your self with a technology, or you will become obsolete when it becomes obsolete”.

  10. Justin James May 12th, 2010 18:47

    A couple of quick points here…

    First, I beleive that HTML should be solely for documents which can provide hints for styling and really just hand over control to the browser to render them. This whole notion of trying to precisely control layout and presentation is rediculous. Indeed, if folks weren’t so hung up on presentation, there would be little need for mobile versions of Web pages or printer-specific style sheets, because the device would just render as needed.

    Personally, I would love to see HTML be replaced by something like Silverlight, Flash, Flex, etc. for client-side processing, and X11, Terminal Services, etc. for server-side processing. But the genie is out of the bottle on this one, and I have no clue how to put it back.

    Secondly, I think you miss a huge problem around tags like <em>. *Nowhere* in the HTML spec does it say “<em> gets italicised”. That is an *assumption* made by HTML authors because every browser out there *chooses* for <em> to be italic in their default style sheets. If I wanted to make a truly awful browser, I could make <em> display in hot pink or in superscript, or whatever I considered “emphasis”, just to prove a point. Of course, no one would use the browser because it would not conform to HTML authors’ expectations, bespite being HTML compliant. Much of the complaints folks have about some browsers is not that they truly deviate from the HTML spec, but that they deviate from what that person’s favorite browser happens to do.

    This brings me to HTML 5. You are right that it does not introduce many new tags, and that most of its functionality is around non-document stuff, like sockets, “web workers”, and other things which support HTML as an applications platform. But what it *does* do, it really nail down the vague spots and make it much harder for two 100% standards compliant browsers to render a document differently, outside of the default style sheet. Error handling, for example, is much more clearly defined.

    J.Ja

  11. Justin James May 12th, 2010 18:49

    If there is one amazing piece of trash application on the market, it is WordPress. It proves your point and mine, that HTML should not be used for apps. In this case, it did not escape my use of < and > around the em, and just emphasized half my post.

    Hopefully, readers will be able to understand what I meant based on context.

    J.Ja

  12. Scott Tadman May 12th, 2010 19:59

    I’m amazed that the web has continued to muddle along using half-baked standards and a complete lack of architecture. Your observations on the disjointed nature of HTML vs CSS vs JavaScript are right on, especially when considering none of them fits neatly into even one of the conventional MVC containers.

    While bytecode shipping is perhaps a better way to manage shipping of executable assets, anything inherently “binary” is anathema to the philosophy of an open web where “View Source” is but a click away.

    That being said, there are two things that would help push these things forward in terms of efficiency:

    * Simple, standardized, packed binary representations of HTML, CSS and JavaScript such as JSON vs BSON (Binary JSON) were there is a 1:1 mapping between one and the other.
    * A way of packaging multiple assets together as is done in a .swf file, or a .jar for that matter. It is sad that we have to resort to JS and CSS “minimizers” to simply get some efficiency that way.

    Sometimes I wonder if it’d be possible to create an alternate W3C to push for implementation of renegade standards such as these.

  13. David Arno May 12th, 2010 20:14

    @J.Ja,

    I’ve fixed the <em> parts of your comment so it hopefully makes sense now. It would be useful if WordPress did this automatically as you say. Time to look for a plugin methinks :)

  14. progr May 12th, 2010 20:16

    “one must turn to CSS and JavaScript … is a messy framework … so any changes to the language require all browsers to be updated to support those new changes.”
    Welcome to Web 2.0 man. A world where nobody uses JVM and CLR. A world that is abandoning Flash. Maybe you should take a look at what web designers are doing today.

    “we need to kill off HTML and replace it with an open-standards Flash equivalent … and so the DOM would remain … components within the DOM (?)”
    This is hilarious. Only because you don’t know how to program in html+css+js this doesn’t mean the every other programmers and web designers around the world (and search engines and I can continue) must move to a web driven by a proprietary plugin. Open your eyes. Why doesn’t flash dominate the web? Why nowadays everybody are abandoning flash?

    “Some do so as a result of having won the war against Microsoft over HTML being an open standard.”
    Uh? I mean, uh?

    “so their argument is tempered by the ugly technologies they promote”
    Do yourself a favor. Grab all the flash books you have studied for years, put them away and accept the fact that the world is evolving.

  15. James W May 12th, 2010 21:31

    I it is a common misconception that Javascript is a “toy language”. When you get to learn it, and you are abstracted away from the inconsistencies of the underlying browser in which it so often is found you find that it is a powerful and beautiful language. I have trained in COBOL, used Basic, Pascal, C, Visual Basic, Java and c sharp but find it the most flexible and satisfying language I’ve used. With the rise of JIT compilation engines such as Google’s V8 engine, it can also be used professionally and commercially.

  16. David Arno May 12th, 2010 22:53

    @progr,

    Please re-read what I wrote and try again. At no point did I suggest we move to a web driven by a proprietary plugin. In fact I very clearly state the exact opposite: that it should remain based on a open technology.

    As for the gibberish about everyone abandoning Flash: you have been swallowing the nonsense spouted by Jobs, more fool you.

  17. David Arno May 12th, 2010 22:57

    @James W,

    It is not a misconception on my part that JavaScript is a toy language. It is my opinion that it is. This opinion is based on the fact that JavaScript lacks a great many features of fully-fledged functional and fully-fledged imperative languages. It cannot therefore be seen as either style of language and so is not a true software-engineering language solution. Thus it is a toy language.

  18. [...] Design: HTML5 For Drunks HTML5 must not become the future of the web Designisnowhere Women In Web Design: Group Interview Thanks, but no thanks Web 3 Uses Flash: Five [...]

  19. George Bashi May 12th, 2010 23:30

    Some good points here. One thing I still take issue with though is Javascript being a “toy” language: I’m sorry, but I really don’t see what it’s missing that stops it being a “big boy’s toy”, especially in comparison to AS or other “scripting” languages?

    As a general thing I don’t see that replacing divs/canvases with MovieClips, and JS with AS3, really gets us anywhere? Are you wanting something more like XUL?

  20. Jostein May 12th, 2010 23:40

    I have built proffesion software, using software-engineering concepts of components and modules in a language solution system with fully fleged core-based expressional constructs of interoperable dynamically injected business e-commerce cloud services solutions for high level enterprise deployment environments with centralized JavaScript execution in a highly distributed bidirectional location. Thus it is my view that JavaScript is a serious language.

  21. Jonas Huckestein May 13th, 2010 00:39

    Don’t worry, HTML 5 will not become THE standard. In fact, I don’t believe there will be “a” standard. The way the web is evolving (consider ChromeOS), it does indeed not make sense to use the HTTP/HTML/JavaScript/CSS stack to develop ALL applications.

    On an abstract level, we only use that whole stack to deliver software and data to a thin client that then renders it. The real paradigm shift here is that all software only ever needs to be deployed once in the cloud and will be shared by all it’s users. This has nothing to do with JavaScript or CSS and there will most likely be many languages available to develop your webapps in.

    Take a look at this http://blog.chromium.org/2010/05/sneak-peek-at-native-client-sdk.html and maybe the “Beyond JavaScript” sessions at GoogleIO

  22. Martin May 13th, 2010 03:57

    [anti-flash rant by an Apple fan boy deleted as off-topic]

  23. David Arno May 13th, 2010 08:06

    @Jostein,

    Clearly I was wrong when I said few people would argue JavaScript is not a toy language. I had assumed everyone forced to use it by circumstance simply tolerated its inadequacies. People’s tastes in programming languages can be strange indeed.

  24. Jostein May 13th, 2010 14:10

    Hehe, I was partly joking. :)

    But I actually think more and more people are starting to like JavaScript more and more.

    The language by itself is really nice and it has got some cool concepts not found in other languages. It’s actually a very consistent and simple (not as in toy) language while at the same time being very flexible.

    Check out this video with Douglas “I’ve got bigger guns than you” Crockford, talking about JavaScript – The Good Parts: http://www.youtube.com/watch?v=hQVTIJBZook&feature=youtube_gdata

    And if you want to decouple the notion of JavaScript = Browser language, take a look at Node.js (nodejs.org). Using the V8 engine of Chrome to run server side (and other stuff) Javascript with scalability, simplicity and high performance. With Node.js, since you don’t need to concern yourself with the browser’s rendering quirks, JavaScript starts showing more of its beauty.

    But browsers have been fixing a lot of rendering quirks lately, faster than ever, and quirks are quickly becoming just shameful bugs – what they always have been. People are starting to expect bugs in browsers to fixed as well, just as they do with all other software.

    HTML, CSS, JS has finally got a chance to become something which even “serious” programmers wouldn’t think of as a toy. And yes, it will most definitely grow and evolve stuff that you mention you want, inspired from Flash. It’s already happening.

    Also, I think someone told me ActionScript is actually based on JavaScript…

  25. kazoolist May 13th, 2010 18:33

    “Few people would argue that [JavaScript] is anything other than a half-baked toy language that does not scale well.”

    Either count me as part of the “few” or admit this is a bunch of FUD/ignorance on your part.

    JavaScript (meaning the language and core API) has it’s issues. It would be nice, for instance, if it’s core API included a robust security manager.

    But it’s a very clean language with powerful constructs. And, for the web specifically, there is a plethora of mature, tested, and robust libraries that make getting-stuff-done easy and efficient.

  26. dug May 13th, 2010 23:02

    What is your argument?
    We are all logical people, we all choose the technology we use on a few very logical criteria. Does it limit the effort I have to expend to achieve what I wanted to achieve and did it come for a cost I am willing to pay.

    Being open source the “cost I am willing to pay is reduced to zero, not simply because the tool is free but because other people can make better tools unlike Adobe flex and Flash.”

    To limit the effort “I” need to expend means putting the development platform into a language or format that I am used to using therefore if I use Delphi then a pascal language would suit but most C/Java e.t.c. developers would require a different flavour of a language.

    With regards the “mess” that we are left with regarding css/html and all that jazz. I would say what mess, mess only occurs when developers allow it to, just because a technology allows us to mix presentation and control logic doesn’t mean we should, come on people we can stick java code into jsp files but common sense should stop us from doing this, as mentioned earlier we can stick all html into javascript but again think it through you wouldn’t want to do this. This is analogous to eating your starter main and desert in one go because its all going to end in the same place anyway.

    Everyone so far is arguing their own cause, fighting in their own codes corner when we should REALLY be thinking in a code agnostic manner. Why else would we have different constructs for achieving the same thing in many many different languages stop re-inventing the bloody wheel and realise that to make a web app requires a little effort on your behalf that is why you get paid such an exorbitant amount of money, so shut the fuck up

  27. Zooro May 14th, 2010 01:23

    David you are 100% right… There is not freakin way for someone to claim that Javascript is fully developed language. For that matter when comparing it to Actionscript 3, it can not be considered a language. Forcing developers to do half of what the can do with Actionscript/flex/flash, by cobbling together js/css/html5 is a GIANT STEP BACKWARDS for designing and make RIA. All one has to do is look at some of the HMTL 5/css/js apps that people claim are flash killers. These sites look like Flash when it was called future splash. In the end I feel like I am a web/app RIA designer and will use what ever tools I have, but now I feel like a soldier who had a machine gun and who is now told that in the future they must fight with a bow and arrow.

  28. Rich May 14th, 2010 07:44

    “I feel like I am a web/app RIA designer and will use what ever tools I have, but now I feel like a soldier who had a machine gun and who is now told that in the future they must fight with a bow and arrow.”

    oh please don’t talk such drivel!

  29. [...] Audio & Canvas, and what we can look forward to in the future. Included is a discussion of David Arno’s recent article arguing against the move HTML5 and Lee Brimelow’s suggestion that Flash is built for touch. This week’s WebVisions [...]

  30. Steve Antal May 19th, 2010 03:11

    If JavaScript is a toy language, than I don’t know what is Java and C#, both of them FAILED where JavaScript succeeded.

    JavaScript is not thought well, I give you that, the DOM is not a descent API, but saying that the language is bad, is well: foolish.

    But wait, I will explain this:

    Flash’s language is Action Script, which is ECMA Script, which is JavaScript. So you criticize JS and claim that Flash is superior while Flash Action script is really a JS dialect.

    I’m a little tired to point out all the errors in this article, but there are many more of them.I would certainly update this article with facts instead of some assumptions.

  31. [...] Arno is a programmer that works a lot with Silverlight and Flash, and in a previous post, entitled HTML5 must not become the future of the web, he pretty much calls for the end of web browsers as we know it and a move to something like a [...]

  32. Nick October 20th, 2010 22:27

    Long story short – you’re familiar with flash and since you know it you like it. Don’t worry that’s so common. Even I do. However flash basically sucks and usually adds no real value to a web site except a nice animated image etc. but face it – real content is the text bringing some information to the user and it’s usually html (unless the entire site is one big flash). Try this – block flash with an addon (chrome, ie and firefox have some adblockers or flash-blockers). Missing anything important except some adds you don’t even need? I don’t and since I started blocking flash my browser got more responsive and I am not distracted by ads jumping and flashing everywhere on the page.

    I really hope that people will abandon flash, silverlight and anything similar

  33. David Arno October 21st, 2010 10:00

    @Nick,

    I already have both a flash blocker and ad blocker plugins installed, though these days I have the flash blocker turned off as there is a growing amount of useful flash content on the web. I hate flash adverts, just like you and like the fact that my advert blocking plugin blocks almost all of them for me.

  34. Jimmy Sudekum December 3rd, 2010 08:05

    So wait, let me get this straight… You guys are debating the merits of HTML5 and JavaScript? … Why?

    Not that I don’t understand your points, but why does any of this matter if you can still make beautiful work, anyway? If HTML5, CSS3, Jquery, etc. all help the designer create immersive art, democratizing what was once exclusive to those with thousands of dollars of software, what’s to fear? Shouldn’t a more globally-minded concept of design what we should be striving for?

    To me, this is an exciting, hopeful time and I’m glad to be a part of it. :)

  35. happybetter February 11th, 2011 08:35

    Why HTML-5 and Flash can just be friends? they’re both good for their own usage, make Flash be integratable to HTML-5 and stop the hate about it, specially those I-LOVE-APPLE geeks or STEVE-JOBS-SAY-SO followers. Sorry FLASH will not die and probably HTML-5 will still be on BETA after 10years.

    If you are a developer you won’t care about the two, as long as you are flexible and know the standards, everything will be just fine. There’s no problem if you can work both, right?

  36. James Blake April 10th, 2011 17:49

    I stopped reading at the word “whilst”.

  37. David Arno April 11th, 2011 12:23

    @James,

    I’m sorry you found “whilst” offensive. You are the first person I’ve come across that does though.

  38. Jacob February 6th, 2012 00:07

    It is the future…..

  39. Jacob February 6th, 2012 00:08

    It is not the future…..it is NOW!

  40. max March 28th, 2012 18:50

    HTML5 will NOT be the future, everyone saying it will come out in a few years “killing” flash but really before that even happens, flash will go through numerous updates and be 3x’s better than it previously was leaving HTML5 in the dust to rot. Let the naysayers of flash rot with their ignorant and arrogant attitudes along with the bitchy apple turnip head fan boys, while I enjoy many years of flash with my hardcore windows pc. HTML5 is an attempt to different when it falls flat on its face, flash and its countless endless updates are now the future, :).

  41. PG85 July 9th, 2012 18:44

    I’ve been working with AS2/AS3, Javascript, Jquery, Html, CSS, AJAX, C# and VB with Asp.Net and PHP for several years now designing and programming all kinds of websites, games, interactive banners, webservices and web-applications.

    What has become pretty clear to me (and is once again proven by some comments here) is that most Flash-designers simply are not web-developers and vice versa. In my experience, the difference in mindset tends to be huge. Web-developers understand the nature and evolution of the internet and have a lot more things to worry about such as SEO, cross-browser-compatibility, security etc. Flash developers are used to their safe and comfortable proprietary IDE and sandbox and care primarily about presenting RIA/media/content in an attractive fashion.

    I’ll agree that HTML5 doesn’t even compare to flash when it comes to creating things like games and animations. However when I want to create a web-application that needs to be fast, secure, accessible, portable/reusable, compatible with other web-technologies, easily edited and correctly indexed by search engines I would never even consider using Flash.

    To flash developers who think html+css+js is an abomination for webdesign and think “flash is better”:
    You probably don’t understand how the internet works, how standards are created and how the web evolves. You’ve been programming in Adobe’s little playground, safe, easy, cordoned off, and tailored to your comfort. Unfortunately for you, the rest of the programming world is much more diverse and expansive and there is no 1 company or developer creating all the OS’s, browsers, software and languages required for browsing the web and creating websites (and thank god for that).

    “Few people would argue that [JavaScript] is anything other than a half-baked toy language that does not scale well.”

    For creating animations, yes, for creating webpages, no. When it comes to creating fully fledged websites and web-applications, Flash is the kiddy-tool.