That only works if you don’t need to drive somewhere in the short term.
Let’s say you’re looking at a feed of events, and you’ve scrolled down to the middle. If it’s reactive by default, the feed will start moving past you, and you lose your place. So in this case, you need to put in extra effort to have a good UX with reactivity.
This is a good talk about the topic.
We absolutely can not assume this. Reactivity takes more physical resources than non-reactivity. You cannot explain away physical limits of a system. Some systems are designed in such a way that they will never scale beyond a certain point, because they have hit an upper bound limited by a bottleneck in their architecture.
This seems like an oversimplification, and I am not quite sure what you’re getting at.
This is a great question. @sashko just made a good point about UX glitches, flicker, and jank that happens when the client tries to render new things in front of you. I’m going to speak about it in terms of the data. Suppose you have a piece of data which is updated every 10 seconds. If analytics have shown that the users only look and interact with the data every 20 minutes, then I would be wasting bandwidth, CPU, and memory with default full reactivity. A performance optimization might be to scale down the reactivity because people aren’t interested in the data. What if my data updates every 1ms? Humans can perceive differences on the order of 10ms (more like 50ms to be exact), so why bother updating users every 1ms? What if my data changes every hour, but 99.9% of my users get on for 10 minutes, then log off. Why bother implementing reactivity for this? There are a lot of reasons why one might want to get rid of reactivity, one being how often data is updated. Reactivity assumes that if X changes, then Y should change, too. Can we assume X changes? Not always.
Keeping the UI self-consistent (React, Blaze, etc.) is trivial compared to keeping clients consistent with servers, because of the shared memory state. It’s like building a house in the middle of a wealthy suburb where the city has already installed PG&E. I would continue with our analogy and say that client server consistency is like trying to build a house with electricity in the middle of the woods, where the necessary infrastructure is non-existent. If any grand unified protocol were to emerge facilitating in reactification of the web, surely it would be an opt-in system?
I like this talk…solid counter example from a user experience…I guess this where you need to shift back to manual…but I still wonder how often is the case that people want to switch off? and should it be the exception as oppose to the rule?
He presented a very good counter example with the feed, but as stated earlier I personally didn’t have any issues with reactivity and all the people I’ve presented for were really impressed by the speed and the responsive of a Meteor app…and let us say you’ve an app with many tables (as oppose to the feed), I think it will be tedious to keep asking the user if you want to sync…
Therefore I still lean toward an automatic gear with manual override…but it seems that people in the poll are preferring the other way around and I wonder is it largely due to the concern related to potential complexity and unresponsiveness (1) of the system or that end users generally want it off as the norm as oppose to the exception (2) which I still doubt…
The user will want reactivity on, for sure (assuming we fix UI glitches mentioned by sashko). The plus sides to controlling reactivity everyone mentions here are regarding the scalability and performance of the application, which in turn affects your users.
Alright Streemo, if we agree that generally speaking reactivity is good to have (i.e. end users want to have it) but as we know it put strain on the network and the underlying system. Then wouldn’t it be desirable to enable it by default and provide the option to opt-out and optimize the corner cases when needed ? ( cases like news feed losing scroll position, data source updates <50ms, or the case you mention that the user is starting at the screen but apparently not interested in new data…)
I’m not saying it should always be on, but I think generally speaking from an end user perspective it’s a good thing to have (aside from the crazy scrolling news feed!). Therefore let the developers and consequently the end-users enjoy it out of the box, and when they start hitting performance issues due to large volume of rapidly changing data then provide the analytics and the opt-out options so the developer can adjust the rate of update or completely turn it of if needed…
In the car gearbox analogy, it’s like going automatic on a highway and when you hit the forest you’ve the option switch to manual…but you don’t make everyone drives manual because some will hit the forest…
Also I’m a bit bias, reactivity was one of the first wow moments I had with Meteor…we implemented reactivity to a dashboard in a admin panel using sockets to push events and then rest to fetch the new data and it took time to implement and was not really core business feature, it was not fun… but when I saw it coming out of the box in Meteor I was blown away 
This is starting to become a semantic discussion. If the API for reactive and non-reactive modules is effectively the same, then it makes no difference to me, and the distinction between having something then losing it and losing something then having it becomes negligible and even ill-defined.
Yeah, I guess the point here is: if you focus on one experience, the other inherently suffers. For example, Meteor was built around reactivity, and a lot of the features don’t work as well without it. On the other hand, something built to work with static data only might be harder to add reactivity to. Of course if we could have both with no compromises then that would be the best option, but I don’t think that’s ever the case.
Agreed, I think we’re same page, your brought good perspective.
The old chestnut:
Graceful degradation v. Progressive enhancement
Let’s flip for it…
Too bad there’s not a way to rate-limit something like reactivity. Default is everything reactive, then configure a rate-limit either globally or more fine-grained, when things switch over to non-reactive. Of course if something should never be reactive that’s also configurable.
I think the focus on developer experience and user experience are great, but I also think there are other strategic considerations the Apollo team should consider:
Having it on by default will turn off some users. Some developers will think “too much magic!” and discard Apollo out of hand, and will go with another solution like Relay. It also gives the potential for a bad reputation for Apollo (the same usual suspects will be shouting “it doesn’t scale”).
On the other hand, having it off by default on the other hand will still create appeal for everyone, because it’s something that’s not available anywhere else.
As long as it’s easy enough to opt-in, I think opt-in is the better strategic choice.
It’s too much magic until it becomes a norm…I’m willing to bet every technical advancement was met with too much magic statement, until it became expected and people start building on it…the keyboard i’m typing on and the screen i’m looking at are too much magic that we take for granted…
even the most real-time app out there(mostly chat) only have their main feature (the chat itself, current online users) reactive.
Users do not care if they see real time updates on the current page they are on. Often than not it could accidentally screw up the experience by updating something that the user is reading(thinking an article/text block being reactively modified while you’re trying to read it). Or a list of items all of sudden changes your view window beacause new items came down.
without electricity we wouldn’t all be here talking about the need to to not have it.
People keep on pointing the exceptional case where a user is staring at a news feed and it changes on them, I mean in that case the data could be reactive and the rendering could be a bit more intelligent to fix the scroll position and load data on the top while show a nice new data notification message, …but why not point out Uber, Snapchat, Pokemon go or the many other modern collaborative apps that was enabled by reactivity? with IoT and the potential many real-time sensors I think real-time and reactivity will be more the norm than the exception…
If you think users don’t care about reactivity, then you can opt out…and while on it, why do you need Ajax? opt-out of that as well, just let the user hit refresh like the old good days prior to 2005…less strain on the server and less complex code!
snapchat is not reactive besides chat, it just refetched data when you enter the view. When you haven’t been on stories for a while, you only get a “you have new stories/snaps icon”. And only when you visit the actual stories page, you see the items being loaded only after you visit the page. The notification(letting you know you have new items) is entirely separate from the fetching actual data themselves. This is true for almost all real time apps.
Full-stack reactivity here means server-client side perfect sync even if app is running in the background. Which is pretty much never necessary unless you are in chat.
Alright I got this use case, which is same as the news feed pattern I described above…it seems in that specific scenario which is pretty much the only UX argument I’ve heard thus far, we need to know that the data has been updated (added,removed, etc…) but without fetching the actual content until the user grants permission through an action to avoid a surprise experience…
But what about a use case like Uber? would you ask the user to hit refresh everytime a car moves? how would you handle that?
It is true that Uber needs full reactivity because the entire app is just the car-map-update. It’s a special case. Name another app that is like that?