Exactly. We have always been able to do ajax loading even before Turbolinks. Client-side applications are a whole different matter, they have a level of interactiveness that is way beyond what's possible by sticking to server-side rendering. This is not a pissing contest, I just think your comment missed the point.
I can do all those things pretty easily with partial replacement. By a lot of state I mean things like highly interactive forms. This is where I've typically used Knockout or Angular in the past.
From what I see, developers these days use javascript frameworks for ridiculous things, and it's out of hand. I haven't been to a single website that uses React, Angular or EmberJS that actually needs it.
From what I can tell the background of React is, Facebook couldn’t create a notification indicator on Facebook.com, so they create this over engineered dump pile to solve that problem. Now they can tell you how many unread posts you have while downloading 15 terabytes of Javascript.
Sprint.ly wrote a kanban board in React. As a customer I didn't care, there service already worked fine. Seems they've abandoned it at this point though. Probably couldn't take the React churn, or all the engineers have jumped to the next latest framework.
Don't get me started on Discourse. Netflix.com, viewing some movies and ratings? Been to several article sites that use React. For what? Yahoo.com re wrote mail client in React. Guess what no one cared. It worked fine when they owned Zimbra.
Catch my drift?
The only way to remove this latency is for the client to take full responsibility for building the UI, instead of playing a complicated game of ping pong across the Earth.
While I don't particularly like React, that's what they're aiming for.
Just because something is possible doesn't mean people are actually using it. To make some optimistic updates you have to duplicate logic on client and server. It just gets really hairy especially when you're using auto increment id's in your database. That's just one of the problems. The complications it creates isn't even worth it. I'd rather just put a server in London. A lot less hassle then dealing with this over engineered client side bullshit.
http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html
(our server is in Chicago - SingleHop is fantastic)
Yes, you do make a valid point that things like optimistic database updates can be problematic, if not planned for. However, I would counter that the end result is much more durable and scalable than the alternative. If you build your application to handle distributed, optimistic transactions to a back-end JSON-based API (our dataset API does about 98% of the work for you), you're well on your way to having a distributed application that can be run anywhere and maintains a nice separation of concerns where the front-end or back-end can be swapped out as different needs arise. That, to me, seems to be a much better position to be in than one that requires a mix of both client-side and server-side content generation, which intimately ties the front-end to the back-end (brittle).
I like to deal with client-side apps which talk to a simple JSON API. It's a lot less hassle than dealing with this over engineered server side bullshit.
This Redux flux capicator, isomorphic, 4 Terabyte NPM install, 45 Babel plugin, flow, dumb component pure functional, immutable js, virtual dom. Now that's over engineered.
I built more complicated stuff with Knockout.js in 2011 then half the stuff I see people building with React(which from what I see is just news sites and forum software)
We've never had anybody complain about speed. If you can return responses in 100-300ms your good to go.
I do know it's limitations and that's keeping a lot of state in the client. In that case I'll usually fall back to rivets or vuejs. Yes I said fall back. People tend to go to a JS framework as the first solution. In my experience that's usually not a good idea. You'd be surprised how little you need a JS library, with a solution like Turbolinks