> The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used.

It's easier than making the UI and server faster for sure, I'm just not sure why engineers don't insist of fixing things the right way.

> I'm just not sure why engineers don't insist of fixing things the right way

Einstein figured out why in 1907, and most of us have just been going along with the assumption that superluminal communication just isn't possible.

https://en.wikipedia.org/wiki/Tachyonic_antitelephone

Network roundtrip is still going to introduce noticeable latency even assuming everything else is literally instant.

>>It's easier than making the UI and server faster for sure

In majority of cases, I assume network latency will be the dominant factor, and that is outside the control of the engineers.

I happen to use slack from hardwired gigabit ethernet to a gigabit fiber internet connection. But I maintain some awareness that some others may use it from their older android phone with 2 bars of service, or on a laptop with 27 open blasting wifi spots, etc etc etc.

I will therefore put forward that assumption you can ensure instant communication, is the wrong wrong wrong way for engineers to write code...

>I'm just not sure why engineers don't insist of fixing things the right way.

That's like saying "just fix global warming", it's more complicated than that.

I think you’re missing the bigger picture here, google customers are marketers not gmail users.

The worst thing that google does imho is to subsidize YouTube, Gmail and other products using advertising money. They’re effectively selling your data to marketers while killing competitors.

You’re not a consumer though, you’re the product.

Google needs to sell eyeballs, so it creates products for free (subsidized by ads) and along the way destroys competition.

Google used its other monopoly, in search to aggressively promote chrome.

“Upgrade to a safe browser”.

They always use their monopolies (video, search, maps) to venture into different markets.

Google is an Adtech company.

I meant respectfully blame, fwiw. If your plugin crashes my browser and I like the plugin, I'll fix it / send a bug report. If I don't like it, or it's beyond repair, I'll uninstall it.

I have way bigger stones I can grind my axe on, if I ever feel the need.

Just take a step back and look at it, you're combining HTML, SQL and JS, on the fucking server.

If you’re going this way, might as well put all of that as a stored procedure in the database. At least it Simplifies your infrastructure.

Personally I took a break from frontend work, I'll circle back in a few years once web assembly is ready.

The JS ecosystem is insane once you take a step back and look at it.

> What is going to be the limit?

He suggests 1mb, personally I still think it is too much.

> How I, as a developer, make sure my website works everywhere?

1mb for a single page isn't enough?

> What with sites that use a lot of code but still work fast?

It's fast if the resources are near your device (CDN), most websites don't do that at all.

I think we already do this. Its built into the fabric of the web. Not sure why we are proposing arbitrary limits and additional user opt in for this.

Wether a website wants to be inefficient or has a good reason for having a lot of resources it impacts the speed with which the site loads. The slower the site loads the more users are going to abandon the site. Stats say by 2 seconds most users have abandoned a slow loading site. Caveat that if the user feels the site is really worth the wait, they will wait longer.

So seems everything in this proposal is already addressed...

> 1mb for a single page isn't enough?

What about single-page apps where the whole app is "a single page". With this proposal, even lazily loading the extra bits would hit the limit.

I strongly suspect the true purpose of this would be to make javascript unusable for all but the most trivial cases, and to train end users to fear it like a virus, or find its presence annoying, making it an anti-feature. Killing SPAs would probably be a feature in that case.

Ah yea, mostly, just frustrated that they just keep creepin on all of us. No means no, ya know?