Hacker News Reader

Comment by donatj | Hacker News Reader

> Most web apps I work with daily have highly sophisticated in-browser interactions that are built with JavaScript and can only be built with JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc.

There is truly nothing about any of those that couldn't be done with a simple page refresh. Especially YouTube. Generally I find most of what JavaScript adds just irritating.

View on HN

I feel like Gmail reached a peak of Javascript use just slightly past what the basic-HTML version has, and everything since has just slowed it down and made it eat more RAM for little benefit. Sometime between then and now I'm sure they added some "helpful" frameworks that have contributed to the problem. Inbox is even worse.

Our children won't believe we ever browsed the web in a graphical multitasking OS on 64mb of RAM and a single processor core. "Don't be silly, that wouldn't even be 1/6 enough to load Google Inbox!"

That's hilariously clueless. Do you think youtube is just a <video> tag?

Let's list Youtube's features that could be done with no Javascript

* Displaying the video

* Controlling the video (although with the browser's default controls)

* Being logged in

* Listing videos

* Voting

* Commenting

* Suggested videos

* Subscribing

Actually, I can't see a single thing that can't be done without Javascript. It has no complex notification system aside from annotations (and I'm not sure anyone enjoys annotations), nothing that isn't provided by browsers. But no javascript would require page refreshes, which makes for a worse UX. Eh, we survived refreshes before. Maybe browsers could even agree on a standard to refresh only part of the pages by querying the server themselves. Throw in five lines of JS to save to localStorage the current time on the video and restore it on reload.

Of course it can be done with page refreshes, but it would be a worse user experience to do so.

Not saying it's true in the case of Youtube, but I've noticed recently that going back to lame old creaky page-refreshing HTML+(a little)CSS+a few lines of JS sites with no AJAX that they feel unbelievably fast compared to most AJAX-heavy Angular/Backbone/React/Whatever sites.

Ajax was better UX than full page refreshes when it was basically just replacing frames and iframes. It's become bad UX now that template rendering systems and a few hundred KB of code are involved.

Actually, I just tried this with modern Gmail in one tab and the basic HTML version in another. It's way, way faster to switch folders/categories in the basic HTML version. It wasn't even close, despite modern Gmail "efficiently" loading just the data it needs and basic HTML refreshing the whole page.

So you are saying one shouldn't use JS to implement voting and comments but instead voting and comments should interrupt the video and then one uses JavaScript to restore the playback position. You also imply youtube should have waited for 6 years or whatever for video playback to even be possible without client side programming.

> Maybe browsers could even agree on a standard to refresh only part of the pages by querying the server themselves.

Maybe browsers could also agree on implementing all needed applications in the browser. Then you just make <youtube> tag and you have implemented youtube.

HTTP 204. You send the request, the browser stays where it is. Super simple, and what it was made for. Amazon used to use it quite heavily back in the day.

Is there a spec that the browser must stay where it is? Otherwise I would just use a form targeted to a hidden iframe. Still it's not usable here since you won't see your vote or comment or anything without reloading the entire page.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html "If the client is a user agent, it SHOULD NOT change its document view"

Also, a tiny bit of JS and no ajax can solve that easily.

The spec language "SHOULD" is not same as "MUST" at all.

> Also, a tiny bit of JS and no ajax can solve that easily.

No disagreement from me that JS solves these issues.

> The spec language "SHOULD" is not same as "MUST" at all.

There are edge case clients that would need to contravene this. Most of those clients don't support JavaScript (or in many cases video) in a meaningful way, making the whole thing moot.

The spec language "SHOULD" is not same as "MUST" at all.

No, but in practice all major browsers (Firefox, Chrome, IE, Opera and Safari) do so. And it's not like the implementations of JS and its APIs never differ.

The interesting thing about the modern web developer is that they don't know jack or shit about HTTP.

Yes. Quite literally "kids these days". HTTP is so powerful and so under utilized today.

Youtube without voting and comments sounds like video nirvana.

Maybe you could have some kind of application, or "app" that users could install locally, on their computer or device, and then this application could play videos from Google, without needing to use a web browser at all!

And have full access to your machine as well! Let's just make every website a downloadable application then.

And build it for multiple platforms. Unless you only care about one.

No, let's just have applications be applications. You know what works really, really well for streaming videos across a network? VLC.

Let's kill UX and get rid of all the smooth JS interactions and replace them with refreshed pages and native browser controls. Geez... are going backwards here?

Actually, the <video> tag is the only important part, the rest is just noise.

I can see where that comes from, the functionality of Youtube is nothing without its videos.

But on the other hand, Youtube wouldn't have as many videos – specifically the content creators wouldn't have as much of an incentive to upload them – without the social features being there.

I play youtube videos in VLC. No JS required, and I get higher quality sound as well.

So you downloaded 30 MB of client side code instead of 100kb. Don't see how that's a win. By "higher quality" you mean placebo (see foobar2000 faq) or some DSP filters?

> So you downloaded 30 MB of client side code instead of 100kb. Don't see how that's a win.

Depends how you're counting. Using that 100kb of code "as intended" essentially requires Firefox (95MB) or Chrome (153MB), or some proprietary alternative.

To use VLC instead, we can get by with something like dillo (1MB) and youtube-dl (1MB), which (added to your 30MB estimate for VLC) is much less client-side code.

(Size estimates taken from packages.debian.org)

Firefox and Chrome are application platforms, like your OS. It doesn't make sense to count them. They don't only run youtube, unlike VLC which is only a media player. Otherwise VLC counts as 20 GB (or whatever) for the OS as well.

Then Firefox and Chrome loose again, though.

Because then you have the 7GB OS + 95MB Firefox + 100kB YouTube vs. the 7GB OS + 30MB VLC + 2MB youtube-dl

And, additionally, the browser is just a document displayer, like a PDF viewer, or an image viewer. 135MB for that is far too much in any case.

From a performance perspective, it is a win. I've used the VLC trick to smoothly play videos on machines which are too old to play them at full frame rate in the browser.

Its already on my system so doesn't get downloaded with each video.

> That's hilariously clueless. Do you think youtube is just a <video> tag?

I wish. Either that, or `youtube-dl` became the official UI.

Reply on news.ycombinator.com