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

171–180 of 313 posts

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

#171

Post by lazyjones »

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.

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

#172

Post by htgb »

Mandatum wrote: post #168
codebolt wrote: post #162

Earlier quoted context omitted.

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.

There's https://www.netlifycms.org/ if you want a static site generator with a CMS, FYI.

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

#173

Post by hesarenu »

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.

When did gmail become slow. It pretty fast for me. If speed is slow then yeah.

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

#174

Post by wyqydsyq »

rovr138 wrote: post #169
wyqydsyq wrote: post #157

Earlier quoted context omitted.

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.

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

It basically is and that's the point. With SPA's you generally structure it so your entire app is just a function. The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery selectors match up with what the PHP backend spits out.

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

What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output. PWAs are generally deterministic because they're just functions that take an input and give you back a DOM. Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input, it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one.

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

This has nothing to do with languages, it's about project architecture and programming paradigms. The classic webserver+jQuery type architecture is inherently imperative. Of course it can have little islands of functionally pure, declarative code, but the overall software architecture is still imperative.

In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.

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

#175

Post by wyqydsyq »

henrikschroder wrote: post #164
wyqydsyq wrote: post #157

Earlier quoted context omitted.

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.

It isn't. I elaborated a bit in my later comment: https://news.ycombinator.com/item?id=22523344

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

#176

Post by hanniabu »

htgb wrote: post #172
Mandatum wrote: post #168

Earlier quoted context omitted.

A management system my photographer friend can use without learning what "CLI" or "GitHub" are. They just login and make changes.

There's https://www.netlifycms.org/ if you want a static site generator with a CMS, FYI.

Are you aware of any open source applications as a CMC for static generators like Jekyll? Would be very convenient to have one with a a simple github login/auth settings page and then add/edit page/post options and the ability to select or upload a theme would be great.

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

#177

Post by indysigners »

Mandatum wrote: post #168
codebolt wrote: post #162

Earlier quoted context omitted.

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.

Yup, exactly that. WordPress editors (WYSIWYG and Gutenberg) are still far more user-friendly and mature than a Netlify CMS that still is buggy like hell and where many little details and YAML formattings need to be fixed in code editor. You really cannot expect such a thing to be done by a non-coding person.

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

#178

Post by 6510 »

Mandatum wrote: post #168
codebolt wrote: post #162

Earlier quoted context omitted.

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.

my photographer friend can use ftp

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

#179

Post by hnarn »

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.

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

#180

Post by onion2k »

RockIslandLine wrote: post #59
onion2k wrote: post #20

Earlier quoted context omitted.

The trend in my work is to add more and more JS to get the render time below 11ms per frame (11ms for my code, plus 5ms for the browser to paint and update, for a solid 60fps). To do that takes a lot of data structure design, memoization, cache management, plus a decent understanding of how browsers put things in the DOM and on the screen. Admittedly I work on something that's a bit unusual (a diagram tool for lawyer…

Why would you ever build that kind of application using web technologies?

A browser gives you robust networking, caching, rendering, and security out of the box. SaaS means updates and versioning aren't issues. Online means I don't have to consider network installs behind law firm's firewalls. I'd prefer not to have to touch any of those myself even if it means I have to deal with JS and SVG rendering performance (which is actually really interesting).
Post reply on HN