Hacker News Reader

> and doesn't require that you download 90k of JS each time you want to refresh.

That's what caching headers are for. You can effectively cache your "big" JS libs indefinitely on the client, as you'll change the URL and therefore require a fresh download when the lib gets updated.

This isn't to say that cold cache performance isn't also important, but even a slow DSL connection should be fine with a once-off jQuery download.

I ran some experiments on this when I first joined Google. With JQuery loaded off ajax.googleapis.com, running my tests on google.com, cache hit rates were roughly 87%. This is with a CDN that caches everything indefinitely and the most visited site on the web at the time.

There's an extremely long tail of people who browse the web only occasionally, or have just one favorite site they go to, or who are running on devices with small caches, or who just cleared their cache because they wanted to look at porn. The hit rates are probably even worse now with the shift to mobile, because mobile devices have tiny caches. In recent prototyping experience using Chrome ADB to check on network traffic, files are gone from cache after only a half dozen or so other pageviews.

You can't assume "caching will take care of it" if the site downloads several hundred K of JS. Caching is effective at making an already-lean site even faster, and you get even more bang for your buck because more pages can fit in cache when the pages are small.

Anyway, I was thinking mostly about developer experience when I wrote that comment (this thread is about MVPs), and also mostly about mobile development, where the bulk of my time is spent lately. JQuery is a noticeable drag when loading a page over a cell network, even if you just want to try out some ideas. It's not just network latency, either; on mobile devices, you can burn significant time (and battery) just parsing and executing all that JS.

  > .ajax = iframes

I was pretty much in the same boat as you regarding all the other choices, but when i saw this I thought: "Seriously?"

I remember when AJAX came out: I was finishing my iframe-based custom-rolled 'AJAX'. It was such a hack, I can't even believe someone would consider it in 2013.

Why not XMLHttpRequest?

Iframes have a couple advantages over XHR:

1. You can do progressive rendering with an iframe. With an XHR you don't get the 'loaded' callback until the entire response has arrived, and so you can't start working with and manipulating the data until it's all there. With an iframe you can put successive chunks in <script> tags and they will start executing as soon as the closing tag for the script is found. Or if you want to transport the data as HTML, you can put a 0-length animation on each element that forms a response chunk, and listen for the animationend event to get notified as soon as it's ready in the DOM.

2. You can measure and manipulate elements while they're still in the iframe. For example, if you're animating the rest of your layout, you can measure the size of the elements that you just loaded inside a hidden iframe, adjust transitions on the main page to make space for them, and then pop the elements from the iframe into their proper places in the final layout. With an XHR, the only way to measure the element is to place it into the DOM and force a layout, which is much slower, particularly on mobile devices.

3. Iframes form a layout boundary, so when the browser lays out elements in them it stops the layout process at the iframe. This eliminates the need to do a CPU-intensive layout of the whole page when you pop in your XHR content.

Regarding the first objection, you could just send your responses as a series of websocket messages, rather than repeated AJAX request/response pairs.

The other two objections I'm not so clear on--maybe because I don't often dynamically construct views by retrieving "presentation" from the server. In what I've seen as "idiomatic HTML5 client-side development", all the views are shipped as templates with the initial code-blob that starts up the client; from then on, the client just speaks pure data-related JSON to the backend's plain HTML-unaware API. Does this practice not scale to Google levels? :)

Yeah, websockets are fairly useful if your data is JSON blobs or other byte data, but awkward if you just want to ship some more HTML for display. They're best used in long-running client applications.

As for sending JSON with rich clients vs. rendering HTML on the server; that depends a lot on the intended usage pattern of the app. For apps that you expect will be open for hours at a time, like e-mail or social networking, the former pattern is better - and indeed, GMail and G+ both speak JSON (well, a modified version that gives better latency) to rich client JS. For apps that you open quickly, perform your task, and then close (Search is the canonical example), it's far better to render all your HTML on the server and just ship that down to the browser. There is a large cost to downloading and executing all that JS, and you lose many, many customers if your app is slow.

There are strategic reasons why, if I were founding a startup today, I'd prefer to play in markets where the latter case held, unless I was writing enterprise software. Consumer markets where people spend hours with an app open are rare, and Google/Facebook generally want to own that space. I would rather not compete with them. On mobile, the open-for-hours apps are generally moving to native, where you can interact with the platform's notification API. The sweet spot for long-running webapps is enterprise and intranet applications, which has many fruitful markets, but many technologists shy away from it because there are frequently many arbitrary and difficult requirements.

> well, a modified version that gives better latency

Any more details on this (that you're allowed to talk about)? Low-latency JSON-alike communication is something I'd be highly interested in.

Personally, I've investigated BERT.js for this use-case, but it didn't work quite right (likely since the available client library was written to construct binary messages using String.charCodeAt, rather than just writing directly to an ArrayBuffer.) I kind of gave up when I realized I might be--especially on mobile--spending long enough on the pure-JS encoding/decoding processes (versus the browser's native JSON implementation) to lose any gains I'd get from the network. If you know otherwise, I'd like to hear about it.

that's all correct, but then you ruined it with the .ajax= iframes nonsense and the total waste of time removing jquery. optimizing for the right things is important, but doing the wrong ones is just wasting your time.

See my other response on iframes:

https://news.ycombinator.com/item?id=6649195

One of my big surprises moving to Google was how much iframes are still used, but even beyond that is the very pragmatic approach of looking for exactly what a technology gives you and what it costs you in return. There's basically a 1:1 correspondence between the API of an iframe and the API of an XHR:

xhr.open = iframe.src

xhr.onreadystatechange = iframe.onload

xhr.response = iframe.contentDocument

Many devs don't like working with iframes because it doesn't fit their mental model of how a request should work (possibly because iframes were initially introduced with a visual extent), but that's a problem with their mental models, not with iframes. You can always wrap the API if you don't like it, anyway - pretty much all the major frameworks do, since raw XHRs are a bit clumsy to use.

This is pretty interesting. What causes latency issues with this approach?

Having to download & run all your code on the client. In general you don't want to send things you aren't going to use on the client.

is there any small library ala "notjquery.js" that is a drop in replacement for jquery but that calls the browser native stuff directly ? serious question ?

jQuery is a map between its own small grammar and "the browser's generic stuff". You're thinking of jQuery.

Smaller than jquery would be Zepto.js

You probably want something like Zepto.js. I'd also look into Lo-dash, which is a better, more functional-friendly version of Underscore.js that provides a ton of useful helper functions.

Be warned: Zepto doesn't claim to support any version of IE, so if you need IE support you'll want to fall back to jquery (yepnope works. Conditional HTML won't in IE10+).

Zepto has an IE10 branch: https://github.com/madrobby/zepto/tree/ie10

jQuery does exactly that, with polyfills for browsers without the native implementation. jQuery 2.x does away with many of the polyfills since older IE versions aren't supported.

If you want an even smaller jQuery, you can build your own[0] without the modules you don't need.

[0] https://github.com/jquery/jquery#how-to-build-your-own-jquer...

doesn't require that you download 90k of JS each time you want to refresh.

wait...what?