Building on the Web

Foundations

When building a house the foundations are fundamental to it’s structural integrity. Without good strong foundations the house is weak and liable to fall over at any moment.

Things on the web also have foundations in the form of HTML and URIs.  JavaScript can then be layered on top to improve the experience. It’s called progressive enhancement and people seem to be forgetting about it these days.

It’s pretty simple, build your HTML and CSS  first and then override the default behaviours with JavaScript.  This will ensure you are building on solid foundations.

When generating HTML on the server, you can easily re-use it with JavaScript. Its far better than generating the HTML in the browser (with JavaScript) and either ignoring Search engines or having to duplicate your logic on the server for SEO, accessibility and things like RSS feeds.

Here are some rather sweeping statements:

1. JavaScript should NEVER be used to process data in the browser.

2. JavaScript should rarely be used in the browser to generate html (sharing code with server-side JavaScript is acceptable).

I did warn you they were rather sweeping.

I’ve heard it said that if you want to provide an app/flash like experience you need to use JavaScript to render your pages: You need to build single page JavaScript apps.

history.pushState() tells us otherwise. You can read about it here.

Basically it makes it possible for what we now call single page web apps to exist across multiple pages while still providing nice page transitions (no page refresh).

history.pushState() – A Fallback

History.pushState is all well and good but it’s only available in WebKit and Firefox(4) at the moment.  Maybe that is why people are seeing hashbangs as an alternative solution. Personally I would rather fallback to a fragment identifier (#) only in situations where history.pushState is not available.

There would need to be a bit of JavaScript at the top of each page redirecting users to the appropriate fragment identifier in browsers that do not support pushState.

So when pushState is not available:

http://simonmcmanus.com/page.html

might redirect to :

http://simonmcmanus.com#page.html

which would then go and fetch the contents from

http://simonmcmanus.com/page.html

If a page is loaded with the fragment identifier in a browser that supports pushState the hash should be removed and pushState used.

Summary

When you require JavaScript for templating and data processing you are on a very slippery slope to writing JavaScript applications.

We have for a long time been able to obfuscate our data with technologies like Flash, I for one have avoided these technologies because I believe that when we publish data properly on the web it becomes more re-usable, findable, accessible and actually has far greater potential.

By all means use JavaScript, but please don’t rely on it.

Advertisements

2 thoughts on “Building on the Web

  1. Never is a very sweeping statement.

    I think the rule is OK if the following are true.

    1. You expect/want users to track state through bookmarks
    2. You wish to be indexed by SEO (this is not true of all applications – eg your bank account – an email app – your routers management page)
    3. You wish to have inbound links – really a subset of 1.
    4. You are NOT aggregating data from many sites. As a user I prefer cross domain calls being made from the browser (using cookies the “host” page can’t see) then having to do OAuth-esque authorization so that a server can render content to me.

    Never is far too sweeping. The browser can host a whole bunch of different types of sites and apps.

    PS the CSS on this page makes it impossible me for to see when I’m selecting words in the comment box.

  2. Yeah never is very sweeping.

    I realise there are some exceptions, I guess you could say they don’t apply to things that you don’t want to be used outside of the context in which you provide them.

    Even on things like bank accounts and email apps, if you process the data in the browser, you will have to duplicate that logic on the server to provide a no-js version of the site. I’d rather just see it done once on the server.

    The same things applies to point 4. If you aggregate content in the browser then you cannot easily provide other representations of that resource. An RSS feed for example.

    Sorry about the rubish CSS. The theme will change soon.

Comments are closed.