Yet each of those steps solved a different problem.

Early computers did not have the local processing power needed to run heavy jobs.

Early PCs did not have the storage.

WWW solved an entirely different problem, namely distribution and communication.

JS et. al. solved the problem of responsiveness and interaction ie. latency.

I don't really see those as exhibiting cyclical traits, at best I see it as a correlation ie. side effects of the true problems being solved.

> JS et. al. solved the problem of responsiveness and interaction ie. latency.

You mean "introduced", right? Back before the modern web, when we all expected software to run on our machines, there was no responsiveness and latency problems, because data didn't travel over the wire unless it absolutely had to.

You can't download the entire internet. And loading a new web page every time you push a button is slow.

Not in practice, given that in reality of this use case, JS code also does network requests, which tend to be at least as slow as downloading a HTML page.

That said, what I meant is modern JS enabled moving into the web things that should have stayed local. It's literally two step backwards (moving software into "the cloud") and one step forward (giving back some responsiveness through AJAX).

For some reason the web feels a lot faster when I disable JS...

I can make an application as fast as you want if it doesn't have to run correctly.

Most of the time when you put JS on your page, what you're doing is breaking the thing that would - without JS - still correctly do what it's actually supposed to do.

"Most of the time"? Citation needed.

While I generally agree with the sentiment of "do more by coding less", and minimalist user interfaces, there are plenty of cases where you throw a whole lot of functionality out the window by outright banning JS.

> WWW solved an entirely different problem, namely distribution and communication.

> JS et. al. solved the problem of responsiveness and interaction ie. latency.

I don't think either of these statements is correct. There wasn't a problem of 'responsiveness' and 'interaction' on http to begin with, in fact what Sun and Netscape did with javascript was to overengineer the web because they saw it as a business opportunity to add client-side code. http was designed (badly) to exchange hypertext documents, not to perform transactions over the server, or render video-games, or play music and videos, and certainly not to transfer files, for the latter ftp was desgined (also badly).

While I accept that my description of JS et. al. might be contentious, I don't see that you have argued against my piece on the WWW in general.

Regarding latency and responsiveness I agree that they are issues that depend largely on your use cases and your skill at implementing solutions. In this regard I can agree that some pages simply don't need JS. It is also being misused for ads and tracking to a degree that is problematic and can in itself cause issues.

That's basically what Chromebooks already are. I think it's the future too. The only problem is that it moves away from the "upgrade your device every X years" paradigm that makes consumer electronics manufacturers money. They'll have to switch to a subscription model and people may not like that (and personally I'm terrified of the alternative situation where a company would rather I give them my personal information than pay them $1000 every 4 years)

One way to approach the latency problem is with more aggressive colocation. For example, an apartment complex could have its own AWS or Google servers for local computation or video streaming.

> One way to approach the latency problem is with more aggressive colocation. For example, an apartment complex could have its own AWS or Google servers for local computation or video streaming.

That would be great, if only we could make it not belong to Amazon or Google. Consider the same idea phrased like this: apartment complex have servers in their basement offering compute, and services you use work on those servers. The model of today is that companies own services, control where the compute happens, and ship your data to them, taking ownership over it in the process. The alternative model I dream of is your data under your control, your choice where the compute happens, and third-party code being shipped to that place.

Let's imagine we could solve the easy problem of writing the software that is fully distributed to each complex and interacts with the software in any other complex. How do we solve the operations problem of running the machines in the complex?

One model is to overprovision hardware a bit, and just not repair until it is significantly degraded (at which point you just swap it out and refurbish). Maintaining a software platform is getting easier.

VMs, containers, and whatever stuff Amazon is doing with that Lambda thing all sound like a good start.

> it moves away from the "upgrade your device every X years" paradigm

Don't Chromebooks have ~4yr end-of-support lifecycles where they stop receiving upgrades?

6.5 years for most devices, 5 years for some legacy cases, and it is a soft limit ie. they don't automatically enter EOL, they just stop guaranteeing the updates.

Source: https://support.google.com/chrome/a/answer/6220366

6.5 is pretty respectable. Not quite like Windows or general purpose Linux which can be upgraded almost indefinitely. I have Vista laptops released mid-2009 (>8yrs old) that run Windows 10 rather well considering their age. Of course, no one would have guaranteed 8yrs on those devices. I'd wonder what experiences people with EOL Chrome devices out there are having with upgrades.

I imagine you could still update with some wench-work. An EOL date of 6.5 sounds to me like a way to say that "beyond this point we will stop testing and ensuring compliance, and to avoid fucking over your relic (in PC terms), with an update that is untested on your specific hardware, we simply disable the automatic updates. Good luck."

Yeah, if we want latency added to literally every action... I understand that what you're saying is a possibility, but I sure hope it doesn't come to pass.

Those of us who get frustrated by latency in our tools were left behind long ago. Shiny user interfaces, cloud to-do lists, adblockers, bloated fad frameworks of the week, electron apps, blue apron for dogs... This is our reality now.

I miss the internet I grew up with. The one before all the money arrived to ruin absolutely everything.

New technology starts with the above-well-off, using tech you currency consider "absurdly unattaible to the masses" (like cars in the 20s, or telephone in the 40s, or computers in the 60s, or 24/7 internet in the 90s): for instance, when you just get a basically free gigabit connection straight into the backbone (like in a new upscale Japanese apartment building) the very idea that latency could even be a problem just... disappears.

In that context, just attaching an interactive window to a remote running process (as long as it can stream faster than whatever is your minimum acceptable framerate at your minimum acceptable resolution) is literally indistinguishable from running locally. So I frankly do hope that comes to pass (as long as I also get to keep being able to build a desktop computer for working offline).

Latency and bandwidth are different though. Your GBit connection won't help you access servers on the other side of the Atlantic.

I have no idea why you would need to leave your country in a world where we're back to thin clients and remote processing. Pretty sure the most obvious place for that processing to take place is at what used to be ISPs and have in this hypothetical future become Interactive Service Providers rather than "internet" service providers, with low latency, high bandwidth hubs in or near your city (and more likely, multiple hubs per city).

The catalyst of such a shift could be a very good thing, e.g. exceptional internet speeds everywhere

Now I expect that there will come usability experts from google/facebook/amazon and tell you that an average user does not event know what latency is.

Native apps have won over web app ecosystem, plainly and simple. WASM will not change things even a bit to root causes of people deciding to use native apps over web apps.

Google and amazon certainly think the average user cares about latency, even if they don't know what it is: https://blog.gigaspaces.com/amazon-found-every-100ms-of-late...