About the Author

Chris Shiflett

Hi, I’m Chris: web craftsman, community leader, husband, father, and partner at Fictive Kin.

JavaScript and URLs

I like the Web. It's simple, open, and accessible. It's robust. It's also inherently altruistic; every link gives, and links are what ties it all together.

People have always used the Web in their own way, and this is partly what makes it great, but sometimes people don't seem to appreciate the Web for what it is — and what it isn't. Some people just don't get it.

For years, one of the telltale signs of not getting it has been using Flash as a substitute for the Web. By delivering Flash over HTTP and extending browsers to run it, it's easy to overlook the fact that Flash is a competitor to the Web, not a proprietary part of it. (Being a competitor isn't a bad thing, but it is what it is.) Flash sites are dying, partly thanks to Apple, but a new bad practice is emerging.

Except it's not new. It's as if a bunch of people got together and decided that the problem with Flash sites is the technology, not the use of it. Everything I used to hate about Flash is back, this time in the form of JavaScript. Like Flash sites, there is a new breed of web apps that don't feel quite right. Maybe it's because they scroll like a supertanker. Maybe it's because the back button doesn't work right. Maybe it's because the browser tells you it's done, but you don't see any content. (I'm looking at you, Twitter.)

I think all of these things are just symptoms. Some solutions already exist. Remy Sharp teaches us how to enable the back button. Ben Cherry gives us a saner HTML5 history solution. Mozilla explains how to manipulate the browser history. Google provides a solution for making your Ajax apps crawlable.

I think Simon Willison comes closest to describing the fundamental problem:

The Web for me is still URLs and HTML. I don't want a Web that can only be understood by running a JavaScript interpreter against it.

Many others have weighed in on this conversation. Here are a few posts that have caught my eye:

Thoughts on the Hashbang
Ben Cherry makes the case for web apps versus web sites, arguing that the former deserves some leniency, because URLs are a legacy of web sites. He also makes the case for web apps being faster, more seamless, and much better. Using his distinction between a web app and a web site, I have a hard time agreeing with web apps being better. I do agree with his assertion that the debate should focus on the merits of these types of web apps and not just the use of the hashbang in URLs. (It's still a relevant talking point, but it shouldn't be the focus.)
Breaking the Web with Hashbangs
Mike Davies points out many problems of this new breed of web apps, with a focus on fragility, using Lifehacker's outage as a timely example. The caching of web content is a bit more nuanced than he suggests, but I agree with the thrust of his argument.
Going Postel
Jeremy Keith focuses on the Web's history of adhering to Postel's Law, which says to be conservative in what you give and liberal in what you accept. This is one of the reasons the Web is so robust, and it's one of the fundamental principles being abandoned in this new breed of web apps.
Broken Links
Tim Bray breaks down the technical details of hashbang URLs for anyone who would like to know what all the fuss is about. He also asks a good question: "What is the next great Web app that nobody's built yet that depends on the simple link-identifies-a-resource paradigm, but that now we won't be seeing?"
Hash, Bang, Wallop
Ben Ward gave us the excellent rule of thumb that if site content doesn't load through curl, it's broken, and this post offers a much more complete viewpoint. I like his description of hashbang URLs as a client-side routing pattern. (That's exactly what they are.) Because of his careful dissection of some of the arguments being made, this is probably my favorite post on the topic. If you read nothing else, read this.

What do you think? Is this just an awkward phase during a period of necessary evolution for the Web? If so, it sure is a bumpy ride.

About this post

JavaScript and URLs was posted on Mon, 28 Feb 2011. If you liked it, follow me on Twitter or share:


1.Sean Coates said:

I think the fundamental problems are:

1) There's no way to fully implement both a strong, rich client-side solution (such as pagination without page reloads) *and* simultaneously avoid things like breaking the back button, without manipulating URLs.

2) The tools to help with these (such as jQuery's hashchange support), don't integrate well with server-side technologies from which they should augment. This is compounded by the vast majority of users' browsers being able to process JS, but other tools cannot (such as Google's workaround).

We've run into both of these problems with Gimme Bar, and have chosen to focus on making the general case (like it or not, that's JavaScript right now) work first, and we'll drop back to non-JS rendering when we catch our breath. A great example of my second point above is that we're switching from jQuery templates to Mustache templates because the latter can be rendered in not-just-JavaScript (JS and PHP in our case).

Anyway... I don't have any real solutions. I like this conversation, though. I'm not as quick to condemn "#!" URLs as others have been, but I would prefer a much more elegant solution.


Mon, 28 Feb 2011 at 16:21:29 GMT Link

2.Grigory V. said:

I think that HTML5 history API rocks. Open any repo on GitHub. Browse through the tree (with AJAX). Look at the URL: no hashbang. Press ⌘R. You're in the same directory/file!

P.S. "if site content doesn't load through curl, it's broken" — right. The keyword here is "site". The one that has content. A blog, a news site, a wiki. This doesn't apply for web apps (like Gmail and Basecamp).

Mon, 28 Feb 2011 at 16:26:05 GMT Link

3.Jordi Boggiano said:

This is kind of what I hinted at in my post on the topic from last year. People see Flash as this spawn of the devil, and then go and start writing flashy-blinky sites that are oh-so-cool because made of "HTML5".

Sad sad world.

Eventually, the technical issues (back button and friends) will go away I think, with the help of browser vendors. But that won't fix some people's contestable taste for flashy colors and swooshing sounds.

Mon, 28 Feb 2011 at 16:41:53 GMT Link

4.Chris Shiflett said:

Thanks for the comment, Sean. Like you, I don't have any real solutions, but I do see the problem as being more fundamental than the characteristics people are focusing on like hashbang URLs and back button support. I'm also keen to promote an ongoing discussion about this, because I think it's important.

Mon, 28 Feb 2011 at 16:46:39 GMT Link

5.Martin de Keijzer said:

I think this is just another part of the web evolution. Let's go back to the time we used horses to move from one place to another.

When the first cars arrived it was also nothing more but a novilty to do exactly the same job. They were untrustworthy and even starting them was more of a hassle than jumping on your horse. Also safety was a big issue compared to cars nowadays.

What I am trying to say is that great things can come of this technology we just need to improve and adapt. Flash was nearly impossible to crawl in a good way because it was mostly binary data which controls the flow of the pages. JavaScript tackles this problem by being readable and interpretable to anyone. HTML5 tackles the video/audio which we used to love Flash for.

Back in the beginning the web was just text and links, we've come a long way already. And we just keep moving on, to keep our customers attracted and make our options even larger to create what we have in our minds.

Wether these technologies are adopted in a right way is something we as developers will always be tested with.

Tue, 01 Mar 2011 at 07:59:29 GMT Link

6.Jared Verdi said:

Take Google Maps as another example of a rich client-side experience, but one that doesn't manipulate the URL. Drag the map around as you like, zoom in with a double click; everything starts on the client-side.

I think we can all agree that the user-experience far surpasses that of early Mapquest, when clicking a North/South/West/East link would tell the server to send back an image of the next 10 mile square of the map.

And Google does do some work to preserve the back button functionality. Requesting directions or searching for a location will add an entry to your history. If you refresh the page at any point though, that maps.google.com URL will take you right back to the beginning.

There are lots of examples like this, some of which you mentioned, where some or all of the user's browsing expectations aren't met. We can often do better, but the browser developers and standards bodies are in the best position to facilitate the continued (and bumpy) transition. Any solution we can come up with as developers will be stretching the existing technology stack beyond its intent, and likely no better a hack than the hashbang.

Tue, 01 Mar 2011 at 18:15:14 GMT Link

7.Daniel Serodio said:

Jared, IIRC this change to Google Maps is recent. Previously, the URL (fragment identifier) was updated when you scrolled, dragged, etc.

Tue, 01 Mar 2011 at 21:40:24 GMT Link

8.Roman said:

I agree with your sentiment, Chris.

IMO, there are some pretty simple solutions to the problem that people are solving with AJAX, but they would have to be implemented in the browsers and servers.

Part of the reason people use so much AJAX is to prevent re-loading of the content that doesn't change. Unless I'm missing something, the same can be achieved with partial caching:


Another problem is aesthetics. People don't want pages to flicker if there is a delay before you receive the new page. People also don't want the page to loose track of the state of the scroll-bar. Both of them should also be solvable without the use of JavaScript.

Tue, 01 Mar 2011 at 22:17:45 GMT Link

9.Edmar said:

About making Ajax apps crawlable, if one is developing a public website currently, I agree with Google.

As for the future, I'll bet that if Google doesn't implement a Javascript-aware bot, someone will. It just seems wasteful to implement "HTML snapshots", when IMHO all it saves is bot cpu cycles.

Tue, 01 Mar 2011 at 23:32:12 GMT Link

10.Michelangelo van Dam said:

Have you surfed the Internet lately with JavaScript disabled? It's not pretty in many cases if you get to see any content.

I recently reviewed a book about building a cms with PHP and JavaScript where I came down hard on the author for building logic into JavaScript and less logic in PHP.

JavaScript should be the final layer to enrich a perfect working app, making it more user friendly, but still usable for screen readers, content crawlers and other non-browser like tools to access content.

I see more people being convinced of the fact that if you browse the web, you have JavaScript. And it's hard to convince them it's not always the case.

Wed, 02 Mar 2011 at 00:23:13 GMT Link

11.Drew Wilson said:

I personally develop with CodeIgnitor. The URLs for the controller I find are the best way to implement navigation. When doing any sort of XHR request, however, the page will return just the JSON for that URL. If I were to add a hash after the root, and then the URL, I get the template for that JSON in mustache format.

All in all, with JS off the page works great, if not normal, using regular http links. But if you have JS on, you get the benefit of no refreshes and Hash links updating the page. The history API just increases that effort more and localStorage can be used to save the mustache templates for even faster rendering.

Progressive development is the only solution.

Wed, 02 Mar 2011 at 02:41:35 GMT Link

12.Anonymous said:

There are two problems with flash: it's proprietary and it often produces things that integrate badly with the web. HTML5 and JavaScript solve 1.5 of these problems: they aren't proprietary, and they at least often produce results that integrate well with the web. But even if HTML5 didn't address the second problem at all, it would still be a huge win simply by not being proprietary.

Wed, 02 Mar 2011 at 08:03:06 GMT Link

13.Hugo Rodger-Brown said:

I totally agree (I wrote something very similar myself yesterday - On AJAX, the hashbang debacle and why the web is just fine as it is) - and I'm afraid I don't totally buy Ben Cherry's reasoning. Web apps are fantastic (when done right), but that doesn't mean corrupting the fundamental principals of HTML/HTTP and building a complete client-side app in JavaScript.

I think this approach does work well in single use scenarios, where users fire up an app, use it for a single purpose and then close it down - which makes it perfect for mobile / tablet apps implemented as HTML (rather than native). The new Basecamp & Fogbugz mobile sites are good examples of this - they are almost indistinguishable from native apps on an iPad.

Wed, 02 Mar 2011 at 09:12:27 GMT Link

14.Demis Bellot said:

I love how all this semantic HTML police are putting the hate on JavaScript. Comparing it to Flash is a gross misrepresentation. If flash was a superior technology that easily allowed you to create a superior user experience that behaved like browser applications ought to it wouldn't be dying away. It can't and doesn't, but JavaScript and Skilled js devs can.

Why should we be forced NOT to use a technology that provides superior response and productivity than what was traditionally possible? Forcing us to live in a world with server round trips for everything just so we can say we perfectly fit within *an artificial restriction we created ourselves 20 years ago* - long before any consideration was given to the web was being used for more than viewing linked documents?

Note: HTML5 / EcmaScript 5 / WebSockets are also standards being ratified today, which will allow for the creation of a new kinds of user experiences. Why are these standards less acceptable than HTTP/HTML developed 20years. I agree all applications shouldn't break the browser model users are used to, but this is an application concern that can still be maintained with JavaScript today.

There still exists the 'content web' suitable for browsing and navigating content! For the Wikepedia and the plethora of blogs carrying content that remains as business as usual and has no need to change.

There are other 'apps' that provide enhanced functionality like gmail, google maps / docs / calendar, Zoho Writer, groove shark, etc. Delivering a far superior experience to anyone with an internet connection and a modern browser, better than any set of hyper-linked documents and server round trips ever can.

Wed, 02 Mar 2011 at 15:51:33 GMT Link

15.David Turner said:

I personally don't mind JavaScript being used to load content into certain areas, so long as it isn't the only way that content can be loaded.

In my own (admittedly) limited experience creating webapps I do use jQuery to handle link clicks, loading in bits of content dynamically based on user interactions. But I always make sure that, if JavaScript is disabled, that things work fine for the user. That's something that a lot of sites don't seem to be doing these days, meaning no JavaScript = no Site, which should never be the case.

Wed, 02 Mar 2011 at 15:55:50 GMT Link

16.Jason Brown said:

I couldn't agree with you more.. its only a matter of time before the dreaded site intro's make a comeback.

Wed, 02 Mar 2011 at 17:02:20 GMT Link

17.Tom said:

I don't think you could build an efficient/timely crawler for twitter (or any fast realtime app) using curl and cron, maybe grandpa would.

You can always curl twitter statuses as json.

The new breed of apps shine where flash didnt. Flash app developers loved to reinvent UI elements, speed was usually not prio 1.

A web site's shouldnt be measured solely by its semantic web conformity and ability to respect the browsing history.

Google docs and maps dont really need back buttons, because they're not modelled after wikipedia or books.

Also, didnt twitter move to a mustache based client side rendering, mainly because of speed and server cpu cost?

Kudos to them for solving it elegantly, sans the url.

Gmail is a good example of a web app that works because of javascript. I wouldnt use it with js turned off or if google decided not to use js.

As to the back button, yea its a problem, but not a huge one, imo.

Wed, 02 Mar 2011 at 19:05:46 GMT Link

18.Tom Southall said:

Thank you Demis Bellot!

A lone voice of reason amidst a whole load of backward-looking blather.

Wed, 02 Mar 2011 at 19:07:26 GMT Link

19.jmarranz said:

Added for the discussion:

The Single Page Interface Manifesto


Wed, 02 Mar 2011 at 20:19:12 GMT Link

20.Chris Shiflett said:

Thanks for the discussion, everyone.

Jared, I'm glad you mention Google Maps. We're working on an app called Mapalong, a web app by pretty much anyone's definition, and we're guilty of everything I mention in this post.

We're not being hypocritical, though; we're working pretty hard to come up with some better solutions. I may blog again if we can make any progress and share what we did and why. In the meantime, I'm reading, listening, and thinking.

Michelangelo, I think you make a good point, but I think there's a bigger problem here than just the erroneous assumption that everyone has JavaScript enabled. I always have JavaScript enabled, but I still feel like the Web is slowly getting worse, and I'm trying to just consider things from a user's perspective and not be some sort of puritanical developer or cranky old man. :-)

Demis, it would really help if you'd soften your tone. Ignoring that, I think you're focusing too much on the technologies (Flash and JavaScript) instead of how they're used. I agree with the spirit of your argument, just not exactly how you say it. I love that web technologies can be used to do so many cool things. I use Ajax myself. (Even the comment preview I'll use to preview this comment uses Ajax.) I am not at all advocating for full page loads at every turn or subjecting ourselves to arbitrary restrictions. However, just from a user's perspective, there is a lot to be concerned about with the way things are going. It is quite possibly just an awkward phase, but I'm not yet convinced that's all it is.

For anyone who's interested, there are ongoing discussions about this post on Reddit and Hacker News.

Wed, 02 Mar 2011 at 21:01:07 GMT Link

21.mike lawrence said:

For me, the web is simply a delivery mechanism. It's not an operating system. Sure there are some conventions, based on legacy use cases.

The fact that there are many browsers times many versions of browsers in the wild, means you would have to test your app on all of these to be sure it works. Enter a VM like flash, which provides a consistent API that renders the same on all versions of all browsers. Problem solved.

One can be incredibly productive, write once, run anywhere.

Flash/ActionScript3 is statically typed, so one can easily tell if a change breaks anything (try that with HTML/java/CSS).

Ok, so iphone doesn't support it... hopefully that will change soon.

Wed, 02 Mar 2011 at 21:41:11 GMT Link

22.Denis Zgonjanin said:

Dude, you have it all wrong.

It's the web that's broken for what we need it. And that forces us to write apps in a roundabout way.

HTTP was never meant to support rich client applications. It was meant for static, document type content. And that's not what most applications are about these days. What every web developer is doing is finding clever ways to work with a very flawed system. The tragedy is that HTTP has so far been the only thing we've had.

You should instead bitch about how the foundations of the web are broken. Not about how we're not doing our jobs 'right'

Wed, 02 Mar 2011 at 23:53:06 GMT Link

23.artsrc said:

We need standard ways to publish more content types.

Being able to take text content intended for a human audience and use it for something else is what makes the web we know today possible. The existence of Google depends on this ability.

JavaScript is not a bad thing. Making content in-accessible is bad. Some content types, like maps, are not the text web. So we need a standard way to publish maps.

Thu, 03 Mar 2011 at 02:09:25 GMT Link

24.Nathan said:

There is another side to this, which many people seem to miss, I've discussed this and clarified as much as I can. Hopefully the info is of use to some other people too.

best, nathan

Thu, 03 Mar 2011 at 09:54:09 GMT Link

25.jmarranz said:

+1 Nathan

I don't agree with your AJAX intensive REST approach, there are more options, Single Page Interface can be done server-centric and most of JS generated on the fly in server, I think "creating applications entirely in js" is not good for many people.

Thu, 03 Mar 2011 at 10:00:10 GMT Link

26.raul said:

Another example of using html5's history api to address the problem. (no pun intended!): http://diveintohtml5.org/history.html

Thu, 03 Mar 2011 at 21:29:33 GMT Link

27.Chris Shiflett said:

Thanks, Raul. I was just looking at that earlier, including the example. Seems very promising, at least for modern browsers.

Thu, 03 Mar 2011 at 21:33:47 GMT Link

28.Roman said:

Nathan, calling a website that doesn't work without JavaScript "web application" doesn't change much for the end users.

To me, the real difference between web applications and web sites is in what they are doing, not in which technologies they use. E.g. if you display a bunch of mostly-static web-pages via SilverLight, it's still a website (one that lacks many basic functions at that).

Sun, 06 Mar 2011 at 00:16:25 GMT Link

29.Benjamin Lupton said:

Totally agree that the hashbang is big glorified mess and popular for all the wrong reasons. Mostly it brakes best practices and destroys the chance for graceful upgradation and degradation.

What is amazing is that there are other solutions that provide best practices like graceful upgradation and degradation with less effort. This article goes into the issues and the alternatives:


Mon, 07 Mar 2011 at 19:03:51 GMT Link

30.Kevin Remisoski said:

I think you are absolutely wrong about Flash not being a part of the web. Your complaints about browser history and back buttons are addressed in Flash, and Flash is another medium for media on the web.

I'm not going to say which is better, but it's clear to me that Flash is not a competitor to the web as much as another enhancement.

Either way, HTML, Flash, and hybrid sites are all good solutions depending on what you're using them for, but you can't blame Flash for the ignorance of most developers who don't know how to deep link or manage dynamic content in Flash.

The problem is most people don't know how to do SEO, either, nor do they make good uses of the noscript elements of HTML.

Your statement that Apple is killing Flash is complete farse though. The only thing Apple is killing is Apple and that includes their product line. Case in point: Iphone vs Android. Enough said.

Wed, 16 Mar 2011 at 06:15:41 GMT Link

31.The Daily Captcha said:

I am not sure why you think Flash is a competitor to the web, and it might have helped to explain yourself on that point. Flash is an integral part of the web, and will most likely stay that way for years to come. The many benefits to delivering your message via Flash greatly outweigh the risks of using the technology.

I think Mike Lawrence has made a great case for the use of the technology, and many of the reason web developers "hate" Flash have everything to do with inexperienced developers creating web sites and intros, because their clients asked for them. Point being... there was a huge demand for the Flashy dancing bananas, and everyone with a computer tried their hand at Flash and ActionScript. Yeah, it created some fugly web experiences, but we learn from our mistakes and move on. Flash was not the mistake... the implementation was the mistake. Much like the JS Flashy apps mentioned above.

It would help if there were more articles written and read by seasoned web developers and designers, instead of the hundreds that are produced by web editors just repeating the flavor of the month mantra just to get some site impressions.

We should be "technology agnostic" as someone somewhere recently posted, and learn when and where to use a specific technology. Sometimes Flash is not the answer... sometimes HTML/CSS/JS works better, it just all depends.

A great carpenter has more than one saw in the shop, and knows which tool it best for the job.

Wed, 23 Mar 2011 at 18:22:49 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.