Comment by Smudge | Hacker News Reader

Comment by Smudge | Hacker News Reader

Parent Full thread

One thing I'm not sure I made entirely clear. Whenever my JS library intercepts a link or button click, it will update the URL bar with whatever the link or form would've brought you to, so that at any time if you refresh the page it will result in the same state that the AJAX gave you. Also, the approach is designed to gracefully degrade if JS is disabled, because the links and forms really are just links and forms.

> why redo it with JS? To lower the load time? Then don't make the page multi-meg already, no?

I hear you, and often I let links do their full behavior, no JS magic involved.

But beyond a certain amount of interactivity, the AJAX intercept approach does add a few things beyond just load time:

* Even if your payload is very small, the HTTP round trip can make the interaction feel slow, especially if your browser has to go through the full load+render routine. Things like images and sometimes even the whole page will flicker. When all you need to do is update a very tiny portion of the page, having a thin JS layer on top of your usual link/form element can be a significant UX improvement.

* Say you have a page with a few interactive buttons/links and a form with text input. Without any AJAX, if you click a button or link (that isn't the form's submit button), it will wipe anything you had entered into the text field. Not a great experience.

> Whenever my JS library intercepts a link or button click, it will update the URL bar

The browser does this already.

> Even if your payload is very small, the HTTP round trip can make the interaction feel slow, especially if your browser has to go through the full load+render routine. Things like images and sometimes even the whole page will flicker.

Browsers are very smart these days, caching many things. And if the bloat is eliminated (unnecessarily large images [make thumbnails], custom widgets [use what's there], etc.), if you webpage is not the whole of the Emacs or FreeBSD manual, it'll load in about a second or so at worst. The progressbar will indicate that it's loading, so the user will know that the server is live and he's not standing there waiting to see a HTTP 50* or 40* or a lookup error.

> Say you have a page with a few interactive buttons/links and a form with text input. Without any AJAX, if you click a button or link (that isn't the form's submit button), it will wipe anything you had entered into the text field. Not a great experience.

Also an inexistent experience. Most browsers do retain the contents after navigation, both ways. I use xombrero and it does. Chrome too, I just tried it.

If downloads of your web pages are >1sec, check your web application, web server, proxies, asset file sizes, loading order, internet connection, status of hosting, etc. Use default widgets on your forms and don't fiddle with their default behaviour. Otherwise when everybody puts out their shiny new idea, the users become timid to click anything. But I guess if all the websites were like this thousands of front-end devs and web designers would lose their jobs, and thus we have all these websites.

sigh

I guess my overall point here was that you can build a sufficiently interactive webapp without a bloated, client-side, MVC, virtualDOM, JS monstrosity. And that there are widely varying degrees of complexity to these implementations.

So, on the one hand, you have Ember, Angular, Backbone, React, etc. On the other hand you can have what I described. A very thin, very maintainable layer on top of what the browser is already doing.

That was the point.

Anyway, one other thing:

> Most browsers do retain the contents after navigation, both ways.

That's not what I meant. What I meant is that sometimes you need a button or link to take you back to the exact same form, just update the page slightly. (Add an optional field, etc. Think if you are entering an "album" and need to add a list of "tracks"). Without any JS/AJAX, that "add track" button will require a bit of finagling to not clear out the rest of the form that you've already partially filled out (but aren't ready to submit). I don't know if my example is entirely clear, but it's about enabling a certain amount of interactivity without relying on more standard JS bloat.

I guess my overall point here was that you can build a sufficiently interactive webapp without a bloated, client-side, MVC, virtualDOM, JS monstrosity.

Given the fact that most of the bloated JS monstrosities you're talking about are also the most popular websites around (Facebook, Google, Pinterest), I think this assumption might be wrong.

Do you have any examples of popular, complex web apps that work the way you suggest is better? Why is it that Facebook etc don't make things that work the way you're talking about?

I think he means sites that are not as complex as Facebook etc think they need to use the same framework as Facebook etc uses where they would be perfectly fine using the pjax/turbo link style approach the op suggests

Yes, this is what I meant. One prominent example is GitHub. As far as I know they still take pjax/turbolinks to an extreme, in favor of a true client-side template/view framework.

> it'll load in about a second or so at worst

A second is slow, and should absolutely not be the standard we're aiming for. If AJAX allows you to get closer to the ideal without messing with the typical browser workflow, why not use it?

Try browsing https://dev.to/. It feels good, no? That's the standard we should be aiming for, and it's made possible in part with exactly these ideas (see: http://instantclick.io/).

Reply on news.ycombinator.com