Live data from Hacker News

Websites have evolved back to static HTML/CSS/JS files

paramaggarwal.substack.com

91–100 of 313 posts

Re: Websites have evolved back to static HTML/CSS/JS files

#91

> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- i…

> Pfff - That's completely wrong. SPAs are all about performance.

Why are they consistently slower than especially when there is low bandwidth or bad reception (lost packets)? Your large JS script has to be downloaded and parsed by the browser. This is fine when you have high bandwidth and low package loss. But if the opposite is true that initial hit to get all your JS code can be really painful. Writing really fast JS is hard and is not normally something that can be done in a framework. I know React is better than things like Angular, but there is nothing faster than vanilla JS.

I write a lot of pure JS and I write stuff to be very fast. However it requires more effort and a higher skill bar (to the point where I am weaker at server side development and terrible with databases).

A lot of SPAs can be replaced with with a post back mechanism and some caching of assets (CSS etc) and a sprinkling of Ajax. The less you have to download, parse etc can really make things less painful when you are in that situation.

The problem is that many developers don't bother to learn JavaScript properly so unless you give them a framework like Angular or similar you end up with the jQuery spagetti of the past.

> Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it?

Documents and other resources are content. It is about displaying content in a meaningful manner to the user.

If it is something that the browser can't render (word docs for example) you need to deal with that appropriately.

Sometimes a plain page with some links to download your files is more than sufficient. I used the old gmail lite version for years because it was faster and did most of the same things. If you gave that interface some nicer CSS most people probably couldn't tell that it was quite old (if done right).

> Why shouldn't we pursue that? Just because the original web architecture didn't account for it?

Generally the browser already knows how to deal with HTTP and the OS knows how to deal with documents you download (if it has the right programs installed). So I think generally things just end up better when you try to keep as things were intended to be built.

I do however have the attitude of "the water takes the shape of the container" attitude to development. Whereas others don't.

Re: Websites have evolved back to static HTML/CSS/JS files

#92

Earlier quoted context omitted.

Most people know Google’s webapps are slow, they just don’t know how to do anything about it. Or they notice it as worse battery life and fans running constantly and think there’s something wrong with their laptop because they don’t realize a web app can cause that, or even know what a webapp is.

> Most people know Google’s webapps are slow Can you substantiate this with more than just your personal experience? This doesn't match my experience outside of the HN bubble.

Of course it's just my personal experience, but almost all of that's with "normies". Teachers (they live in Google webapps), writers (=avoid because terribly slow and input-laggy on low-end hardware, which ought to be all you need if you're trying to make money writing rather than impress people at coffee shops—and anyway it's not a ton better on good hardware), various other non-tech folks. The ones who don't complain about it do complain about its effects on their machines, without realizing that's what's doing it.

Re: Websites have evolved back to static HTML/CSS/JS files

#93
post #86

Earlier quoted context omitted.

Loads instantly for me on FF desktop and laptop running linux. But i have experienced what youre talking about. You either have graphics hardware support disabled or youre laptop CPU is not running in perfoance mode and has its govenor set to something like balanced or power saving mode.

...why is a web-based email client depending on graphics hardware?

The same reason your desktop based email client probably depends on it. It’s 2020 and developers are starting to make use of all the modern browser features. It’s time to stop thinking like the browser is some fickle thing that needs to be caressed and treat it like a sandboxed OS environment for delivering apps and content.

Re: Websites have evolved back to static HTML/CSS/JS files

#94
post #77

Earlier quoted context omitted.

Whether or not this is true, when Gmail came out, it was WAY better (including faster) than everything that it competed with.

It was never faster then squirrelmail. It had cool features search was fast. But loading up your mailbox never as fast as other solutions.

I was considering things like Hotmail and Yahoo mail to be competitors. Free, ad supported, web based email. Was Squirrelmail that? I don't know I've hardly heard of it.

Re: Websites have evolved back to static HTML/CSS/JS files

#95
post #87

> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- i…

> Use the right technology for what you're trying to build. Yep .. so if you want a rich responsive user experience, DON'T use any web technologies. GMail (AND Gsuite) is a perfect example of how a relatively simple concept like email can be turned into a slow, unresponsive piece of garbage.

I'm about 99% sure the store on the PS3 was webtech. That beast of a machine could barely run its own store. They lost a lot of money from me as a result of the store being super-slow, input laggy, and crashy (OOM I assume), and I can't be the only one.

PS4 feels like they've taken webtech all over the OS interface. Its store's snappier than the 3 but the rest of the interface performs way worse. Usable, but far less pleasant.

[EDIT] store should be snappier than the 3, mind, since it's way more powerful hardware—it's still kinda slow, considering.

Re: Websites have evolved back to static HTML/CSS/JS files

#96

Earlier quoted context omitted.

...why is a web-based email client depending on graphics hardware?

The same reason your desktop based email client probably depends on it. It’s 2020 and developers are starting to make use of all the modern browser features. It’s time to stop thinking like the browser is some fickle thing that needs to be caressed and treat it like a sandboxed OS environment for delivering apps and content.

We had rich desktop email clients - with more features than GMail - running on sub-GHz CPUs with integrated graphics. They also had better UI.

Re: Websites have evolved back to static HTML/CSS/JS files

#97
post #34
post #30

Earlier quoted context omitted.

> But Gmail showed us that web 'apps' are useful. And we really have come full circle. Gmail performance, at least on Firefox, is awful.

Its performance is so horrible that even on a high spec machine with fast internet, you have plenty of time to click the "switch to plain ol html" button. Which is actually more in line with the performance I'd expect from a glorified file drawer.

I have plenty of time to hit "load basic HTML" on damn beefy machines running on Google Fiber (LOL).

Re: Websites have evolved back to static HTML/CSS/JS files

#98
post #12

Good. I could do without the JS, to be honest (I'm a little tired of pages that refuse to show me anything unless I whitelist some stupid third-party jQuery script in uMatrix), but, baby steps. When sites finally ditched their trendy Flash rewrites and went back to HTML, I thought, thank God .

Be interesting to see if we could start charging website owners fees for them using our processing power to render their site. Something needs to be done to encourage some efficiencies given the fact it takes more resources to surf the internet and read about running a k8s cluster than it does to actually run the cluster

There are some interesting trade-offs in this.

There is more JS being processed, but that JS is smartly split up, bundled and takes care of loading just the content you need on subsequent browsing.

So the gains are:

- less data sent over the wire overall

- faster page loads overall initially and especially on subsequent loads.

- on subsequent loads only parts of the DOM are being rendered, not the whole thing so in some cases it might save you processing power

- no round trips to a DB and template engine, this is mostly a pro for the provider of the content

- some sites with this pattern enable you to download the whole thing as a PWA, so you can look at it offline with a single download.

Re: Websites have evolved back to static HTML/CSS/JS files

#99
post #8

Wouldn't do it any other way. I dipped out of web dev in 2015 to run an ecommerce project. I stopped tracking all the latest js framework news. I settled on a barebones CSS rule set. I stopped choosing SPAs as the starting point for mvp ideas. I shelved Wordpress and moved some content sites over to Netlify and just recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc. I was regressing to the e…

> I doubt I'll ever voluntarily use one of those frameworks for web dev. > I do, however, like this thing called, Svelte. Svelte is just another one of “those frameworks”, except with a vastly smaller community: https://trends.google.com/trends/explore?geo=US&q=svelte%20i...

Svelte components compile to vanilla javascript plus a small runtime (a dozen or so functions that track state for context and the developer tools). It's much lighter weight than React or Vue's runtime and a side effect is that integrating Svelte components into other frameworks is a breeze (especially if you compile to web components). The author refers to it more as a separate language.

I've had a great experience with it recently developing a smart tv app - which are dog slow even with a quad core ARM CPU due to the resolution so I decided to learn Svelte for the project. The big downside is another templating language to learn and as you said, the community is tiny, but the surface area is small enough that it hasn't been a problem regarding tooling or debugging. Pulling in other frameworks into a svelte app is also relatively easy so it can be part of a slow incremental rewrite, although as always it devolves into a webpack/rollup config mess.

Re: Websites have evolved back to static HTML/CSS/JS files

#100
post #87

> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- i…

> Use the right technology for what you're trying to build. Yep .. so if you want a rich responsive user experience, DON'T use any web technologies. GMail (AND Gsuite) is a perfect example of how a relatively simple concept like email can be turned into a slow, unresponsive piece of garbage.

> DON'T use any web technologies.

How do you think that would have worked for Gmail's success?

Post reply on HN