Websites have evolved back to static HTML/CSS/JS files • Hacker News Board

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

#181

Post by blowski » Mon, Mar 09, 2020, 6:29 AM UTC

codebolt wrote: post #162

colecut wrote: post #147

Earlier quoted context omitted.

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.

A better question to me is, what does WordPress offer that a static site generator like Jekyll can't?

A huge variety of plugins, and a large pool of cheap developers with plenty of experience in the stack. I personally like Jenkins, but if I’m handing the site over to a low-tech client, I’d use WordPress hosted on managed WordPress.

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

#182

Post by winrid » Mon, Mar 09, 2020, 6:29 AM UTC

WDCDev wrote: post #87

x3haloed wrote: post #23

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

Well, I'm all for SSR for most use cases, but Gmail is that way not because it's an SPA. For example, Fastmail lives up to its name and it's an SPA.

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

#183

Post by wyqydsyq » Mon, Mar 09, 2020, 6:34 AM UTC

lazyjones wrote: post #171

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…

Another problem is that Google and some other search engines have only just started interpreting JS and since they determine the fate of most projects based on their search index, you'd better use a design that Google is able to turn into indexed pages.

I can't see JavaScript SEO ever being a thing, especially when most people these days just add SSR to their stack and call it a day

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

#184

Post by 6510 » Mon, Mar 09, 2020, 6:40 AM UTC

cj wrote: post #160

nn3 wrote: post #151

Earlier quoted context omitted.

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

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

???

  If you have any questions:

  Phone:    0123456789  [call me]
  whatsapp: 0123456789  [message me]
  facebook: html.purist [message me]

https://jsfiddle.net/r3u5yvk8/

I'm now on their contact list.

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

#185

Post by volument » Mon, Mar 09, 2020, 6:43 AM UTC

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.

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

#186

Post by the8472 » Mon, Mar 09, 2020, 6:46 AM UTC

cj wrote: post #160

nn3 wrote: post #151

Earlier quoted context omitted.

>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 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 have seen chan-style imageboards that update posts as people type (every dozen milliseconds) with 10k posts in a thread. The layout recomputation overhead is really low.

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

#187

Post by kugelblitz » Mon, Mar 09, 2020, 6:52 AM UTC

hnarn wrote: post #179

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…

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.

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

#188

Post by yurishimo » Mon, Mar 09, 2020, 6:54 AM UTC

brightball wrote: post #166

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…

Table sorting in the front end only works if all of the data exists in the front end though.

Yeah if you actually want to sort datasets of any meaningful size, you’ll be making requests to return database results anyway since a database is going to be infinitely faster and more comprehensive than any client side solution.

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

#189

Post by Lev1a » Mon, Mar 09, 2020, 6:56 AM UTC

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.

Vacuuming up RAM while all the other applications have to fight over the leftover scraps or wait for paging to get the data from disk (1) is NOT a good thing as much as Electron-zealots want to normalize running a multi-GB browser instance for every single application.

(1): burning through an SSD's limited number of write cycles OR being at least an order of magnitude slower to access in the case of HDDs

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

#190

Post by zelphirkalt » Mon, Mar 09, 2020, 6:56 AM UTC

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…

Except that usually someone from marketting or the reception still wont touch the website, because they think, that they can save time by delegating that back to the developers. Wordpress has some kind of terrible design decisions backed in and yes, there are many more elegant and long term effective ways (it's not about getting it online in 30mins) to build a company website.