Honest answer to your question: Because they have to-do lists a million miles long, and "make an HTML-only version" is often at the very bottom of that list, because it may require high investment while providing few benefits relative to other things on the to-do list. Also, because "giving users control" can mean a million different things… colors, fonts, sizes, dimensions, HTML vs JS, etc.

I agree with your point (here, have an upvote), but really, this should be, and already is, a browser option. Easier to do that than to get thousands of web sites to change. I know Safari has "Disable Styles" and "Disable Javascript" tucked away under the "Developer" menu of all things. Firefox has a "No Style" option somewhere in View. Would be better if it were easier to get to or even the default.

It's occurred to me that it may be a market seqmentation tactic. Possibly unintentional.

https://plus.google.com/104092656004159577193/posts/ikRoMcRw...

But by the looks of it, the search backend isn’t being run all over the world, else latency would be decent.

The vast majority of the JavaScript is superfluous third-party libraries like AngularJS. The actual app is under 2,000 lines of code. I do not expect it would be difficult to cut the frameworks out of it at all, for a lighter and faster experience that only weighed a few kilobytes.

>Once you've loaded up the SPA once (ie. your 4 second delay), you are able to do multiple searches quite rapidly as the subsequent post requests are tiny

I don't think parent poster is talking about initial page load. Instead, the search page's javascript intercepts every keydown event so you would suffer 4 second round-trip delay for every keystroke. (You can go see this in browser's developer tools by setting a breakpoint on the keydown event.)

Instead of this:

  [4 seconds] page load done, type "Ruby"

It's this:

  R [4 seconds] u [4 seconds] b [4 seconds] y [4 seconds]

More examples of this keydown latency frustration are retail websites like homedepot.com and lowes.com. When you're at home on a fast fiber optic connection, the keydown events work fine. (Customers generally like the "autocomplete" feature that the keydown javascript code enables.) However, when I'm at the store with a mobile phone on a slow 3G connection, each keydown takes 5 seconds and it makes it impossible to use the website.

Your argument is entirely unsound.

The cost difference between producing JSON and producing full HTML should be negligible, half a millisecond at most, and only a few extra kilobytes to the response (still tiny). (I’m deliberately ignoring the question of whether Algolia can emit HTML, talking rather about a theoretical system, or a system that proxied Algolia to sort that part out.) And the extra CSS and JavaScript required should be trivial.

Therefore, the difference between a full page load and slurping JSON and crafting a new DOM should be a matter of a few milliseconds at most. (And you can add a tiny JS handler that does the new page load as XHR and just replaces the body without needing to reparse any JS and CSS to shave most of those few milliseconds off if you are so disposed.)

As I assess it, the benefits of the JS SPA are a few milliseconds on each search—a frame or two at the most.

But the costs are that the first search is very slow, twice as slow in the best-case scenario (due to using a different domain—if the same domain was used, the absolute best case would only be ~33% slower, more like 40% in practice) and much worse on slow devices or higher latency environments.

The first search is the most important one and the most common one. To be sure, some will perform multiple searches, but most sessions will involve only one search.

In summary: the SPA approach has marginal benefits but severe downsides. It is not necessary or desirable for a web app like this.