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

211–220 of 313 posts

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

#211

Post by b0rsuk »

kristopolous wrote: post #138
AdmiralAsshat wrote: post #2

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 .

When flash was dying I said it was a bad thing because ads would no longer be contained in these tidy, controllable virtual machines sitting adjacent to the page content but instead would be redone in JavaScript in a huge soupy mess where the content is held hostage by ads that slide in and out of the screen and cover content, popping in and out of existence, reflowing the page, making the content jump around and dis…

Flash ads were trivial to block with plugins :-). And it was safe to block because usually no serious pages used Flash much except for artist portfolios.

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

#212

Post by zeta0134 »

kugelblitz wrote: post #187
hnarn wrote: post #179

Earlier quoted context omitted.

For this typical use case, a statically rendered page with some kind of editing interface would work great, no need for databases.

Why is this downvoted? I'm a big fan of PHP, but I feel something like Netlify CMS + Jekyll on Netlify is appropriate for this. It would be super fast (statically generated and on Netlify CDN) and secure (no database or app scripts) and includes an editing interface. With WordPress I don't worry about the PHP part, but for the tendency of people to bloat it by installing plugins and not updating it enough.

Wordpress gets a hard pass for me specifically because (a) it has a plugin system that I've seen explode in practice far too often to trust, and (b) the task specifications provided by OP include marketing and management access to the editor. There is no stronger force behind pet features and rule breaking. I'd choose something easy to work with, but with an intentionally limited scope over anything with shiny bells and whistles in this specific case.

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

#213

Post by turtlecloud »

jonny383 wrote: post #167

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acq…

The reason for choosing new technology on the developers part is for job security. If everything were still php you would have outsourced his job to India ages ago. The fact is that the developers need to do this because of the ding dongs mbas in management.

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

#214

Post by mnsc »

the8472 wrote: post #186
cj wrote: post #160

Earlier quoted context omitted.

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

> Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience. The retro approach is to have two frames. One to submit, one to slow-stream a bunch of html elements which we can thankfully now lay out via flexboxes which are highly efficient when it comes to relayout, i.e. only the appended elements would incur some runtime costs, the already rendered ones don't get recomputed. I…

> ... slow-stream a bunch of html elements

Slow-stream?

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

#215

Post by jusssi »

volument wrote: post #185
jonny383 wrote: post #167

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acq…

This feels like a response from a seasoned backend engineer. Seasoned frontend developers value user experience and design — thus the tendency to go "back to static" and rarely back to WordPress.

To me Wordpress sounds exactly a suggestion you'd get from someone who doesn't have to maintain it. I.e. frontend dev.

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

#216

Post by ShroudedNight »

manigandham wrote: post #165
userbinator wrote: post #123

Earlier quoted context omitted.

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…

Unused RAM is wasted RAM. If you don't have anything else that needs it then just let your system automatically handle it. Also I find most performance issues with big apps are a result of browser extensions that interfere. Try using a private window without any extensions.

Who says it was otherwise unused? Web apps aren't used in isolation, the additional RAM you're using to speed things up by 3% has caused my code look-ups to slow down by 30% because you've consumed what was my file cache.

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

#217

Post by crucialfelix »

sireat wrote: post #196
kugelblitz wrote: post #187

Earlier quoted context omitted.

Why is this downvoted? I'm a big fan of PHP, but I feel something like Netlify CMS + Jekyll on Netlify is appropriate for this. It would be super fast (statically generated and on Netlify CDN) and secure (no database or app scripts) and includes an editing interface. With WordPress I don't worry about the PHP part, but for the tendency of people to bloat it by installing plugins and not updating it enough.

How does something like Netlify CMS work for an end user? I mean how do you skip the "storing some sort of state in DB including a users table" step? It is very typical for a small to medium business site client to want a minimal CMS and ability to add a few more users with edit rights. With Netlify CMS it seems the build happens from a git repo so wouldn't it require for end user to learn git? I love how fast and ea…

https://www.contentful.com/ works well for this.

Content, copy, even menu items, metadata etc can be edited by multiple normal people. Translations too

A static site can be set up to rebuild when someone updates content.

You could also fetch content with JavaScript on the page. That would work if it was just opening hours as in the parent example

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

#218

Post by the8472 »

mnsc wrote: post #214
the8472 wrote: post #186

Earlier quoted context omitted.

> Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience. The retro approach is to have two frames. One to submit, one to slow-stream a bunch of html elements which we can thankfully now lay out via flexboxes which are highly efficient when it comes to relayout, i.e. only the appended elements would incur some runtime costs, the already rendered ones don't get recomputed. I…

> ... slow-stream a bunch of html elements Slow-stream?

Keep the socket open and write a div to it each time a new line is posted. Browsers can and do render partial documents.

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

#219

Post by zuzun »

benbristow wrote: post #52
qznc wrote: post #22

Earlier quoted context omitted.

As long as old and compact reddit are still there, I'm fine with it. Twitter on other hand has no lightweight version, unfortunately.

Twitter's redesign is one of the most performant SPA's I've seen in a while. It's really smooth and nicely designed too. A lot better than their previous webapp.

When I open a Tweet I look at spinner animations for 10 seconds. Scrolling is also the opposite of smooth.

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

#220

Post by vanviegen »

wyqydsyq wrote: post #157
henrikschroder wrote: post #150

Earlier quoted context omitted.

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

Well, I'd argue that old fashioned PHP sites are structurally really similar to modern declarative client-side UIs, in that in both cases your're basically just constructing a series of functions that (deterministically) convert the current state to HTML.

Client-side rendering without declarative framework (say jQuery or vanilla) is different, in that you also need to consider state transition. This gets complicated fast.

And of course, the trade-off between the old fashioned approach and modern declarative revolves around how much interactivity is required.

If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!

Post reply on HN