Will HTML ever be replaced?

By Craig Buckler

Ian Hickson (“Hixie” — WHATWG specification editor, CSS2.1 co-editor and Google’s W3C representative) recently published an interesting post on Google+. He’s occasionally contacted by people suggesting a better alternative to HTML but, in all cases, none have come close. Ian states that any technology would need to satisfy at least five objectives to displace existing web technologies:

  1. Be devoid of licensing requirements.
  2. Be vendor-neutral and accept input from everyone.
  3. Be device and media-neutral; it should work on PCs, TVs, mobiles, tablets, screen readers and any future hardware.
  4. Be content-neutral and not restrict itself to types of document or application.
  5. Be radically better than the existing web in every way; faster, more usable, more features, easier to develop, easier to monetize, etc.

HTML can fail objectives two and three. Technologies such as XHTML2 and XForms only satisfied one and three. Java and Flash struggle in all areas — and I’d also add Google’s Dart to that list.

Let’s face facts: web technology never has been and never will be perfect. There will always be shortcomings and compromises. After all, it took 15 years for native video support to arrive and vendors still haven’t agreed implementation details.

However, web technologies have been incredibly resilient despite alternatives offered from Microsoft, Google, Apple, Adobe, Sun and Oracle:

  • HTML has its roots in SGML as it did in the early 1990s.
  • CSS was devised in 1996 and retains the same selector / property syntax.
  • JavaScript has been (undeservedly) ridiculed by developers, but it’s the world’s most-used programming language. It has only received minor amendments since Brendan Eich devised the syntax in a few weeks back in 1995.

All survived because they were the first practical web technologies which could be used without paying royalties. Better options may appear, but it’s difficult to imagine ones which would receive universal vendor agreement and have commercial benefits which offset the substantial investment required to supersede HTML.

Regardless of developer and vendor whims, HTML, CSS and JavaScript are here to stay for some time. I suspect it will take a massive shift — probably the invention of a better Web with a different infrastructure — before they are displaced as core development technologies.

But perhaps you know something I don’t? Gaze into your crystal balls and let me know whether HTML has a long-term future or better alternatives are around the corner …

If you enjoyed reading this post, you’ll love Learnable; the place to learn fresh skills and techniques from the masters. Members get instant access to all of SitePoint’s ebooks and interactive online courses, like Build Your First Website: Getting Started with HTML and CSS.

  • evolution, not revolution. Most of it will be replaced gradually as time goes by, just like programming language.

  • Patrick

    I agree with the basic premise here – the current suite of technologies has survived not because they are good at what they do, but because they got there first. Now we’re stuck with them, and it’s highly unlikely that we’ll ever get rid of them without some major revolution (which is itself unlikely). Even incremental upgrades like HTML5 and CSS3 are problematic, taking many years and a huge amount of developer pain to become widely adopted and supported.

    This is something developers rightly hate, because the technologies we have suck. JS is widely used because it is widely supported, not because it’s a brilliant language (which is not to say that it is particularly bad). There’s a reason jQuery (or a similar library) is almost a prerequisite for using JS on web pages, and that’s because it’s horrible to use without a library to provide a nice interface for simple, common tasks.

    CSS is absolutely, flat-out terrible. I hate it with a passion. It can do simple styling, like setting colors and background properties okay, but it is a horrible, horrible attempt at a layout engine. Simple design ideas – columns, footers that stay at the bottom of the page when content is smaller than the page height, groups of equal height or width elements – all of these are a nightmare of hacks and workarounds in CSS, and that’s before you get to the browser incompatibility issues.

    Even the HTTP protocol is ill-suited to the current ambitions for the web, which is why it’s now being actively replaced or worked around by a number of alternative protocols.

    I’m not entirely sure what the point of this article is. Trying to imagine what may happen 20 years from now is pointless. The question posed by this article is unanswerable. We’ll all just have to wait and see, and hope that next time around we get some decent standards to work with.

    • I agree with you on CSS. It works for styling, but for layout it’s a nightmare. For now, it’s all we’ve got, but as far as I can tell it shouldn’t be too hard to replace. If someone can invent a better language that integrates with HTML, there shouldn’t be any big problems.

      • Patrick

        If it was easy to replace, it would have been done already. It isn’t just the layout issues – even the basic structure of the language is lacking. Obvious features like nested selectors and variables are absent, which is one of the reasons CSS preprocessors such as Stylus and SASS have become so popular. So there’s clearly a big incentive to find a better alternative.

        The reason it won’t substantively change or be replaced is the same reason we’re stuck with all of these technologies – compatibility. If you devised the most perfect styling and layout language possible, and you got support for it into every browser, it would still be many years before it became useable. The web is consumed by a diverse range of browsers and devices, and all of them (or a very large % of them) must support something before it becomes viable for developers to use. Even CSS3 has taken many years to standardise and implement, and many features are still not properly supported, even in the most modern browsers.

        Of course, given how bad CSS is, it would be almost trivial to create a better standard. But are we likely to see one gain support and become useable in the near future? I’m not holding my breath.

      • CSS has vastly improved since it’s early days. I can also agree it’s not the easiest thing to learn, but considering I learned it now it doesn’t bother me personally. During the early days of 2002 it was certainly a nightmare.

      • Patrick

        I’m not saying CSS hasn’t improved since its inception. I’m saying that it still sucks despite those improvements. Where are variables? Where are nested selectors? Where, in 2012, is a decent, non-hacky, useable layout module?

        Undoubtedly CSS3 has brought improvements. But the language is still fundamentally lacking in basic features. Excuse me if I don’t get all excited just because they added border-radius.

    • I have to disagree with you on your comment about JQuery and Javascript. As soon as there have been programming there have been libraries to makes things simples.

      Even C has a very large set of libraries in place to speed up development. Does it make C a bad language for that matter? Nope, it just means that a programming language is just that a: programming language meant to resolve a problem, meant to be broad in it style. That’s very different from a framework which is meant to simply specific tasks at the cost of some performance and flexibility.

      • Arlen

        “…it would be almost trivial to create a better standard” than CSS. True. But also true is that it is nearly always trivial to create a better standard than any given one. The non-trivial part is getting other people to use your standard. The limitation is not in what we can think of, but what others will adopt. The side of the Progress Road is littered with the corpses of Better Ideas No One Used.

        Javascript is actually one of the better languages around; it merely suffers from bad implementations. The DOM interface it is required to use is a drag, true, but once you get the hang of it, is bearable (I’ve written some extensive javascript apps in vanilla javascript). But the resources (in terms of things like heap) available from browser to browser vary widely and inconsistently, so code that works in one browser engine may fail mysteriously in another.

        In some respects, the current javascript situation reminds me of the early days of C, when code was not portable from compiler to compiler. Eventually we had ANSI C and the C Standard Library, and a few years later portability became real. The full jQuery stack will not likely be the Standard Library analog, but its syntax and API will play a major role in it.

        Now that some serious work is being done in javascript, work beyond “make this page block look/feel/act pretty,” we can expect that pressure to make the implementations improve. A simple look back shows this happening at an increasing rate.

        The biggest improvement would come if the W3 would rethink the DOM interfaces, but that won’t happen.

        A more likely improvement would be the replacement of HTTP, not necessarily with SPDY, or indeed anything that is currently in existence. The solution might even *be* a future version of HTTP; I doubt it, but I’ve seen stranger things happen.

        I feel pretty sure nothing will replace HTML and javascript over the next 5-10 years (almost certainly not in 5) but I would hesitate to predict 20 years. We’re currently putting a lot of focus on these tools, and they are being added to. That should make them dependable for the short-term, but long-term what always happens is the effort to retain currency creates issues with the past. I’d expect it more likely we’ll be using something in 20 years that won’t yet be thought of for another 7 or more.

        Returning to the subject of CSS, I see a little more room, there. By killing off the idea of a monolithic spec, and instead creating smaller modules (and by definition, allowing for the creation of new future modules) it may have a chance to last longer, as it has created the possibility for a complete systemic replacement of itself within the bounds of “CSS.”

        The pessimistic card in this whole deck is not the software makers, but the users. How long users hang on to outdated software will dictate how quickly any new tech will rise to replace it. I’m not talking about merely upgrading browsers and OS’s, but any future tech as well. If Captain Billy’s Whiz Bang runs beautifully over the Trombone protocol, and 50% of the users remain on IE8 over HTTP, it’ll be meaningless.

      • Patrick

        Regarding JS libraries – of course, every language has libraries. But a web developer is far more likely to reach for a JS library than they would be to use a PHP library, at least for basic functions.

        In PHP you may use a library to perform some specific task (e.g. sending emails), but you’d be likely to write the bulk of your code in vanilla PHP. In JS, it seems that most developers reach for a library before they tackle even the most basic of tasks – I’ve often seen people add jQuery to a project for something as trivial as adding and removing classes for various elements. You can blame that on bad developers, and you’d be right, but there must be a reason that developers feel less comfortable with JS than other languages.

        My point is that many developers reach for a JS library faster than they would go for a library in other languages, which suggests problems with its usability. It also suffers from simple omissions, like the lack of a built-in debugging tool.

        I’m not saying JS is terrible. I just don’t think it’s particularly good either.

      • Patrick


        I agree with most of what you’re saying. Of course it is end users who are the main barrier to improvements, and they always will be. With most browsers now using automatic updates, we may see the number of people using outdated browsers decrease in the long term – we may eventually have a majority of users staying up to date.

        The W3C is also an obstacle to progress. There are a lot of criticisms that can be levelled at their organisational structure, and also the glacial pace at which they work. And of course, even when they do produce something, it’s frequently broken or sub-optimal – see XHTML, the DOM or CSS for example.

        I don’t think HTML is going anywhere, and I don’t really think it needs to (although it would be nice if we could all agree on things like video codecs). Long-term, I can see HTTP going, and perhaps CSS as we know it too. JS has some competition now, so it’ll be interesting to see what happens over the next 10 years. Ultimately though, I agree – we’re only going to see incremental changes to the existing stack in the foreseeable future.

  • Nenad

    HTML/JS mix will stay king as long as consumers buy the story that they need a faster machine and better GFX cards to run, well, 1988 games on their multi core CPUs and 1GB of RAM on GFX card and they’ll need to upgrade to be able to play 1996 years games inside of the browser, of course. Browsers do a better job where Java and Flash seem to fail – in degrading and slowing down the experience of online content consummation. This will not change as long as major players have their server farms that run fast enough and consumers keep on buying new hardware and gadgets. Tablets took the web yet again ten steps into the past.

    The only future of computing that I see (no matter desktop or web) is a future where OS differences are wars of the past and no they won’t be replaced by mem hogs that ere browsers.

    The code of the future will run on the standardized platform similar to todays JVM and Flash VM, but I think in it’s core closer to C++ and Low Level Virtual Machine. There will be multitudes of syntax flavors, to each it’s own but that will be the core concept. No more desktop or web differences, no more browsers, just services and apps. People will eventually loose interest in hardware and just seek the right experience and information. In the end if you get the information that you need or the right amount of FPS on screen does it really matter what hardware it runs on? Or what version the browser is? The answer is: NO, it doesn’t!

    • Matteo

      I disagree. Innovation and entrepreneurship will always drive an individual as well as the general market. Your utopian “cloud” of information access/sharing will never become commonplace, simply because people expect that their experience will be unique to them and ownable. There will always be a component to the market that allows for personalization and customization. Base cores can never be everything to everyone; differences will continue to exist because people want different outcomes.

  • I think this is a thoughtful article and I enjoyed it. First of all, I love HTML, CSS and Javascript. I don’t see these basic and powerful languages being replaced anytime soon either — I see them improving.

    HTML5 is already validating forms without the need of JS, which is what I thought it should’ve always did in the first place, so this means less JS for common stuff. And I’m glad CSS3 added transitions, now we don’t have to use complex JS for simple fade effects.

    CSS layout will be a whole lot easier once the browser support is here and I see in the future the ability to customize each HTML element with CSS — currently there are some restrictions. So those are my thoughts: HTML, CSS and JS will just get better and continue to be used.

  • Hopefully not.

  • RB

    We should probably be quite thankful HTML appeared when it did – when the big companies weren’t all out for a piece of the pie. If we’d had a couple of Microsofts (at their current size) or Googles in that era, the web might have wound even more commercial and divided than it presently is. Scary thought.

    • Thank Tim Berners-Lee. He devised HTTP, HTML and the first web browser then gave it all away for free. Without that freedom to grow, the web would never have taken off in the way it did.

  • We’ve gone too far to turn back now!

    We can all agree CSS has evolved so far since it’s introduction, same can be said about HTML and the uses of JS. It’s all just works! I don’t see this changing any time soon, instead I see HTML releasing another DOCTYPE as they normally do to keep up with new technologies.

    Replacing one way of doing something with another is never an ideal scenario, it’s far better to evolve, and from HTML’s introduction this is what it’s done time and time again. Since history has been known to repeat it’s self I am confident we will continue down this path.

  • Sorry, how does HTML fail objectives 2 and 3?

    • 2: non-standard tags, APIs and CSS properties.
      3: do your web pages work on every device every time?

      • Eddie

        Your answer to 3 is off because the developers of HTML DO NOT control the manufacture of the devices.

      • Danny Bullis

        2: Non-standard tags are also affected by vendors, right? HTML can be very XMLish, since there’s nothing preventing you from creating your own tags – the browser might not accept it, but JavaScript does! Which means you can create BS attributes in your HTML that is only important to your JavaScript, and is a hackish little way to be able to write complex apps using a variety of data that could otherwise get difficult to keep track of. Call me a rogue, but it works for me :P

        3: Wouldn’t this be more because of how the browsers / devices are implementing the HTML? I.e., IE for example :P.

        There’s been a huge push for standardization across the board, both by vendors (for the most part), as well as the W3C. These vendors, by the way, are some of the largest corporations in the world – Facebook, Google, Microsoft, Amazon, Apple…Companies that have their own browsers and / or a huge web presence, and a huge strategic interest in the viability of HTML.

      • Sorry yes, there’s a conflation there, HTML for HTML/CSS/JavaScript. I agree that a real webpage will fail on some devices.

        A plain, unstyled HTML page will deliver meaning on any device. It’s ultimately just a text file. There is great strength in simplicity.

  • Think HTML and JavaScript will stick around, but developers will get abstracted away from it further. Similar to how machine language/assembly is used, but mostly via higher level languages.

  • What we have today works for us today because it is free and it is good enough to do what we need today.

    Tomorrow, what we have, will work for us tomorrow because it will be free and it will be good enough to do what we need to do tomorrow

    Anyone who expects that html/css/javascript will be replaced by something that ‘does it properly’ – well we can all dream, I suppose!

    • aaron


      Our demands and solutions grow together. Will anything displace HTML? Probably, but only when our usage changes so drastically as to demand it. And with how different our web-experience is today from even 10 years ago? It might be a lot sooner than we think.

  • Thoughtful article! Like many others I think the technology is to stay. One thing that may and should be changed is the uniformity and consitency of browsers.

    Smarter browsers are nice to have, too – where browsers can somehow intelligently decide how to display font size, banner size, navigation etc. to fit screens of handheld devices – if there’s no display instructions from the code (by web developers).

  • Danny Bullis

    I think the real question is whether new technologies will warrant the need for a different language. I’ll illustrate my point from the web-app / mobile-app angle, since I’m an web-app developer, not just a website developer…

    People might have thought that with the smartphone market having blown up, that HTML would become less relevant, given that native mobile apps are arguably more useful and therefore more used. However, I’m a recent convert to Adobe PhoneGap, which allows you to write native mobile apps across at least 6 different mobile platforms — all written in HTML5, JavaScript, and CSS (btw, I don’t work for Adobe). I’ve used it and it’s sweet. Instead of having to manage an app written in multiple languages ($$$), I’ve found I can accomplish my particular task using the HTML5-PhoneGap approach. Best of all, I get to use HTML5, JS, and CSS which are MY native languages.

    Of course, there are drawbacks, trade-offs and the likes. My point is that HTML5 is great for what it does and will do so in the foreseeable future. So instead of replace it, I think it’s best to reinforce it to help it stay relevant. PhoneGap is a huge success here. JQuery is a huge success for JavaScript. Etc…

    Thanks for getting my gears grinding on this one! Cheers

  • I agree with Ngan Tengyuen that it will be mostly evolutionary. I suspect the biggest changes will only be feasible by building on top of the existing technologies, sort of wrapping them. It’s happening with both CSS and JavaScript. It may eventually result in direct support of LESS/SASS/Stylus and CoffeeScript/TypeScript and dynamic/templating HTML with polyfills while support gradually builds.

    • Certainly HTML, CSS and JS improvements will be evolutionary. However, I suspect it will require a revolutionary alternative technology to displace them.

  • Any new standard would require at least 98% market penetration to be a viable platform. Microsoft couldn’t manage it with Silverlight. Adobe couldn’t maintain it with Flash. Google will fail with Dart. I suspect we’ll have HTML/CSS/JavaScript for as long as we have the internet.

    • Actually, with regard to users, Flash did achieve something close to 98% market penetration on PCs (admittedly, the story’s different on mobile devices).

      But the development tools were not free. Even if they were, you still required software and some development knowledge to create a “page”. And once you’d created it, that code couldn’t be examined by others — such as search engine indexing bots.

      However, Flash served a critical need for rich media when it wasn’t possible in HTML. Even today, Flash remains the most viable option for video on older browsers.

  • James Thomas

    There’s no point at all in fixing something that isn’t broken.

    HTML works just fine, does what it needs to do, and serves its purpose.

  • Steve Tee

    Great question well posed. My tuppence worth: IMO(im a veteran at this stage) Apple have put a kibosh on the momentum but more acutely the spirit built up around tech evolution through the Open Source movement from late 80s up to quite recently. The demise of Sun was a further death knell to technological evolution along a particular path, perhaps tech not well tuned to pure web development but certainly providing for solid stepping stones to where we find ourselves now. Once you monetise the evolution of infrastructure as fundamental as HTML, javascript and CSS etc you’re screwed. Noone will bother because the incumbents all work AND its too expensive to “mess around” with alternatives. So I would advocate a return to the spirit of the Open Source movement across all tech infrastructure including Linux, currently thriving in data centres but not in the consumer space. Encouraging kids to hack w/out asking for $$$ in return can only lead to the next jump. Once the spirit of evolution free(-in-part) from monetisation returns, we’ll then see labs around the world start to focus on replacing HTML, CSS, java script. Until then, enjoy the AppCentric world…

  • I agree with all the comments on HTTP. HTML was built to suit HTTP, and it does that as well as anything probably could.

    If we come up with a better transfer protocol, then it will inevitably come with a better format to be transferred too.

    I’m guessing that someday HTTP will be replaced with something that maintains state more like software. But that will be a day when bandwidth is no longer talked about.

  • Having worked as a web programmer since the previous century, I have always found it odd that web programming is the only paradigm that requires you to combine about 5 different syntaxes within one program (e.g. HTML, CSS, JavaScript, PHP/Python/Perl, SQL – not to mention config and settings files). Coming from a C++ background, I found this baffling. Between these languages there is also very little consistency between syntax for operators, functions, OO models. To be fair, some convergence is appearing. But even so, if you get into the nuts on bolts of any of these languages, you’ll find design flaws. Most were created for much simpler applications than they’ve been ultimately used for, and are full of kludges, add-ons and workarounds.

    I always wanted to to program with the same language on the client and the serve, and hence built sites using ASP with JScript for a long time, but then I got into PHP. Now we have new node.js and JS-only frameworks like Meteor, which is a step in the right direction. But my goal for a long time was to discover or invent a single language that would encompass everything that HTML, CSS, JavaScript, PHP and SQL can do, and overcome all of the design flaws in each of these. I recognised the need for a complete ground-up rebuild of the languages we use to build web apps, and with this in mind I started a design project which is currently known as “Datascript”.

    Datascript is basically Javascript++. It looks like, and is a lot like, Javascript, but enables you to do everything you can do in all 5 syntaxes mentioned, plus more. It’s functional but also OO. I’ve studied and borrowed good design features from Python, Perl, Ruby, Java, C#, and other languages, and added a few new innovations. It has consistent syntax for operators and everything else. You can perform data queries within the language. It’s designed to do everything the current web can do, and more. My design goal is that it must be able to do document markup, windowing, multimedia, games, VR, and windowing (it should be possible to make any desktop app with it). It must be a high level language that’s reasonably easy for newbies to get into, and it must be blazingly fast and efficient.

    But, it’s in design phase :) There’s no implementation, no prototype, not even a finished online spec for people to read and comment on, so it would be easy to say that I’m full of hot air – just another dreamer. But it’s a great idea and a fascinating project, and I hope to develop a version 0.1 this year or next year, depending on the usual time/money constraints.

    • JimK

      Keep us/me in the loop as you progress, please.

  • Tim

    While the current web languages have issues I can think of a much worse internet technology that has been around even longer – Email.

    Without email how much time and bandwidth would be saved. How much less fraud would be in the world with a proper, secure communication system? Google experimented with Wave, but it’ll never work unless it’s made free and totally opened up.

    Much like email has stubbornly hung on I predict the current web languages will be around for the long haul.

    Right now i gotta go – just got an email from a friend that they are stuck in Africa and i have to send them $5000 so they can get home.

  • towrz

    Not much has changed. I was thinking about this topic because I clicked a link to see a video and it took around 20-25 seconds for the page to load and then play the video I wanted to watch. I wonder when are we going to have the technology to load links instantly. What do we have to invent, replace, and improve?

Get the latest in Front-end, once a week, for free.