Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

paramaggarwal.substack.com

Post reply on HN
Print view View original

141–150 of 313 posts

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

#141

Post by chrysoprace »

ShinTakuya wrote: post #134
chrysoprace wrote: post #54

Earlier quoted context omitted.

No, it doesn't need to be, but it is nicer . There's quite a lot of complexities to my country's tax law (as with any country's tax law, really) and it's heavily simplified by giving you highly dynamic choices. Trying to use my country's immigration site, which has some JavaScript sprinkled on but is largely static, is a largely inferior experience.

There's no reason you can't query a backend for the complexities and present those dynamically to the user. For instance, quite often an SPA might ping the backend for a list of states or provinces once you've selected a country.

Sure. It's up to the engineer implementing said app to determine the best fit for the project.

At the end of the day, you have to choose what's right for your users; whether that's a seamless experience with no full page reloads, or the occasional full page reload.

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

#142

Post by julianlam »

wyqydsyq wrote: post #136
torgoguys wrote: post #45

Earlier quoted context omitted.

SPAs being the darks ages is over-the-top, but being an SPA when other web architectures could better serve the user is a dark pattern . That tax app doesn't need to be an SPA. JavaScript powered interactions make the experience nicer for the user, but that doesn't mean it needs or is improved by being a single page.

If it's a web-based user interface as this tax app sounds to be, it is arguably improved purely by being an SPA. Requiring full page reloads just to submit or change some tiny bit of data in a page is objectively bad UX.

Besides doing my taxes on paper, I can't think of anything more tedious than filling out tax forms via a vanilla HTML form.

At least my SPA tax software makes the form filling a little more exciting, and doesn't s#!t the bed when I hit enter by accident

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

#143

Post by non-entity »

julianlam wrote: post #142
wyqydsyq wrote: post #136

Earlier quoted context omitted.

If it's a web-based user interface as this tax app sounds to be, it is arguably improved purely by being an SPA. Requiring full page reloads just to submit or change some tiny bit of data in a page is objectively bad UX.

Besides doing my taxes on paper, I can't think of anything more tedious than filling out tax forms via a vanilla HTML form. At least my SPA tax software makes the form filling a little more exciting, and doesn't s#!t the bed when I hit enter by accident

Personally I wish more forms did have enter bound to submittal

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

#144

Post by julianlam »

muglug wrote: post #51
torgoguys wrote: post #45

Earlier quoted context omitted.

SPAs being the darks ages is over-the-top, but being an SPA when other web architectures could better serve the user is a dark pattern . That tax app doesn't need to be an SPA. JavaScript powered interactions make the experience nicer for the user, but that doesn't mean it needs or is improved by being a single page.

I think an SPA can be much more user-friendly than a traditional series of server-rendered pages. Email is a great example of this - GMail, at launch, had much better UX than existing server-rendered applications like Hotmail. You can find bad UX everywhere - in SPAs and server-rendered interfaces alike - but there’s nothing implicit to SPAs that reduces usability.

I feel like Gmail has lost that edge. Email being a text medium should be fast, but Gmail using up many hundreds of megabytes of RAM and taking many seconds to load really feels like they've lost sight of what reading an email is about.

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

#145

Post by mycall »

userbinator wrote: post #123
manigandham wrote: post #118

Earlier quoted context omitted.

Extreme statements aren't useful. GMail is a poorly built app, that's all. There are plenty of great examples. Both Outlook and Fastmail have fast and feature-rich email clients. Gmail was good back in the day and got carried away by project managers and feature creep. Meanwhile Google Docs continues to be a pinnacle of what you can achieve on the web.

My experience with the Outlook web app (not the "basic HTML" mode, which is perfectly usable in contrast) is the exact opposite --- it's extremely slow and consumes a ridiculous amount of memory for what it does (I've seen it take over 2GB of RAM, and this is with an account where all the emails with their attachments total less than 100MB.) When composing a message it lags so much that it will delay each keystroke b…

> I've seen it take over 2GB

Probably because that RAM wasn't doing anything else. Why not use it as cache to speed things up. I'm sure it can work fine in much smaller RAM sizes.

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

#147

Post by colecut »

chrysoprace wrote: post #43

This is something that I see espoused by "web traditionalists" for lack of a better term. Sure, there are a lot of web developers who are not optimising for performance but I think the difference is that it has simply shifted to the frontend where it's more noticeable. The kinds of people who care about performance in the backend are exactly like the kinds of people who care about performance in the frontend. There's…

What in JavaScript are you using to take the place of a server side database?

Your comment seems to imply that the only options are SPA or WordPress..

If you are building something that would normally need to be a desktop app, sure, an SPA might be a good idea. But this is still rarely the case, most web pages are just are just presenting data, and in those cases, the less JavaScript the better.

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

#148

Post by wyqydsyq »

akiselev wrote: post #99
jakelazaroff wrote: post #19

Earlier quoted context omitted.

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

> Svelte components compile to vanilla javascript plus a small runtime

Same could be said of React though. React components are literally just plain JavaScript functions which return VDOM nodes that get diffed and applied to the DOM by the runtime library.

The only objective advantage I see to Svelte is it's tiny footprint, which if you really need you can already get by using Preact (3kb vs Svelte's 3.5kb) without having to learn yet-another-completely-arbitrary-templating-language to no benefit.

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

#149

Post by cookiengineer »

userbinator wrote: post #123
manigandham wrote: post #118

Earlier quoted context omitted.

Extreme statements aren't useful. GMail is a poorly built app, that's all. There are plenty of great examples. Both Outlook and Fastmail have fast and feature-rich email clients. Gmail was good back in the day and got carried away by project managers and feature creep. Meanwhile Google Docs continues to be a pinnacle of what you can achieve on the web.

My experience with the Outlook web app (not the "basic HTML" mode, which is perfectly usable in contrast) is the exact opposite --- it's extremely slow and consumes a ridiculous amount of memory for what it does (I've seen it take over 2GB of RAM, and this is with an account where all the emails with their attachments total less than 100MB.) When composing a message it lags so much that it will delay each keystroke b…

What I wish for every Christmas is that web developers across the globe finally learn that syncing a draft server-side onkeyup is the worst idea, and it should never be pursued in implementing it.

Reality has rtt and shitty 2G slow, and will drive people away from your web product if you are too silly to cache things locally.

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

#150

Post by henrikschroder »

ng12 wrote: post #67
torgoguys wrote: post #45

Earlier quoted context omitted.

SPAs being the darks ages is over-the-top, but being an SPA when other web architectures could better serve the user is a dark pattern . That tax app doesn't need to be an SPA. JavaScript powered interactions make the experience nicer for the user, but that doesn't mean it needs or is improved by being a single page.

"Single page" isn't the why it's the how. It enables you to take a JavaScript-first approach which in turn makes building complicated applications easier.

> It enables you to take a JavaScript-first approach

Uh-huh...

> which in turn makes building complicated applications easier.

What? This is vacuous market-speak.

Post reply on HN