Hacker News Reader

Hacker News

Comment by zeroonetwothree | Hacker News Reader

Full thread

zeroonetwothree

Yes you don’t need React for a static site. Is this news at this point?

Also I find the colour scheme hard to read but maybe it’s just me.

View on HN

> Is this news at this point?

If you started your career in the last 5-10 years then yes, it might be news.

An entire generation of web developers has been trained to think that every app big and small needs to be a convoluted SPA. The results are a disaster.

"A convoluted SPA" is fully orthogonal to React. If you're making a blog into a SPA, that's a you problem. It's been possible (and recommended for many things!) to just bake a static website with React and use JSX as a templating language for a long time.

Why would you need JSX for a static website? If you need JS then it's not "static".

You can render JSX at build-time. So it's just a templating language, as the parent comment said.

React is completely happy to spit out a DOM tree as HTML for you; wiring up the in-browser JavaScript side of React is optional. This is how static site generators like Gatsby or NextJS work (with some hacks that as a user you don't really care about) and (eliding some detail) how React Server Components now work generally. I've also used it to generate email templates[1] with some success, too.

I use JSX because it's a nicer templating system than EJS or similar. It allows me to write components to encapsulate reused fragments rather than text manipulation. And I like it, which counts for something.

Candidly, this is something that people who fulminate about React probably should know before they start talking.

[1] - https://github.com/eropple/rx-mailer

Obviously there's a spectrum. A static website just means the files are served statically from a folder, and routing is just the folder path. You can still serve JS files and have a static website. If you put an alert on a button, you're not suddenly a SPA

It's more than that: you can just call methods in ReactDOMServer to get a DOM tree. The tools to wrap this vary widely; you can use Gatsby (ehh) or NextJS (yeah!) to do it if you want a full-featured framework around all of it, you can use something like react-snap if you want something simple and less all-in, or you can just call them yourself and plop some files in a build directory.

Generally, a static website refers to any website where the server just serves files rather than running application code for each request. JS runs on the client.

For example, I've been working on a character generator for the Inquisitor tabletop game. It's completely static because I just SFTP the build output to my webserver, but it uses React and JSX.

You're missing OP's point. The website can be fully static (even without any JS) but you could still use JSX/React to generate it (during build time, not runtime).

If you've ever had to build a static website from scratch, with the same navigation, footer etc. on each page, and without using frames, then you'll appreciate the amount of work that a templating engine saves you (whether JS-based or else).

I think you all missed GPs point, JS is barely required, let alone an SPA framework, let alone static generation in an SPA framework, etc.

And you're missing the other GPs point. Even when building a static website, you might want to reuse components. Or use shared components. Or do some logic. Or easily compose things.

Note they said "JSX as a templating language". Why worsen the experience using Python + Jinja when you're just building a static site.

Mm, herein lies the problem, I was not thinking about Python at all, and I suspect we are all thinking about various different tools.

A static site is necessarily not dynamic though, as soon as you need dynamic features you need to reach for one tool or another. "Static site generators" are just dynamic sites with a pre-compile step instead of JIT.

When I think of a static site, I am thinking HTML, CSS, some server side includes for header and footer. A bit of vanilla JS if you absolutely need it. Apache and nginx both have native template includes so you don't even need an extra language like py or php.

A static site to you requires a server generating files? A static site to me implies the assets can be dumped to something like S3 and you're done.

So if you wanted to say, pre-generate those pages with the header and footer already there, you would ... ?

No I was saying the opposite, a static site is necessarily not dynamic.

I would not want to pre-generate those pages. Your static files on an S3 bucket are still served by a webserver.

Anyway, can you honestly say, hand over heart, that server side rendered JSX or React is a robust and simple solution comparable to SSI or I don't know, a bit of copy pasting? Of course not. Server side rendering is a complex toolchain that will rapidly and constantly deprecate. My blog has been sitting on the same "stack" for 13 years, takes me 5 seconds to set up a new post.

I have worked on countless JS projects, sometimes they don't even build just 6 months later without faffing about with packages and versions.

Yeah at this point I have literally no idea what you're talking about?

The thread is about pregenerating static content, "can you honestly say, hand over heart, that server side rendered ..." is way off base. Seems like"static site" means "assets can be plopped into any server that can serve static assets" to one set of people, and to others it's an invitation to balk?

I'm in the former camp, if that wasn't obvious. If you want to talk about serving static assets to host a blog, I'm down. If you want to compare server stacks, I'm out.

Yeah I was going to point out this is getting pretty obtuse but didn't want to be rude. I think we're talking past eachother, or I'm missing something.

My TL;DR I guess, pregenerating/SSR, is a more complicated toolchain than is needed for a simple site (and what I interpreted the topic comment's point to be). How you serve it wasn't really the issue, that is the easy part. I might leave it at that, cheers for being gracious.

Static doesn’t mean no JavaScript. Usually it means it’s not rendered on the server.

Every time i start making a static website, i end up needing to include a table (or some other structured display of data) and then just switch to JSX to render the data with a loop. Sometimes i then render it as html and deploy, and sometimes i deploy it as react. But that’s how i usually end up using React even when static.

Indeed, static just means that the site files can be on a CDN and not need to change. Technically, SPAs are also static, if they spit out pure HTML, CSS and JS files that you can put on a CDN.

You use JSX the same way you'd use PHP - it just compiles into HTML. In this case, you just save the output after compiling it once. (as you can with the dozens or hundreds of non-JS options that do the same)

Because they only know JS and it’s ecosystem.

It's also been possible for 30 years to do the same with languages like PHP, ColdFusion, etc, no build steps necessary, and HTML is your "templating language".

You totally can, but for my money that's kinda not great. Because HTML isn't your "templating language", PHP et al are, and you aren't templating around the DOM with typed objects, you're templating around text with all the pitfalls that entails. Object structures save time, reduce errors, and give you more to-the-programmer natural tools for composition and reuse (just call a function that returns a JSX object! give it typed parameters! declare victory and go have beers!).

I wouldn't go back to doing text manipulation to generate HTML, because I value not having to make sure I've escaped all my quotes.

PHP, ColdFusion, etc allows you to intermix HTML and variables without doing the type of escaping you're describing.

For instance, CFML:

<ul> <cfoutput query="people"> <li>#firstName# #lastName# </cfouput> </ul>

You can also write classes that return data and custom tags that return rendered html.

<cf_PeopleList queryObject="#people#">

I'm not saying we need to go back to those languages necessarily, but I think there's a ton of misconception about how those languages can be used, and quite a bit of reinventing the wheel in the Javascript world.

Sure, of course you can in some contexts and with many asterisks (though in PHP it is literally text munging and that's what you get).

But even, granting your correction: in the CF example you're writing representation and logic in two separate contexts. JSX does not do that. JSX is JavaScript and the constructs that JavaScript provides work without fail with the constructed trees (which need not be DOM trees, e.g. react-three-fiber) you're generating. It puts a lot of strain on the assertion that you must-repeat-must separate these concerns, which hasn't been materially true really at any point in my career all the way back to JSP or Velocity templates where (much like ColdFusion) you had worse tools for one context than you got for free with the other.

While JSX and something like CFML (or hell, Angular) look similar when you squint, this is a different thing. The closest equivalent is something like Scala or Visual Basic XML literals, which never took off; JSX is no-bullshit a step change in consistency and productivity and it's awesome.

Sure, I like TypeScript and componentization though which JSX can give me where PHP doesn't. Most templating languages are dynamically typed.

PHP pages absolutely have to be built/rendered.

I think the distinction is that PHP is interpreted in real time most often. So there is rarely a separate build step.

It’s a build step that happens every time the page is loaded instead of once when it’s deployed.

Then arguably JS is worse, since any 'build' steps preceding it don't bypass the (client side) interpreter either. Except perhaps if WASM is involved.

That's not true, though; JSX can be entirely prerendered server-side. If you don't write client-side JavaScript, you're not going to get client-side JavaScript (modulo maybe a thin hydration layer if you're using particularly old tools, but nothing running pervasively). Your code becomes HTML files. It's more Hugo/Jekyll than it is "a SPA".

I am unaware of a major PHP framework that is designed around similar, though it may exist.

JSX SSR would be in real time again, correct?

If you mean rendered once for all, i.e. statically, there are some PHP wikis, frameworks, and caching plugins that can/do work that way.

You think they would have discovered Flask or something similar just out of personal curiosity.

I think a culture has been created where anything resembling server-side rendering (other than Node spitting out JSON) is legacy to be avoided ..... until of course the Javascript creates its own convoluted version of server-side rendering, which is revolutionary and the new hotness.

I'm not really in webdev, although I still do django sites for people sometimes, amazed and glad I had no idea that's how things had gone.

The main benefit to JS being used as a server side rendered and client side rendered language is that you have a lot more control over which parts you want on the server vs the client, and you can introduce hydration where needed. You technically could do that in PHP and other non JS languages but that's annoying because you'll be mixing multiple languages together and it would be more clunky. So yes, there is some "revolutionary" benefit to having everything in JS/TypeScript.

My least favorite JavaScript argument is “Instead of using one good language for the backend and one lousy one for the front end, we’ll rewrite ALL the code in the lousy language to keep it easy!”

I fail to understand why anybody would use JavaScript - a language so bad everybody uses a series of wrappers around it - for anything they didn’t absolutely have to (e.g. client code).

The entire point of the MVC architecture is to allow you to pick the best tools for the job.

EDIT: I’m not saying PHP is good, though it’s better than JS. And TypeScript is still JavaScript with extra steps.

PHP is a good language? Lol

TypeScript is an excellent language and I agree, no one should be using Javascript anymore.

PHP is a good language nowadays. Much better than JS. Also, Jimmy Hendrix is dead.

I mean, Django makes it very clear and very trivial which parts are serverside and which parts are client side, and I assume rails is the same way. I don't see how JS has any advantage over their approach.

Aren't those just the server-side components from React?

They won’t touch anything that isn’t Javascript.

I use React for static sites and really enjoy it.

* as it’s simplest, it’s a really easy to use templating tool.

* there are a tools that compile to mostly static HTML, so not performance hits

* theres almost always something that pushes you to want some JS. React is handy to have. It also opens the door to all of the the community packages. No sense to re-invent the wheel.

Curious what you mean by “almost always something” that makes you use JS?

What besides shitty/illegal tracking code and cookies do you need to include? Honest question.

In my case, we wanted to gather feedback on a product we were launching. Because we wanted to move fast, we’re in a regulated industry, and our initial tests were simple, we decided to built a simple “chatbot” style feedback tool.

More generally, forms. Forms always seems to morph into more than just simple inputs.

Thanks for the reply, forms are such a pain in the ass. Of course you need hard input sanitizing on the backend but just helping people fill out a form correctly can require some JS.

I like the colors. It's readable for me and it reminds me of sherbert.

edit: hm, she says it's a yaki imo / satsuma imo color theme. I love yaki imo.

You don't understand, it's the future !

https://www.bitecode.dev/p/hype-cycles

It's not just you.

The site has poor contrast ratio - fails all accessibility guidelines for text contrast ratio requirements.

Really? Firefox says the contrast ratios meet WCAG AA.

For me, the main problem is the font weight. I'm sure it looks better on high-density displays, but it is way too thin to read comfortably at a regular pixel density.

Which extension are you using?

I use a tool called CCA and it takes font size into consideration.

I'm using the built-in Firefox accessibility pane.

I checked with other tools and yes it does pass AA for normal text. I'd still increase the contrast ratio.

I use a high resolution screen and the text is rather small - hence why it's harder to read.

On mobile it's OK.

Reply on news.ycombinator.com