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

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

#161

Post by colecut » Mon, Mar 09, 2020, 5:00 AM UTC

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

Simple form validation would prevent that, not exactly SPA worthy.

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

#162

Post by codebolt » Mon, Mar 09, 2020, 5:01 AM UTC

colecut wrote: post #147

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.

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

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

#163

Post by techdragon » Mon, Mar 09, 2020, 5:08 AM UTC

nefitty wrote: post #44

x3haloed wrote: post #26

Earlier quoted context omitted.

It's better than everything else because people have never heard of it. When did software engineers become hipsters?

It seems like a lot of web devs are either stuck chasing novelty or constantly trying to bet on the next big thing. For example, what happened to CoffeeScript? https://trends.google.com/trends/explore?q=%2Fm%2F0hjc5m0&ge... What happened to Ember? https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0s8...

Ember is still going strong, Octane is a fantastic new release and it’s been awesome to un-learn all the ember specific things in favour of all the new vanilla JS ways of doing things that Octane makes possible.

About the only negatives I can bring up are IDE (and other sorts of vendor tools/components) support/integration is not as good as more popular frameworks like React, but that’s really just to be expected as vendors tend to target based on popularity.

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

#164

Post by henrikschroder » Mon, Mar 09, 2020, 5:09 AM UTC

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.

I literally can't tell if your comment is satire or not. I hope it is. I fear it isn't.

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

#165

Post by manigandham » Mon, Mar 09, 2020, 5:15 AM UTC

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…

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.

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

#166

Post by brightball » Mon, Mar 09, 2020, 5:23 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…

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

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

#167

Post by jonny383 » Mon, Mar 09, 2020, 5:26 AM UTC

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 acquired the skill of successfully selecting the correct architecture for the project goals (even if it is _boring_ to actually work on).

Whereas, take the junior to mid developer streams. Every time there's an opportunity to learn something new and break the grind from doing [X] for the past [Y] months, there tends to be unwarranted justifcation on why "we should use this new thing" despite there already being a well-known and battle-tested solution sitting right there.

For example: We need to build a basic company website. Someone from reception needs to be able to update the contact form and trading hours around five times per year. Someone from marketing needs to update product brochures once a month.

Seasoned engineer: Let's use any well-tested CMS such as WordPress and install a caching front-end.

Junior - mid engineers: EW WordPress! Doesn't that use PHP? Hahaha. Hahaha. Why on earth would we want to be known for using _PHP_!?!? We'd be _far_ better to just create a front-end on react and then write a microservice that will allow our staff members to update content. If marketing says SEO is necessary, we can _simply_ add a server-side rendering layer for the react front-end and deploy it onto a second microservice. And to make sure it all works, we can subscribe to some monitoring services, write a full test suite and CI pipeline. Everyone can install monitoring on their phones so if it ever goes offline, someone can immediately sign in remotely and debug which micro service is broken.

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

#168

Post by Mandatum » Mon, Mar 09, 2020, 5:30 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 management system my photographer friend can use without learning what "CLI" or "GitHub" are. They just login and make changes.

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

#169

Post by rovr138 » Mon, Mar 09, 2020, 5:35 AM UTC

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.

> building an SPA allows you to build applications as declarative composable functions which are deterministic

How is that not the definition of a function or a method?

Deterministic in what sense? It’s output? It’s input?

Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.

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

#170

Post by mrmonkeyman » Mon, Mar 09, 2020, 5:47 AM UTC

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.

This must be satire.

Literally every sentence is wrong.