Hacker News Reader

Comment by osrec | Hacker News Reader

I know a lot of people long for the days when the web was just text and a few JPGs. I personally am waiting for the web to become a rich, ubiquitous, standardised application delivery platform that works on any device. I think web assembly adds to the richness while being fairly standardised, so I welcome it!

View on HN

These things are cyclical:

* Early computers (1960-1980s): Dumb Terminal - Remote Server

* Early PCs (1980s-1995): Local Processing - Remote Storage

* WWW (1995-2010s): Dumb Terminal - Remote Server

* JS/ASM/Etc (2010s - near future): Local Processing - Remote Storage

Its fully possible that we will switch again to dumb terminal model. For instance, once the hassle of local code execution takes it toll, someone will have the bright idea of just putting the web browser itself in the cloud and just having a remote control connection to that browser....and the cycle will begin again.

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.

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...

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.

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?

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

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.

> 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."

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.

> 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.

> 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.

> richness

That includes the problematic features like tracking. Running software from random sources is dangerous in ways we are only beginning to understand.

Let’s keep in mind that software running in a browser is sandboxed, using standardized APIs, and isn’t nearly as privileged as software running directly on your desktop.

Problem is, adding to the bl… sorry, richness, doesn't remove the old cruft.

How about having an application platform that would be just an application platform? No HTML, no CSS, no built in multimedia. Just a VM, a viewport, audio, and inputs (and local storage if the user allows it).

I'm all for building from scratch a lean minimal runtime platform as you describe (that's what operating systems should be), also it should be "easy", take a minimal Linux kernel and add some thin APIs on top. But good luck turning this into a project that gains any traction.

Using the browser platform to bootstrap such a thing isn't such a bad idea in comparison... sooner than later we need to depreciate the ugly parts, like WebRTC, WebAudio and trim some fat here and there, but other platforms have their ugly parts as well (look at the mess that is Android).

Exactly. Leave https alone and use it for hypertext. Have another protocol (vmtps?) that is used for apps. Browsers could support both.

Agreed. It seems we are just piling on one thing after another. Surely we can start fresh with a better eye toward the future.

TLS + HTTP Methods/WebSockets + HTML + CSS + JavaScript + JS frameworks

Plus all the server side stuff. It's all a mess.

But that's also the beauty of it. Within the browser we can support the old and the new without too much trouble.

You need a browser in the first place. The standards are now so big that to write a modern, compliant browser, you need to be an international corporation.

A market with only 4 competitors (Microsoft, Google, Mozilla, Apple), is not a market. It's an oligarchy.

We already tried that - Java Applets. Silverligt was the same idea. And Flash I guess? All attempts failed in the marketplace. It turns out using higher level standards like HTML, CSS, URL's etc actually provide a a lot of value.

I was going to say there same thing - this just seems like java Applets have been reinvented

Obligatory point that Flash didn't fail in the marketplace. Rather, it was wildly popular, so much so that Microsoft eventually felt the need to develop a comparable tech -- Silverlight.

Flash on the web faltered rapidly after many years of efforts by Mozilla, Apple, Opera, and associated individuals. They were looking to move the web 'forward' had a high-profile disagreement with W3C, so they started their own standard-setting collaboration to specify HTML5 and associated JS APIs. The blogosphere eagerly awaited the results, which promised to formally bring multimedia and rich interactivity to HTML, without having to use a vendor plugin.

When Apple announced that Flash won't be supported on the upcoming first iPhone, it was over. After a few years, when apps came to the iPhone, Adobe failed at marketing the fact that their Flash assets can be compiled into iPhone apps using Adobe AIR.

With existing Flash assets effectively relegated to desktop-only, it was only a matter of time before it was pushed out of the standard browser stack. Although later, both Microsoft and Google shipped Adobe's plugin (with better process isolation) together with the browser or the OS, and hooked into their respective auto-updaters, Flash was on its way out.

Seconded. If Flash wasn't proprietary, it would still thrive. It could have displaced JavaScript itself.

There is an open source version Gnash. I installed it on a laptop a few years back and it ran fairly well, but a bit slow compared to the real Flash. Why do you think that didn't take off?

Edit: Looking at the wikipedia page I see one reason (though I am not convinced its the reason it didn't take off). https://en.wikipedia.org/wiki/Gnash_(software)#Adobe_Flash_P...

It's not fully compatible. Of course it didn't take off. You want the default application to be free software.

They didn't fail in the market, they were actually quite popular (maybe not java, but flash definitely). It is just that Apple killed them by not making them run on mobile. That's more of a case of a major player strong forcing the market.

Good luck running an ad blocker when every site is run in wasm and rendered to canvas.

You can still block domains that serve ads.

Also rendering the whole page in a canvas implies forgoing the entire DOM, which leaves behind basics like links, forms, embedded videos, etc. It would also mean getting raw input and drawing+laying out everything yourself instead of letting the browser do it.

That's all true.

But the domain serving the ads might be the same one serving the rest of the content. And if that server is motivated enough to show you that ad, they will do all of the things you mentioned. I've been worried for sometime that this will be the end-game of the ad-blocker wars.

Right, but all that could happen now. Webasm doesn't change anything in that regard.

I agree. I'm pretty excited about webasm, although I'm nervous about ad-blocking in general.

It makes it easier though.

Then ad blocking would move to image recognition and/or automatic binary reverse engineering.

> rich, ubiquitous, standardised application delivery platform

Lots of fancy words for bloat. Oftentimes malicious bloat at that.

I think web needs some more standardized functionality (like popups/modals, better dropdowns styling, datagrids ) so you do not have to implement things yourself or research and find a solution made by a third party.

Reply on news.ycombinator.com