Robin Ward

All these problems are solvable. I co-founded Discourse (http://discourse.org) which uses infinite scrolling heavily. Discourse is also 100% open source so you can see how we did it.

My responses below:

> Users will lose the page length orientation - the browser scrollbar become useless.

We have a fixed "x/y" posts widget at the bottom with a progress bar.

> There’s no ability to jump to the end of the list.

The aforementioned widget has an up arrow and down arrow to jump to the top/bottom.

> Your users will not be able to get back to the same in-page position in 1 click.

We use replaceState to update the URL as they scroll. The back button works fine, and you can link to any position in the topic.

> There’s no visible footer until your users come to the end of the list/content.

Isn't this true of all sites where the user scrolls anything? I guess the difference is you see it more often with pagination. We instead have a fixed header with navigation options and extra details.

> Slow Experience - You are using a lot of browser memory as the page scrolls down.

We unload posts that have scrolled off the screen. We released a library for it too - http://eviltrout.com/2014/01/04/hiding-offscreen-ember.html

> If you switch away from the page by following a link there's no way of getting back to where you left off.

The back button works fine thanks to replaceState!

> Lack of sense of completion- no closure for users.

The progress bar and constantly increasing numbers…

I can repro it. The lag is only of a few milliseconds, but enough to capture a screenshot, so it is jarring for sure.

This is on first page load - http://imgur.com/4kB93ZX

And this is on clicking through to a post - http://imgur.com/i7B3HOE

When I hit back, I get the first page's loading symbol again.

Here's another weird thing:

Sometimes, when I click from the list of posts page through to a post, scroll down, and then hit back, it takes me to the top of the post instead of back to the list of posts. This happens only sometimes, not always.

Also, it looks like you are tracking scroll position by chopping up the page into numbered sections which are tracked in the url. Going back and forth resets the scroll position to the top of the tracked section. This works mostly fine, but is off sometimes by a line or two.

Edited to add:

In an earlier post[1], Robin argues that using client-side frameworks like Ember increases speed because you can leverage CDNs. But, I think our examples suggest that there are still some speed issues in the client-side rendering, which I think is DHH's point.

Even if total times with Ember (request to server and final render) might be less than something like pure Rails, the perceived speed for the user might be lower.

Robin gives one anecdote of some people in Prague finding his Ember site faster than others. saurik and I have provided couple more anecdotes :-)

But, it might be good to collect some proper data using something like…

Aggressive virtualization, especially if it also involves removing stuff that scrolled out of view, also bogs down some screen readers (particularly Windows ones) that have their own representation of the web page.

Speaking of both Discourse and screen readers, before my stint at Microsoft, I wrote a Windows screen reader, which tried to detect client-side page navigation by watching for the URL (minus the fragment) to change. Discourse's infinite scrolling implementation broke this heuristic, because Discourse would use the history API to update the URL as the user scrolled. Not sure if I or they were in the wrong there.

Interesting that you feel that Discourse penalizes you for being far away from the origin server. When Discourse was new, one of the founders blogged about how their heavy use of client-side JavaScript made the application better for users far away from the origin server:

https://eviltrout.com/2013/01/06/turbolinks-and-the-prague-effect.html.html

Maybe the author had a point, but it sounds like Discourse still relies too much on frequent round trips.

Edit to add:

> a precise-DOM-updates framework that cares significantly about runtime performance

That's Overture, right? I wonder how it compares to Svelte and Solid.

I have limited experience with javascript and MVMM's and cannot answer all the questions, but here is what I do know:

Which is best overall?
Not enough experience with ember.js to comment.

Common gotchas for angular:
It's a very different approach when compared to using jquery for everything. The documentation can seem a bit daunting at first, as described in the popular post about why discourse chose ember.js.

"The documentation was simple to understand

Here’s some text right out of the Angular.JS guides, about a feature called Transclusion.

'The advantage of transclusion is that the linking function receives a transclusion function which is pre-bound to the correct scope. In a typical setup the widget creates an isolate scope, but the transclusion is not a child, but a sibling of the isolate scope. This makes it possible for the widget to have private state, and the transclusion to be bound to the parent (pre-isolate) scope.'" - http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.html

A lot of these problems are solved by the excellent tutorial videos at http://www.egghead.io though. I have no affiliation to the site, but it has made a ton of things about angular more clear for me.

Hope this helps!

There are probably things the web developer can do to minimise memory consumption, though there isn't an obvious solution.

That said, the problem of losing your reading position can be solved using something like history.replaceState(). As the user scrolls, update the history entry with a reference to the current reading location. Then, when the browser restarts, the website can know where the user was previously at and can return them to that location. This is the approach Discourse uses [1]. Alternatively, I suppose cookies could be used, but that's a slightly messier solution, imo.

Unfortunately, I haven't seen many websites adopt such a feature. Which is a shame because infinite scroll can make for a great user experience -- if done right. But too many websites actually suffer as a result of poorly implemented infinite scroll.

[1] https://eviltrout.com/2013/02/16/infinite-scrolling-that-works.html