Live data from Hacker News

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

paramaggarwal.substack.com

151–160 of 313 posts

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

#151

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…

>You need experienced engineers to create performance no >matter what your domain is.

Actually the funny thing with HTML is that the simplest things are fast. If you just write a old school HTML web page without a bazillion frame works and not going too heavy on graphics things are usually fast.

And doing that is literally so much simpler and easier than learning all the super complicated frameworks of the day.

So it's a progression from initially fast for simple, to slower and slower as people learn the complicated (and slow) frameworks, and then eventually maybe fast again if you have an expert who can make all this mess fast again.

Most people never reach that expert stage of course, but sadly still leave the "easy and fast" stage.

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

#152
post #67

Earlier quoted context omitted.

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

I mean... not really. I wouldn't invest in building client-side applications unless they bought me something. My customers don't really care, the majority don't even know what an SPA is. They do care that our application is faster and has more features than our competitors.

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

#153

Earlier quoted context omitted.

> Says who? Everyone who isn't only on the web to try to make money. That's who. But all you for-profit types are runining it. As the browser becomes more powerful it is more important to secure it. As security becomes more important features are removed and the browser begins telling the user what they can and cannot do. And on the webmaster side it becomes infeasible for browsers to display your site or search engi…

> But all you for-profit types are runining it As someone who loves the internet largely due to all the cool things people have made for profit, I can’t imagine how they for profit people have hurt the internet more than they have helped it. You and I wouldn’t be talking right now if it weren’t for a company making hacker news for profit.

That's not true we would be talking on something else.

In fact, the forums of yore were much better communities than places like Hacker News. And sadly Hacker News is probably one of the better communities on the internet today.

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

#154

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.

I'm not. If your application needs a database, then it needs a backend. An SPA isn't inherently a "backendless" application.

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

#155
post #51

Earlier quoted context omitted.

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.

I too despise the "kitchen sink" approach seen in Gmail's UI where they are trying to cram every unwanted and unnecessary feature into your view and RAM at once.

If you used "Inbox for Gmail" before Google abandoned it and miss the much cleaner and focused UI, this Chrome extension upgrades Gmail to have the same styles:

https://chrome.google.com/webstore/detail/simplify-gmail/pbm...

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

#156
post #14
post #13

Earlier quoted context omitted.

> recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc. What are you using?

Publii. It's developed by a European (France, I think) team. It syncs to Netlify with a single mouse-click.

+1 for Publii. It feels like it's early days for them (i.e. they only have a few themes & haven't been picked up by the third-party theme developer crowd yet), but man, does Publii make it easy for any end-user to generate and publish a static website.

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

#157
post #67

Earlier quoted context omitted.

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

To word it more technically, building an SPA allows you to build applications as declarative composable functions which are deterministic, as opposed to the spaghetti code commonly seen in the days of jQuery and PHP which is harder to read, reason about, debug and maintain due to their imperative and nondeterministic nature.

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

#158
As stated in the article, these ‘static’ files are being programmatically generated by backend services on remote servers rather than client side, but I don’t see how this could be construed as a paradigm shift back towards static site design. How can you call dynamic, per-request content generation as static design?

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

#159
post #158

As stated in the article, these ‘static’ files are being programmatically generated by backend services on remote servers rather than client side, but I don’t see how this could be construed as a paradigm shift back towards static site design. How can you call dynamic, per-request content generation as static design?

You serve the same HTML/JavaScript/CSS bundle to anyone who visits your site, and the JavaScript renders the request specific details on the client (by making more calls to the backend)

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

#160
post #151

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…

>You need experienced engineers to create performance no >matter what your domain is. Actually the funny thing with HTML is that the simplest things are fast. If you just write a old school HTML web page without a bazillion frame works and not going too heavy on graphics things are usually fast. And doing that is literally so much simpler and easier than learning all the super complicated frameworks of the day. So it…

This perspective is reasonable, until you start applying it to highly interactive / dynamic GUIs.

Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.

Another example: any page that displays a row/table of data that the user wants to sort (frontend libraries make sorting instantaneous, compared to full page refreshes with html-only).

There are lots of people using complicated frontend frameworks in cases where pure html from the server would obviously be better. But it’s difficult to argue all libraries are bad and slow for every application.

Post reply on HN