Hacker News Reader

Comment by eropple | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com