united-coders

TwitterFacebookGoogleRSS
  • Home
  • Authors
    • Christian Harms
    • Nico Heid
  • Newsletter
Home » Websites built for the future

Websites built for the future

Posted on January 21, 2011 by Matthias Reuter Posted in Uncategorized 1 Comment

If you had the chance to build a website from scratch. A website that is going to be launched in the late summer of this year. And an old version of that website already exists, which will be maintained but not developed further…

How would you build the frontend?

I have given that some thought in the last time. And here are the three most important conclusions I came to:

  1. Use HTML5 excessively
  2. Style with CSS3
  3. Drop IE support

While the first two might seem obvious, the third sounds like madness. How can I seriously even think of excluding like fifty percent of the users (less in Europe, more in the US)? It’s only logical (and I admit I’ll cut that down a little later on). But let me explain the first two points first.

Use HTML5 excessively

HTML5 offeres a broad variety of new structural elements. And the basis for a good website is semantic markup. footer, header, nav, article, time and so on are HTML5′s answers to a ton of divs that we used in old (and current) websites. But HTML5 is more, using the audio and video elements you can easily embed multimedia to your site. OK, video is still a mess if you don’t want to double encode your content, but that might change in the near future, since Google announced to drop support for H.264 last week.

There are a lot more techniques that help building a light-weight application, part of which are associated with HTML5, but are not part of the specification. Offline-applications, drag and drop, the File-API, local storage, geolocation and more.

Example? Build a blog

If that application was a blog, then the elements article, header, footer and so on come in quite naturally. Using these results in clearly structured, semantic markup. Maybe sometimes I would want to blog about a video I made. Or a song I wrote. I could include these without any plugins and therefore would not need a flash-detection library either. And that would work without Javascript. So if my big paranoid brother, who generally disables Javascript and any plugin in his browser, would want to read my blog, fine. He would be able to view all content. Even if some geeky friend of mine would want to read my blog using lynx, fine too. He would not be able to view the video, but he could download it easily.

Using the application as the blog author would be heavily supported by these techniques. Want to post a video? Just drag and drop it into the browser (using the DnD- and File-API). Write while onboard a train? You’ll notice no difference thanks to offline support and local storage.

Style with CSS3

This seems obvious as well. It means, if you want to have rounded corners, don’t use a bunch of images, use border-radius. If you want semi-transparent background, don’t use a png image, but use rgba colors. If you want animations, use transitions instead of bloaty Javascript code. If you want a shadowed box, don’t use images, use box-shadow. You want to use your corporate identity font for headings? Do not use images, use @font-face. And most of all, if you want your application to fit in a mobile browser, use media-queries.

So using CSS3 drastically can decrease the number of files you need and therefore the improve the performance of your application.

There is one drawback, though. CSS3 support is not complete in most browsers. Opera for example does not have gradients. Firefox does not support transitions. That’s partly because these specifications still are working drafts. But let’s be honest. Does it really hurt, if Opera users have a single background color instead of a gradient? If Firefox users don’t have an animated hover effect? Form follows function.

Drop IE support

If you have a look at what browsers support today, you can see that many, many features I would use already are supported in Opera, Chrome, Firefox and Safari. So if we dropped IE support, we could be using them today.

And if you then have a look at what will be, you can see that in mid/late 2011, when IE9 is released, most of the features are supported by all browsers. So I correct myself: Drop IE<9 support.

As I said it. If you build an application that will be launched in the second half of 2011, use HTML5, CSS3 and don't care about IEs.

But how long will it take users to adapt to IE9? My guess is, pretty quickly. Those using IE8 will switch quickly. Those using IE7 or - godforbid - IE6 will probably stick to it forever and eventually die out. You can still send them to the old version of your application (which is a prerequisite of IEs. If you don't have an old version you most likely cannot afford to drop IE support).

In the meantime build the next jQuery

What should be done in the meantime? How should we spend the time until IE9 is released? Build a new javascript library. Large part of current libraries are concerned with selecting dom elements, providing animations, offering functionality that already found its way into Ecmascript 5 (like JSON, Array extras and so on). Throw them away. Use querySelector/querySelectorAll instead of sizzle. Use CSS3 for animations. Ecmascript 5 is widely supported in many browsers today. Again, IE8 is far behind the others, but IE9 is the paragon for ES5 support. It even finally implements the Event model of W3C.

So spend the time building a library that adds the few missing functions. That works around the remaining browser bugs and inconsitencies. Build a library for the future.

A note at the end

When you use semantic markup, media queries and progressive enhancement for the advanced features (and do everything right), then you have a mobile web app almost for free. You don’t have to build an extra app for iPhone, Android… Now wouldn’t that be nice? Think of all the time (and money) you could save. So go ahead and start.

  • Bio
  • Latest Posts

Matthias Reuter

Latest posts by Matthias Reuter (see all)

  • On the phone with Mom – Throttle and Delay DOM-Events in Javascript - November 17, 2011
  • So your dropdowns won’t open in IE7? - November 11, 2011
  • User-agent sniffing is back - February 15, 2011
« 10 one-line solutions for project euler
no duplicates, please »

One thought on “Websites built for the future”

  1. Twitter Trackbacks for Websites built for the future | unit says:
    January 21, 2011 at 14:20

    [...] Websites built for the future | unitedcoderscom.appspot.com unitedcoderscom.appspot.com/matthias-reuter/websites-built-for-the-future – view page – cached If you had the chance to build a website from scratch. A website that is going to be launched in the late summer of this year. And an old version of that website already exists, which will be maintained but not developed [...]

Leave a comment Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Tags

android code jam code puzzle hackercup hosting java javascript linux permutations project euler python server

Recent Comments

  • http://underarmwhitening.Info on Number crunching with javascript – a tutorial
  • Nico Heid on A scalable, affordable WordPress hosting, lessons learned
  • Per Quested Aronsson on A scalable, affordable WordPress hosting, lessons learned
  • Christian Harms on A scalable, affordable WordPress hosting, lessons learned
  • Yoda Conditions | Pack 6 – Palo Alto on What are yoda conditions?

Recent Posts

  • All you need to know about Raspberry Pi colocation offers
  • A scalable, affordable WordPress hosting, lessons learned
  • google code jam 2013 – tic-tac-toe-Tomek solution
  • Google code jam 2013 – the lawnmower
  • code puzzles and permutations

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Copyright

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
© united-coders
  • If you had the chance to build a website from scratch. A website that is going to be launched in the late summer of this year. And an old version of that website already exists, which will be maintained but not developed further... How would you build the frontend? I have given that some thought in the last time. And here are the three most i