4 ms·

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

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.

baobabKoodaa 3y ago
[flagged]
ehnto 3y ago
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.
- c-hendricks 3y ago
  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 ... ?
  - ehnto 3y ago
    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.
    - c-hendricks 3y ago
      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.
      - ehnto 3y ago
        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.

baobabKoodaa 3y ago

[flagged]

ehnto 3y ago

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.

c-hendricks 3y ago
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 ... ?
- ehnto 3y ago
  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.
  - c-hendricks 3y ago
    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.
    - ehnto 3y ago
      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.