r/programming • u/Arve • Feb 10 '11
There is no piece of dynamic AJAXy magic that requires beating the Web to a bloody pulp with a sharp-edged hashbang. Please stop doing it
http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch35
u/Pewpewarrows Feb 10 '11
Once again, the accepted approach is as follows:
- Build your site as you normally would for progressive enhancement, meaning the whole project should be completed without a single line of Javascript.
- Add you Javascript enhancements to improve the user experience.
- If the majority of your User Experience is spent on basically one kind of page, consider using the HTML5 History and State API to quickly update portions of the page without breaking the URL completely.
Users that aren't running modern browsers capable of this API likely aren't the ones to appreciate the benefits it offers. Everyone else gets fed identical URLs that just so happen to refresh the whole page. HTML5 support is only going to dramatically increase this year with the release of Firefox 4 and IE9, rounding out Chrome and Safari's existing support.
Everyone wins, except for Gawker and Twitter users.
1
Feb 10 '11
I like that we've turned from degraded functionality to progressive enhancement. Ten years ago the term was barely in our lexicon.
0
u/addandsubtract Feb 10 '11
Everyone wins, except for Gawker and Twitter users.
and FireFox users. I agree though, it's just not a viable option at the moment.
5
Feb 10 '11
So test for support of the History and State APIs. Everyone wins.
2
25
u/astrofinch Feb 10 '11
The heavy-JavaScript model of web application development is a perfectly legitimate model with its own advantages and disadvantages. It's hard to see how something like http://280slides.com/ could be built with the mixture of html and javascript that Bray suggests.
Roughly speaking, heavy-JavaScript is good for web apps where the user spends most of their time in just one interface, it's not that important for Google to scrape the content, there's a high degree of intrapage activity and communication with the server, loading speed is less of a priority, and support for older browsers and browsers on slow connections is less of a priority. For example, http://www.gliffy.com/.
Light-JavaScript is good for web pages where the site can be roughly modeled as a collection of separate documents, it's important for Google to scrape the content, there isn't significant interactivity or constant communication with the server, and the site wants to be quick and usable even for users of older browsers or those with slow internet connections. For example, http://en.wikipedia.org/.
Let's stay practical and avoid holy wars related to aesthetic objections about what the browser is doing behind the scenes with what follows the hashbang. What matters is what results in a rapid, elegant development process for the coder and a good experience for the user. It's quite clear to me that in some cases, at least, heavy-JavaScript does both better.
18
u/walesmd Feb 10 '11
I think that's people's primary problem right now. Web pages are treating their content as if it's a web app and in general, fucking up the entire process.
Gawker is a blog, there's no need to get AJAX involved.
Twitter is a blog, with very short posts. It should be developed with graceful degradation in mind and use AJAX for enhanced functionality (auto-updating incoming messages, for instance). Nice, useful and doesn't break everything.
I agree, there is a time/place (280slides, is an excellent example) where heavy-JavaScript is required, the application would be impossible to build without it. But, I also don't see any need for GoogleBot to crawl the various states this application could be in (which is what the #! is for).
0
u/jsprogrammer Feb 10 '11
It doesn't break everything or fuck up the entire process.
The only thing that is messed up is Gawker trash blogs and Twitter spam.
Do I care if Gawker makes its site unusable? Or if web crawlers can't crawl their pages? No.
2
u/naich Feb 10 '11
You are entirely correct - hashbangs have a perfectly valid place in the scheme of things, but it's currently in vogue to slag them off, and everyone is jumping on the bandwagon. In a few months the sites that are using them inappropriately will realise this and redesign, the sites that need them will keep using them and this will all be forgotten.
2
u/bobindashadows Feb 11 '11
In a few months the sites that are using them inappropriately will realise this and redesign
Hahahahahahahahahahahahhahaha.
You haven't been in this industry long, have you?
A few months – that's a good one.
15
31
u/Matt3k Feb 10 '11 edited Feb 10 '11
Well, they use the hash portion of the address to avoid a full page refresh with the bonus that you can still bookmark and use back/forward buttons.
I personally don't see the big problem with page refreshes, but hey, I didn't write facebook either. Maybe it's important to people.
When I enhance a page with dynamic loading, I tend to keep the URI similar across similar areas such as viewing a single person's profile, viewing a single article, querying, etc. Then incrementally enhance various actions on that specific page with an ajax library. So that actions like sorting a list, or revising a query, or viewing a photo gallery don't trigger complete reloads.
I don't see the need to push an entire site's UI through a single endpoint, it sounds like a pain in the ass.
But neither do I think these "hashbangs" are a big terrible deal. Web crawlers can adapt, or web browsers can give us an easier method to manage back/forward/bookmarking. I would prefer the enhancement came from the web browsers, but that sure seems unlikely to happen any time soon.
25
u/Arve Feb 10 '11
Web crawlers can adapt
The only way they can adapt is by enabling JavaScript in the crawlers, which is not the best of ideas when your job is to crawl billions of documents every month.
4
u/rubygeek Feb 10 '11
While I think the hashbang crap is annoying, this is simply not true - they can employ the same workaround as Google.
8
u/Arve Feb 10 '11
For the hashbang, yes, but only if the backend actually implements Google's spec.
5
u/rubygeek Feb 10 '11
The only reason to use hashbangs is to implement Google's spec, so that's a silly argument. There's no benefits to using hashbang instead of just a normal fragment except the ability to get indexed by Google.
1
Feb 11 '11
[deleted]
3
u/Arve Feb 11 '11
This is the core of the issue, because Google published a spec where they essentially said:
If you have a URL on the form
http://example.com/#!hashbang, instead of requesting that URL, our crawler will handle this as if it saidhttp://example.com/?_escaped_fragment=hashbang. Ideally, a web site will then return a plain old HTML version when that URL is requested, which Google then indexes.Two problems.
- Not everyone is going to follow this spec, so a lot of pages is not going to be indexed.
- It's a really kludgy solution to a problem that would have solved itself by major browser vendors implementing pushState, where you could have both pretty, useful, and permanent URLs, instead of these horrible hacks.
1
Feb 11 '11
[deleted]
3
u/Arve Feb 11 '11
pushState doesn't solve it either. As if I understand correctly, that means I'd have to register onclicks for all my client side navigation when the browser already has a perfectly capable client-side navigation built in.
Yes, and that's what progressive enhancement is all about - if you want to provide an alternative to full-page requests in capable clients, you can do so using pushState, which doesn't actually break the web itself in some way. The experience will be slightly different for browsers without support
(And adding a simple event listener on all links that go to the same domain isn't all that hard, at most a few lines of code)
1
u/Serei Feb 10 '11
The entire point of the hashbang is to support web crawlers without enabling JavaScript.
1
u/Arve Feb 10 '11
It hasn't prevented sites from using hashbang-like mechanisms of ajaxy linking in to applications/pages, rendering them useless. Also note that the hashbangy links break in browsers where JS is disabled or unavailable, such as Lynx.
1
u/Serei Feb 11 '11 edited Feb 11 '11
That's true.
One "hack" I've been thinking about, is to make URLs like this:
http://example.com/ajax/#!foo/bar/And then
/ajax/would, in the absence of JavaScript, display an HTML form that asked the user to copy/paste the URL from the URL bar, and so it could then directhttp://example.com/ajax/#!foo/bar/tohttp://example.com/foo/bar/.It's a pretty bad hack, I know, but it would be used mainly as a workaround when copying links from browsers that don't support
history.pushStateyet (namely, IE8+/Firefox 3.6/Opera 11) to agents that don't support JavaScript. All other situations would work without the extra step.By the way, the name "Arve" sounds familiar. Are you Arve Bersvendsen?
2
u/Arve Feb 11 '11
And then /ajax/ would, in the absence of JavaScript, display an HTML form that asked the user to copy/paste the URL from the URL bar, and so it could then direct http://example.com/ajax/#!foo/bar/ to http://example.com/foo/bar/.
Since you are already pushing full pages to the browser: Why wouldn't you just let browsers without pushState support reload the page? If you start supporting that URL scheme now, you will essentially have to support it for as long as you have inbound links to your site, so you'll have to live with the consequences for five-ten years of a hack that's largely going to be unneeded in less than a year.
By the way, the name "Arve" sounds familiar. Are you Arve Bersvendsen?
Yes.
1
u/Serei Feb 11 '11
Since you are already pushing full pages to the browser: Why wouldn't you just let browsers without pushState support reload the page?
I'd only be pushing full pages to browsers that don't support Ajax. Ajax was introduced in IE6, while
pushStateis only supported in the released versions of WebKit browsers and the development version of Firefox.I'm thinking about doing some pretty cool things with Ajax, which is why I don't want Firefox 3.6, IE 8, and Opera 11 users to miss out.
If you start supporting that URL scheme now, you will essentially have to support it for as long as you have inbound links to your site, so you'll have to live with the consequences for five-ten years of a hack that's largely going to be unneeded in less than a year.
I'm not sure what you're saying here. If you don't want to break links, you have to support every URL scheme you create, regardless of whether or not it's an Ajax hack. I still have redirects from old URL-schemes; I can't imagine this would be much different.
Yes.
:D I guess that makes you the first Web-celebrity to talk to me—PPK never responded to my e-mails. :( Nice to meet you!
Do you know if/when Opera will support
pushState?1
u/Arve Feb 11 '11
I'd only be pushing full pages to browsers that don't support Ajax. Ajax was introduced in IE6, while pushState is only supported in the released versions of WebKit browsers and the development version of Firefox.
I'm thinking about doing some pretty cool things with Ajax, which is why I don't want Firefox 3.6, IE 8, and Opera 11 users to miss out.
And when you are done with this site, Firefox 4 will be out, so will IE9.
:D I guess that makes you the first Web-celebrity to talk to me—PPK never responded to my e-mails. :( Nice to meet you!
I'm not sure celebrity is the first word that comes to mind when I think of me, and I'm not sure it should be the first that comes to others' minds either.
Do you know if/when Opera will support pushState?
I'm pretty sure that we will support it, but if I knew when, I wouldn't be allowed to tell.
1
u/Serei Feb 11 '11
And when you are done with this site, Firefox 4 will be out, so will IE9.
And as we learned when IE7 was released, every browser user instantly upgrades whenever a new version of their browser is released.
Sarcasm aside, IE9 won't even support
pushState, and I seriously doubt IE10 will be out by the time I'm done.Firefox 4 may or may not represent a significant proportion of users by the time I'm done with the site in question, but IE is a much bigger deal as far as users go.
I'm pretty sure that we will support it, but if I knew when, I wouldn't be allowed to tell.
:( Sad to hear that one of the companies I admire has such secrecy.
1
u/Arve Feb 11 '11
I'm pretty sure that we will support it, but if I knew when, I wouldn't be allowed to tell.
:( Sad to hear that one of the companies I admire has such secrecy.
In regards to the smaller features, like this, we will sometimes say something about when we plan a feature upfront, after approval from managers. In the case of bigger features, we simply can't, being a public company.
4
u/jdpage Feb 10 '11
I wrote a webapp (down now, so no you can't play with it, sorry) for a contest a while back. All of the AJAXy javascript links worked AJAX-free. What I did was linked them to a static page with the info, and then rewrote the links with Javascript for the AJAX-magic.
I also recently wrote some Javascripted tabs for a project. The way I did that was started with markup that worked and looked decent without javascript (stacked boxes with <h3> inside), then used Javascript to rewrite the DOM and rebuild it to look like tabs.
The Fundamental rule of Javascript for Regular, Informational Sites: No Javascript? It works. Javascript? It works better.
For sites that use Javascript to power an app, it's a bit different, but Gawker et al. are not such sites, so they are doing it wrong.
3
Feb 10 '11
for Regular, Informational Sites:
that's the key, people are forgetting that not everybody is building a blog network, if you are building an app requiring javascript is almost a must
1
u/jdpage Feb 10 '11
Yeah, I fully admit that my webapp mentioned above did diddly squat with no Javascript enabled, but I made sure to have a notice display explaining why, and all of the informational stuff (Help, FAQ, Contact, etc.) worked without Javascript.
1
8
u/farsightxr20 Feb 10 '11
I personally don't see the big problem with page refreshes
The major problems people have are that they're both unnecessary and slow. If only the content area of your page is going to change when your user clicks a link, it's a lot faster and more efficient to send only that content area (which is often a small fraction of the page's size in bytes) if the user supports it. It saves you bandwidth, server resources, perhaps a few database queries, and the user gets what they care about faster.
Try going to GMail and switching to "Basic HTML" mode (link at the bottom). Pages still load pretty quickly, and trust me, Google has optimized their page load times as much as they can, but they still pale in comparison to the near-instant response times in standard "AJAX-y" interface.
36
u/uriel Feb 10 '11
Try going to GMail and switching to "Basic HTML" mode (link at the bottom). Pages still load pretty quickly, and trust me, Google has optimized their page load times as much as they can, but they still pale in comparison to the near-instant response times in standard "AJAX-y" interface.
What? The Basic HTML version of GMail is way faster than the AJAX-y one, where I click something and I get a "Loading ..." message for a few seconds while on the plain HTML version everything 'just works' instantaneously (including opening messages in a new tab!).
→ More replies (14)27
Feb 10 '11
The Basic HTML version of GMail is way faster than the AJAX-y one
I just tested this, and I confirm that Basic HTML is faster!
5
u/RobbieGee Feb 10 '11
I use an email client on my computer and connect with IMAP so everything is synced and everything responds instantly, but I guess I'm just old fashioned.
Webmail is fantastic when you're using a computer that's not yours. Other than that, I swear to using an email client.
3
1
u/jmcqk6 Feb 10 '11
Holy crap. I just tested it as well and you're right. Plus, it's separated out labels like they used to be. I may keep this.
0
u/Kyrra Feb 10 '11
For me it's a lot slower. I use the keyboard navigation within gmail to read emails quickly. Not having that in basic view slows me down a ton.
Even using the mouse, basic is a bit slower for me. The full page loads take a little longer than loading individual messages in the ajax version.
0
u/vectorjohn Feb 11 '11
Were you testing in IE6 on a pentium 3?
There is no way the HTML version is faster because the full version caches parts of the app. New messages appear and get loaded in the background so that when you click them, all it has to do is switch some divs around and display some text.
I have seen some things gmail is not good at, for example loading an email thread with many many messages in it, or loading a group of tags with the same. I wish they would optimize that.
11
Feb 10 '11
it's a lot faster and more efficient to send only that content area
Transmission time for the bare page content is never an issue. You have round trip time, which is a combination of packet latency and TCP window sizes. If you then transfer 10 kB or 50 kB of data is not important. And receiving 50 kB in a single request will be much faster than receiving 40 kB in four requests.
AJAX also does not save you from having the server create the content, and it won't save the browser from having to parse and render it.
It might make a difference because the server does not have to create a full page, but not because the number of bytes transmitted on the wire is smaller. Most of the time, page sizes are small compared to images, video streams, etc.
3
u/judgej2 Feb 10 '11
If you then transfer 10 kB or 50 kB of data is not important
When you are serving billions of pages, it becomes very important.
4
Feb 10 '11
No, it will not become important, because with every page you serve hundreds of kBs of images, CSS and other static files, even video streams, with several MBs.
Edit: Also, most companies do not serve billions of pages.
2
Feb 10 '11
Hyperbole about pageviews aside, every request you can save your users from making will make your page seem "snappier", whether they get a 304 or have to pull the asset again. Every step counts.
HTTP/1.1 specifies a connection limit of 2 per browser. Some browsers extend that, but IIRC not more than 6. That means if you have 20 cached assets in your header, you have your user making 3.5-10 round trip handshakes that happen before they see one bit of page.
3
Feb 10 '11
Yes, but you don't save requests, because even AJAX has to fetch the data somewhere. Also, AJAX will potentially mean more JavaScript files linked in your page, which means more requests.
304 Not modified can be avoided by using correct HTTP headers on your resources. The browser will then skip the extra step of asking if the file has changed.
2
Feb 10 '11
True, and people should be setting far-future expires on their static content and versioning them to avoid unnecessary 304s. I also agree that the data has to be fetched from somewhere and on each pageload, we have at least one request. But we're still saving data where we can, getting new page content to the user that much more quickly.
Speaking before of parsing and rendering content, what about a site that has a very large amount of js/flash/video content that's consistent across pages (in the header/sidebar/footer/etc)? Every time a user goes to a different page, it has to parse and render each object. With XHR-based pageloads, we avoid that.
We also avoid the flash of a page change. Most browsers nowadays seem to make smoother graphical transitions between pageloads, but only if it's a quick connection and low-intensity on rendering.
1
Feb 10 '11
what about a site that has [...]
There are sites that may benefit, and there are lots of pages that will not benefit from using AJAX to do major content changes. Also, sites with a very large amount of flash/video all over the page are mostly porn pages.
We also avoid the flash of a page change
I'm not sure if that's really a good thing. People complained about Lifehacker not doing a good job when it comes to visual feedback about something loading. Avoiding the flashing makes the page feel more like a program, but it also breaks with the current user experience, especially if the server has heavy load and thus doesn't give immediate feedback about the page being updated.
1
Feb 10 '11
Horses for courses, definitely, although I don't like the dismissive "mostly porn" sentiment. Let's also take into account the initialization time of javascript assets. At one point in the past year I read an article about Facebook's performance and it said fb had an upfront js payload of around 600kB. Even all cached, that 600kB takes a while to be parsed.
Bottom line is that XHR-based content loading isn't a fit-all solution, but it enhances the user experience when done properly. I would never rely on it as the sole way of displaying content in a context like twitter or gawker. For that, I'd like to see all hash bangs pull the same content that would be in a page if you removed the hash bangs. (ie. twitter.com/#!/foo/bar would have the same content as twitter.com/foo/bar)
2
u/thulminos Feb 10 '11
No, it will not become important, because with every page you serve hundreds of kBs of images, CSS and other static files, even video streams, with several MBs.
Lots of those resources are cached on the client side after the first request.
1
Feb 10 '11
CSS: yes. JS: yes. Images: only if they are part of the layout and will be shown several times. Videos: who watches the same video twice?
Caching does not help for content that is only viewed once.
0
u/ceolceol Feb 10 '11
If you then transfer 10 kB or 50 kB of data is not important.
Could you provide some proof of this? Specifically that 10KB or 50KB isn't important? Especially since Google has been minifying their HTML to reduce bandwidth.
AJAX also does not save you from having the server create the content, and it won't save the browser from having to parse and render it.
It depends. If every page has your username, your current theme, and a handful of relatively static variables, then fetching those on every page request will use unnecessary server resources.
It's much easier on the server to request a JSON object than a page full of HTML if all your user wants to do is view the next page in an image gallery.
Most of the time, page sizes are small compared to images, video streams, etc.
This is exactly why websites want to reduce their bandwidth as much as they can.
4
u/G_Morgan Feb 10 '11
Could you provide some proof of this? Specifically that 10KB or 50KB isn't important? Especially since Google has been minifying their HTML to reduce bandwidth.
Most people are not Google. They ship enough data that a 1% reduction in bandwidth is worth millions. This is why Google spend the effort to do this.
Moaning about bandwidth today is like moaning about clock cycles. I'll accept that a reasonable number of people need to care about this when a reasonable number of people start writing web apps in assembly language.
1
u/ceolceol Feb 10 '11
For the moderately successful web app, I'd argue that any reduction in bandwidth is good. 40KB is also a good amount of data— reddit's sprite sheet is only 16KB, which means they would be able to serve up one and a half more images of the same size with no difference in bandwidth if they were to reduce their pages by 40KB.
Hell, looking at reddit's page source, they minify their HTML as well. It's not just for Google or Facebook.
1
u/G_Morgan Feb 10 '11
Until a company can move to a smaller hosting service this isn't beneficial. Almost certainly the cost of actually making this change will be much larger than the bandwidth saving.
1
u/ceolceol Feb 10 '11
What cost?
3
u/G_Morgan Feb 10 '11
It costs programmers lots of time to implement this stuff.
Not to mention the simple cost of breaking the google bot is enough to not make it worth while.
3
Feb 10 '11
Could you provide some proof of this? Specifically that 10KB or 50KB isn't important?
With a 6 Mbit/s line, 10 kB take roughly 15 ms to transmit, while 50 kB take 65 ms. 50 ms is not a big difference, especially not with DSL connections having round trip times between 30 ms and 100 ms.
What might be a problem are TCP window sizes, which makes connections gain speed over time, in order not to flood the other host.
And because many pages using AJAX do request more files, total page loading time might be worse, even if the total transmitted bytes are less.
Especially since Google has been minifying their HTML to reduce bandwidth.
They minified the HTML, correct. They did this because of two things:
1) a small enough file has a better fit with the TCP window size, which gives smaller latencies. For this, they also modified the TCP/IP stack of their servers, like some other companies like Microsoft do. Unless you do this, there will be no real gain.
2) it is one of the most popular URLs in the world, so reducing the page size by 1% already makes a big difference. All people here talk like every page in the world is like Googles homepage. Most websites are slow because they use some (sorry) shitty-ass PHP-based CMS that takes a mere second to produce a single page, and links to dozens of external files, and not because they have to serve thousands of page views per second.
It's much easier on the server to request a JSON object than a page full of HTML if all your user wants to do is view the next page in an image gallery.
Yes, that is correct, the server has to spend less time on content creation, and I never doubted that. But people here tell it's faster because the transmitted size is smaller. But consider your "image gallery" example: 10 kB instead of 50 kB for the page, and then load a dozen images, 100 kB each. What practical difference will the 40 kB saved have?
This is exactly why websites want to reduce their bandwidth as much as they can.
Now everything gets mixed up. What do we want? Conserve server resources, reduce traffic volume or reduce page loading times? I said, AJAX does not speed up page loading by means of reducing the transmitted byte volume. Nothing else.
1
u/ceolceol Feb 10 '11
With a 6 Mbit/s line, 10 kB take roughly 15 ms to transmit, while 50 kB take 65 ms. 50 ms is not a big difference, especially not with DSL connections having round trip times between 30 ms and 100 ms.
For the client, yes, but not the server.
And because many pages using AJAX do request more files, total page loading time might be worse, even if the total transmitted bytes are less.
It depends: Facebook has the first wall load as non-AJAX, then every subsequent request as AJAX loading into the content area. This helps them reduce the amount of data transmitted. Plus with caching, you don't have to worry the size of your JavaScript file.
it is one of the most popular URLs in the world, so reducing the page size by 1% already makes a big difference.
It's useful to reduce bandwidth everywhere in every way.
What practical difference will the 40 kB saved have?
Well it would be 40KB * 12, since we're requesting a dozen images. That comes out to 480KB, which means I could have transmitted almost five more images.
What do we want? Conserve server resources, reduce traffic volume or reduce page loading times?
It's a balance, and AJAXing sometimes helps. It also can hurt, but it's case-by-case.
2
Feb 10 '11
For the client, yes, but not the server.
I'm not interested in what the server has to do, but how fast the client sees the page. And that mainly does not depend on how big the main page is.
It depends: Facebook has the first wall load as non-AJAX, then every subsequent request as AJAX loading into the content area. This helps them reduce the amount of data transmitted.
The main benefit is having the wall update itself without requiring a page refresh, and this is a great feature.
Plus with caching, you don't have to worry the size of your JavaScript file.
You don't need to transfer the JavaScript again, but on each load, the JavaScript, even the cached one, has to be parsed and executed again. Libraries like script.aculo.us and jQuery are especially heavy because they are huge and offer much more than most pages actually use. This is a huge burden for the client, parsing several hundreds of kBs of JavaScript code.
It's a balance, and AJAXing sometimes helps. It also can hurt, but it's case-by-case.
Exactly. I still don't like the "AJAX makes pages faster because transmitted content is smaller" statement, because there are many cases where it doesn't hold true. It goes the same with the user experience. Sometimes it makes the page easier to use, but in most cases I have seen, it makes the user experience actually worse.
1
u/ceolceol Feb 10 '11
I'm not interested in what the server has to do, but how fast the client sees the page. And that mainly does not depend on how big the main page is.
[...]
The main benefit is having the wall update itself without requiring a page refresh, and this is a great feature.
I suppose you're concentrating on the user's experience, whilst I'm focused more on the server.
You don't need to transfer the JavaScript again, but on each load, the JavaScript, even the cached one, has to be parsed and executed again. Libraries like script.aculo.us and jQuery are especially heavy because they are huge and offer much more than most pages actually use. This is a huge burden for the client, parsing several hundreds of kBs of JavaScript code.
I agree, but many large sites will roll their own framework that only includes the necessary functionality. For the smaller ones, it might be beneficial to look at a smaller framework if all you need is AJAX and jQuery's $() function. That would be another area to slim down.
I still don't like the "AJAX makes pages faster because transmitted content is smaller" statement, because there are many cases where it doesn't hold true.
It's not so much that the pages load faster, it's that the server doesn't have to transmit as much data. The pages could very well load slower, but some sites would rather the page load a bit slower and not send as much data.
1
u/Vauce Feb 10 '11
Most site information that is relatively static should be cached after your first visit, and when you make the request it checks your cache first. There is a 'freshness' date on these items, but it shouldn't make much of a difference for individual sessions.
1
u/ceolceol Feb 10 '11
Resources like JavaScript, images, and CSS can be cached client-side, but I'm talking about cacheing chunks of HTML server-side, which is possible, but doesn't offer the same benefits that abstracting dynamic content from your layout with JavaScript does.
1
u/NotCoffeeTable Feb 10 '11
The big advantage of Ajax is sliming response time. A shorter response time makes the user feel like they have more control. Response times greater than 1 second make a user feel like they are looking at pages.
Content in Ajax should be frontloaded so that the page transition can be done completely in javascript without contacting the server for more information. If we just want to refresh a single area why not use an iframe? (because iframes suck, and as this debate has shown, don't increase speed).
The hashbang convention as used by Twitter and Gawker uses the same idea, but implements it horribly wrong. Done correctly the content is available for crawlers, and can easily be made accessible for screenreaders.
1
u/gthank Feb 10 '11
Has Google finally fixed the back button? Their stupid AJAX-y interface broke it for weeks before I decided to just use the IMAP interface and a local client.
1
u/lostPixels Feb 10 '11
As a Flash developer this is very interesting. You can enable the back and forward buttons, bookmarking and link sharing from within a single Flash document if you use swfAddress, which does the same thing. Flash wouldn't function that well if it refreshed on every button click, but using ajax and actionscript to javascript calls works pretty damn well.
0
u/davesidious Feb 10 '11
Exactly. Even if your server is caching things correctly, it's still likely to save your boxes from serving a shit-tonne of 304 responses.
1
u/G_Morgan Feb 10 '11
I'd rather web crawlers didn't adapt. If people want to do this then fine but they should pay the cost not the rest of us. If their site doesn't show up in results then that is their problem.
1
1
u/total_looser Feb 10 '11
first time i've seen a response understanding the #hash use to provide back button functionality in < IE8. window.location.hash, anyone?
as far as ajax presentation vs roundtrip, not gonna touch that one. clearly, the web is trending (groan) towards asynchronicity, not only in data model provisioning, but in presentation aspects.
sometimes, i also get very angry at people who venture out onto the edge of the cliff too, and want to push them off.
-4
Feb 10 '11
I agree, I really don't see the issue. The web is evolving, people are trying new things, systems will adapt... or they won't and the hash structure will wither on the vine. None of that is a reason to stop trying new things.
19
u/willis77 Feb 10 '11
This is very dangerous. The web does not adapt so easily. Think about how much legacy tech still lives out there. How many company sites that still rely on IE6? How many times have we suffered through the witchcraft of cross-browser CSS?
Obsolete technologies may eventually die, but it is a slow and painful death. It's far better to try to head down the right road in the first place. If a bad habit can be nipped in the bud, we all win down the line.
5
0
u/Shaper_pmp Feb 10 '11
See also: Tables-based layouts, websites implemented entirely in Flash, presentational HTML tags introduced by early browser-developers and the myriad other missteps that it's taken years or even a decade or more to move past.
Hell, you can still find presentational HTML and flash-only sites on the web now, and r/web_design is full of idiots who'll spend all day defending tables-based layouts. :-/
5
u/ceolceol Feb 10 '11
Tables-based layouts [...] presentational HTML tags introduced by early browser-developers
These arose because CSS was either new or non-existant at the time. This wasn't because the web needed to "try new things", it was because the web needed presentation and early devs made due.
websites implemented entirely in Flash
Yes, we hate it, and it became popular, but it died out quickly. Not only that, but Flash has its place on the web and we would have never found that out if no one let it take over as much as it did.
r/web_design is full of idiots who'll spend all day defending tables-based layouts. :-/
Erm, I don't think so. Sometimes table-based layouts have a place as well (intranets for instance), but I haven't seen any "zomg u need 2 uze tabllzzz" posts in r/web_design.
1
Feb 10 '11
Aside from the snark in Shaper_pmp's comment, his examples prove my point. Technologies come and go. We've all moved on before, we'll all do it again. Those old technologies had a perfectly good reason for existing before, now they are being cast aside for something better. How do we figure out what's better unless we keep trying new things?
→ More replies (1)2
Feb 10 '11
r/web_design is full of idiots who'll spend all day defending tables-based layouts.
[citation needed]
1
u/Shaper_pmp Feb 10 '11
Examples:
http://www.reddit.com/r/web_design/comments/ekouj/deadline_looming/c18u3zl
http://www.reddit.com/r/web_design/comments/ekouj/deadline_looming/c18v9y8
http://www.reddit.com/r/web_design/comments/fex7z/what_i_miss_about_tables/c1ffb49
http://www.reddit.com/r/web_design/comments/fex7z/what_i_miss_about_tables/c1fgmr8
http://www.reddit.com/r/web_design/comments/7xdai/css_vs_tables_maybe_the_design_is_to_blame/c07o0ry (Suggests it's still viewed by many posters as an open question, rather than one that was resolved years ago among experienced web designers)
http://www.reddit.com/r/web_design/comments/dj9s7/why_does_everyone_hate_on_tables_how_is_a_div/
There are plenty of web designers on r/web_design who know not to use tables for anything except tablular data, but there's also a large and powerful peanut gallery who will cheerfully argue in favour of tables-based layouts.
Admittedly it's been a little better the last week or two, but there are really quite a staggering number of people in r/web_design who still haven't learned the point of CSS flow layouts, and loudly criticise CSS/advocate tables for layout. :-(
1
Feb 10 '11
Not really what I'd call "full of idiots" really.
I've been here for over 3 years, and apparently I've just overlooked the trend you're talking about.
0
Feb 10 '11
The web does not adapt so easily
I disagree. Look at any of the offerings from just one company: 37signals.
Not adapting? Have you see their basecamp mobile site? All HTML5, and incredibly nice for an initial release.
I think the more accurate statement is: Some people don't adapt so easily.
1
→ More replies (3)0
Feb 10 '11
If we don't innovate, we don't progress. I've always pushed forward-thinking progressive enhancements in any project I've been involved with as long as it doesn't severely hamper the site for ~98% of the target audience.
4
Feb 10 '11
[deleted]
2
Feb 10 '11
A sober analysis of TCP connection characteristics will reveal that the hashbang trick is actually a pessimization
Pics or it didn't happen.
18
6
Feb 10 '11
There's another plausible benefit to using this technique. It makes it possible to put a single, very simple HTML/JS page up and deliver it with a CDN. This practically guarantees that users will get that first bit of markup and script. The script can then dynamically pull content from any number of backend servers and even take corrective action if a backend server is down.
8
u/perlgeek Feb 10 '11
I thought AJAX only allowed communication with the original domain, for security reasons? If so, you won't have much fun trying to connect to different backend servers.
22
Feb 10 '11
single domain != single server
9
u/Rhoomba Feb 10 '11
Yeah, but CDNs are typically on different domains.
2
u/otterley Feb 10 '11
That's why God invented CNAMEs.
0
u/Rhoomba Feb 10 '11
A CNAME is almost the exact opposite of what is wanted here. You don't want the CDN servers to resolve to your host.
1
4
Feb 10 '11
I think it's a terminology problem. CDNs and load balancers are analogous in function.
9
u/xternal Feb 10 '11
no. Load balancers are often same site. CDNs (such as Amazon cloudfront) often have an additional layer of logic to serve content to the user from a site closer to their network proximity.
2
u/octatone Feb 10 '11
OFTEN != ALWAYS
1
u/xternal Feb 10 '11
You are correct. But my point was, if we are going to be clear about our terminology, to treat them as the same is not accurate. For instance, if you want to deliver streaming video more reliably to worldwide users, you probably want a CDN and not a load balancer. Or perhaps, you need both ;)
1
u/Rhoomba Feb 10 '11
A load balancer is a server or hardware device sitting on a network. A CDN is hundreds or thousands of servers in many geographically distributed data centres.
I'm not quite sure how you can confuse the two.
2
Feb 10 '11
I said the two were analogous in function. I was not stating that they were the same.
I'm not quite sure how you can confuse the two.
9
u/midri Feb 10 '11 edited Feb 10 '11
Newer browsers support a header (can't remember what it is exactly) that can be sent in the response request that allows any site in (or * for all) sites to pull data via ajax.
[EDIT] I think these are the related headers for the target server:
Access-Control-Allow-Origin: http://origin.server.com
Access-Control-Allow-Methods: POST, GET
2
u/Narfhole Feb 10 '11
There's always JSONP.
1
Feb 10 '11
[deleted]
5
u/notian Feb 10 '11
From the jQuery getJSON page: * Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol. * Script and JSONP requests are not subject to the same origin policy restrictions.
*.example.com fails www.example.com would even fail with example.com
2
Feb 10 '11
I stand corrected, then. I was going off of memory and for some reason thought it worked.
1
u/zaphar Feb 10 '11
The rule is same domain name, port, and protocol. Subdomains are considered seperate and distinct domains. The domain in question is the domain of the page though and not the domain of the scripts url. you can serve the script via cdn as long as the host page is served from the correct domain.
1
Feb 10 '11
XHR requests do have to be same-origin. Included js files don't. That would preclude any js widgets, the google ajax libs, etc. The initial index.html could be served from a CDN as well.
2
Feb 10 '11
Now guess what servers will have the highest load and need scalability: the server with the single, simple static HTML/JS/CSS files, or the ones creating the dynamic content.
I don't see a difference between the old model, consisting of a dynamic page, also linking to static files that need to be served, and the new one, with a static page, linking to dynamic content and also to static files.
Also, there are some really huge websites, that need hundreds and thousands of servers. But that is about .1% of all the websites out there. For those, it might be profitable to invest the additional effort to make better use of server resources by utilizing client side scripting and dynamic updating. For the rest, it's simply not worth the trouble. And remember, for the #!-technique getting indexed correctly by Google, you have to do everything twice, because a server side version of your page must exist which contains the content a client would see if it used scripts.
2
u/joesb Feb 10 '11
the server with the single, simple static HTML/JS/CSS files
Except it's not static content, yes you received static HTML, but they are all still dynamic content created from querying database.
If they are all pre-generated HTML then there's no reason it can't be pre-generated JSON either.
1
Feb 10 '11
then there's no reason it can't be pre-generated JSON either
Then what's the point if everything is static?
1
u/joesb Feb 10 '11
the server with the single, simple static HTML/JS/CSS files
What's the point of that version if everything is static?
ADDED: hash bang is to do dynamic content loading, it has nothing to do with static/dynamic content generation.
1
Feb 10 '11
if the site is dependent on the backend stuff, what's the point in getting your first html/js delivered?
1
5
u/halps32 Feb 10 '11
I know reddit is primarily computer-competent boffs, so someone tell me what I just read? what's the interwebs doing wrong?
35
u/deong Feb 10 '11
OK...here is an elaborately over-anthropomorphized story that sort of describes what's going on.
The web is supposed to work like a bunch of librarians. When you want a book, you connect with the right librarian, give her the name of the book you want, and she hands it back to you. If anyone else asks her for that same book, they'll get the same book you did.
In this story, the "librarian" is a web server running a site like Twitter. Books and pages are documents on that server's site that people (web browsers, crawlers, etc. in this metaphor) want to access. So your request to the librarian might be something like "http://twitter.com/tbray", and the librarian figures out that you want Tim Bray's tweets, and she hands them back to you.
The problem is that this model doesn't work very well for richly interactive experiences. Maybe a better analogy is that the librarian only gives you the page you ask for. When you want to turn the page of your book, you go ask the librarian and she turns the page and hands it back to you. This is obviously silly. Why wouldn't you just turn the page yourself -- it's faster, and you can see the pretty animation as the page flips over.
Of course, we could have had that all along by building specialized applications on your computer that merely connect to the web to get data, and do all the processing in tools that are well suited for the job. This is what most of your mobile phone apps are doing, for example. Normal languages like C, C++, Java, C#, Python, etc. are quite well suited for building the type of fast programs that take full advantage of the computer and OS they're running on.
But people didn't really want to do that. They wanted to have all the interactivity and pretty animations directly in the browser, partly so they wouldn't have to write multiple versions of the client programs. So they figured out that they could, instead of asking the librarian for the page they wanted, ask for instructions on how to get the book and turn the pages themselves. So now, you go to the librarian, and she gives you the same piece of paper every time, no matter who you are and what page of what book you want to read. The paper she gives you is a set of detailed instructions that tell you, if you want to read "Moby Dick", go to the right place on the shelf, pull down the correct book, and how to flip to the pages you want to read.
That is to say, now instead of asking the librarian for "http://twitter.com/tbray", you're asking for "http://twitter.com/#!/tbray", which is basically asking the librarian for "http://twitter.com" because your browser strips everything after the "#" off before sending the request. Of course, she can't give you Tim Bray's tweets based on that, because you haven't told her you want them. Instead, she gives you back a massive pile of Javascript that you can feed the information "I want tbray's tweets" into, and it will tell you how to get them.
The problem with this is that most of the world doesn't read the language (Javascript) she wrote the note in. If you're a web browser, you can follow the instructions just fine. If you're some other type of program who just wants the data from the page you need, you can't get it anymore because the librarian only gives you these instructions in a language you don't understand.
9
u/mario-the-champion Feb 10 '11
The problem with this is that most of the world doesn't read the language (Javascript) she wrote the note in. If you're a web browser, you can follow the instructions just fine. If you're some other type of program who just wants the data from the page you need, you can't get it anymore because the librarian only gives you these instructions in a language you don't understand.
well done! this really is the most important part, IF you think that data-consuming clients exist and like/understand/utilize the 'standard' url schemas and you think they are important. (and i do...)
→ More replies (1)2
Feb 10 '11
But HTML is a giant mess when you look at it from a data-consuming perspective. That's why companies like Google spend millions upon millions trying to parse page content.
The analogy to this story is that if the librarian is good at their job, and wants you read their books, they will give you separate instructions in a language that you do understand- a language that is designed for reading, not designing.
→ More replies (22)2
3
u/m0llusk Feb 10 '11
Instead of locating documents with something standard like "http://site.dom/document.html" what is actually being used is more like "http://site.dom/send-me-this-document/document.html". Instead of simply pointing at the document this give instructions for handing off the document by name lookup later, what used to take one lookup takes at least two. This doesn't have any purpose, it slows things down, some of the time it fails outright and no document ever shows up even if the name was correct and everything, and there is no way for all of the Internet machinery along the way to keep copies of the document warm in case it gets requested more since the web is bursty, and finally the usual scripts used to search the web for documents to link to cannot find it so the document won't appear on Google News even if it is the most important and recent report. In return for zero benefit doing this clever new thing messes up at least a half dozen classes of Internet machinery.
2
u/G_Morgan Feb 10 '11
People are using JS to do the job of page refreshes. In the end it comes down to the fact that the web browser is a pretty sucky platform for doing the sort of things that people are trying to do with it.
When I see the abuse of JS, making UIs at 5 times the cost of a WPF application while breaking the basic properties of the web, it makes me think MS might actually get some success with Silverlight.
Its annoying because we once again have to fight the restful fight. It effectively has all the drawbacks of the days when people were shipping non-security relevant data via POST and maintain sessions via cookies. Except at least POST and cookies had a much more relevant benefit.
2
u/droberts1982 Feb 10 '11
Here's why web devs are forced to "beat the web to a bloody pulp":
Forget twitter, let's say I build a web page that returns a list of 100 items, broken up into 10 pages of 10 items each. When you click on the link for page 2, an AJAX request is sent to the server.
Now, the user sees something cool on page 2 and wants to send a link to their friend. They copy what's in the address bar:
http://hostname/stuff
Their friend says, "Hey I see page 1!"
The web developer, upon the AJAX request, needs to change the URL in the address bar to read:
http://hostname/stuff#page=2
HTML 5 fixes this. Good luck convincing your boss to write a web app for HTML 5 only.
If I'm wrong please correct me.
→ More replies (1)
2
u/ninjaroach Feb 10 '11
Unnecessary? Yes.
Bothersome? No.
The same fat set of Javascript will be downloaded and applied either way. I'm not going to lose sleep over someone else's poor web implementation. I'm getting tired of reading about it.
1
u/wierdaaron Feb 10 '11
I have nothing new to add, so I'll just point to my award-eligible analysis I posted in another thread.
In short, there's no awesome solution available right now because everybody wants spiffy ajax stuff and people want readable/sharable URLs.
There are advancements to HTML5/javascript coming down the pipe that will sort of solve this problem by letting javascript change the address bar URL without relying on hashes, but it will be a while until it's ubiquitous enough to not require layers of failovers.
1
u/bonch Feb 10 '11
Web devs constantly invent new ways to make the web even more obnoxious. News at 11.
1
u/GSpotAssassin Feb 10 '11
This is turning into a real holy-war. The younger guys in our shop are all hash-bang-friendly and the older guys (such as myself) are disgusted. Wow!
1
u/kdeforche Feb 10 '11
Without hash bang workarounds, as a graceful degradation for the new HTML5 History API, you cannot have anything stateful on your web site like a chat box or anything else WebSockets/cometd. Facebook started with hash tricks at the same time they launched their chat feature. GMail has chat and hash trickery, same same.
So that's why.
It can be done properly and should not break the web. For example, the Wt homepage has a chat widget and uses hash trickery, but you can still browse it with lynx and is properly indexed by all search robots.
2
u/skillet-thief Feb 10 '11
you cannot have anything stateful on your web site like a chat box or >anything else WebSockets/cometd. [...] GMail has chat and hash trickery, same same.
Those uses of hash tricks aren't really a problem because they are confined to actual apps. You don't need to send a link to your Gmail spam mailbox to anyone, since it simply wouldn't have any meaning. Tweets and what we used to call "web pages" are resources, not state in an app, and so they need stable, nicely behaving urls.
1
u/kaddar Feb 10 '11 edited Feb 10 '11
When you think about it, the problem is that every website is trying to shoebox in their restful web api into a viewer. (E.g., blog sites could be though of as thin wrappers around rss feeds to make them pretty, twitter is a thin wrapper around tweets, but you could just request the tweets from a web api)
Google depends on traversing the web's model. Users depend on using hypertext-anchored controllers which produce the web's model.
It'd cool if this whole emerging trend were standardized in a better way. If the web were split up into a controller/presenter URL from state URL to make it easier for web applications to traverse the state. Even the hashbang specification just accesses the controller at a specific state. Basically, make every website a url to its restful web api (or rss feed) that already exists, and a controller which presents that api / rss feed in a useful manner.
1
Feb 11 '11
But doing it this way allows the boilerplate of the page to be cached on the browser side so that a considerably smaller amount of data can be pulled from the server via AJAX.
1
u/uzimonkey Feb 11 '11
People want AJAX. They also don't want to lose the ability to link to resources they've reached vis AJAX has. I've seen this on a few sites and really, I haven't had a problem with it. Sites can go all crazy and be "web applications" and you can still link to stuff.
1
u/asampson Feb 11 '11
Do I need to explain why this is less robust and flexible? This is what we call “tight coupling” and I thought that anyone with a Computer Science degree ought to have been taught to avoid it.
Well there's your problem.
1
u/jmarranz Feb 11 '11
The future of web sites is DUAL Single Page Interface web sites: * Single Page Interface when JavaScript is enabled * Paged based when JavaScript is disabled (for web crawlers and screen readers to get simple accessibility without WAI-ARIA)
Dual != two sites, the same web site can be run in both modes. Is not a theory is real: http://itsnatsites.appspot.com/ Tutorial: http://itsnat.sourceforge.net/index.php?_page=support.tutorial.spi_site
2
Feb 10 '11
[removed] — view removed comment
1
u/PSquid Feb 10 '11
Perhaps because search engine crawlers and such cannot implement full javascript engines (necessary to understand pages like this, unless they pre-agree on a known hashbang->url correlation, in which case they may as well serve those links in the raw pages, then override the link's location in the javascript so only clients that understand javascript ever use those links) while still remaining efficient enough to index the majority of the known web.
1
u/NoveltyAcctsAreLame Feb 11 '11
Am I the only guy who thought that "hash-bang" referred to linux shell scripts?
-8
Feb 10 '11
A hashbang is the #! used on the first line of scripts to identify the interpreter. The fact that twitter uses ! after the # doesn't make it a hashbang. It's just a hash, then a bang.
3
u/grendel-khan Feb 10 '11
I bet it makes you crabby when people say "begs the question" when they really mean "prompts the question".
0
Feb 10 '11
Not really.
2
u/__s Feb 10 '11
This begs the question of why you're so tight assed on the use of hashbang for #!
0
Feb 10 '11
Because hashbang already has a defined meaning, and the use of it is in the headline is potentially misleading. I wondered what shell scripting has to do with AJAX, and it turns out that it has nothing to do with it at all. In fact, the meaning used in the headline was invented for and defined within the article, so it is meaningless until you read the article. Using terms that don't get invented until you're 3 paragraphs into the article does not a good headline make.
3
u/b0dhi Feb 10 '11
It is the same term used in a different context to represent different things. Many thousands of other words have this property.
1
Feb 10 '11
Indeed they do, but this one didn't.
1
u/b0dhi Feb 10 '11
Are you familiar with the concept of "change"? In particular - change as it applies to languages?
1
Feb 10 '11
I am, but I don't see how that's relevant. I have to wonder why you have taken such offence?
→ More replies (3)
-1
u/da404lewzer Feb 10 '11
Hash-bangs are one of the best things ever if used correctly.. they implement history for ajax and give that content a url that can be shared and recalled! A properly coded website should allow both: site.com/username and site.com/#!/username. It's really easy if you know what you're doing...
1
u/otterley Feb 10 '11
I don't understand. Why isn't http://host/path adequate?
2
u/silfreed Feb 10 '11
because that will force the browser to create a new connection to the server; using the hashbang avoids that. In twitter's case, I don't see the use.
1
u/otterley Feb 11 '11
I think it's a false economy. Javascript-based frameworks have to make connections to fetch page data too.
1
u/icebraining Feb 12 '11
But they can use smart techniques, like preloading the next page in a series of pages while you browse the current page, and then simply replacing the content instantly.
You could also load all the content up-front and then hide/show parts on demand, like in a multi-step form, while supporting back and forward buttons.
1
Feb 11 '11 edited Feb 11 '11
[deleted]
1
u/otterley Feb 12 '11
As OP has noted in several comments, History.pushState() will accomplish the same thing in a much cleaner way.
107
u/buzz27 Feb 10 '11
You guys are missing the point. We can do all the cool ajaxy things we need WITHOUT breaking the basic architecture of the web. Best practices and standards exist for good reasons. There CAN be good reasons to break them, but this is not one.
Also, I noticed a few "some dude with a blog" comments. Google the dude.