Live data from Hacker News

RIP Jekyll (The Genesis of the Jamstack)

bridgetownrb.com

181–187 of 187 posts

Re: RIP Jekyll (The Genesis of the Jamstack)

#181
post #180
post #179

Earlier quoted context omitted.

> Respond to the message in context. Even if you still fail to understand them, are you arguing that those messages are ambiguous enough to allow for the interpretation that I could have been talking about completely abandoning the use of a static site generator and "writing HTML directly", as you were originally saying? Ok, let's get down to brass tacks. The post you originally responded to was: > Oh interesting, th…

> For all the text you have written, you have not really stated which of those to cut out, and what to replace it with. Neither one of these claims are true. You're again ignoring the context on record. You yourself stated, "You can't cut out the browser, so the only thing left was that single binary you first replied to", and the general tone is implying that being this explicit for something so obvious is superfluo…

So instead of taking me at my word, you assume the opposite of that, that I in reality do understand what you mean. Pot, kettle etc.

No, I truly still don't understand what you were or are suggesting.

Have you moved the generation software from your machine to serverside behind the colophon page, making it no longer static?

If you don't want what you apparently consider an uncharitable interpretation the easiest way is to provide more room for another.

Please ask someone in your life to read this exchange and give an outside perspective on it. It might be eye opening. Or you'll have confirmation that I'm just winding you up, or whatever it is I'm doing.

Re: RIP Jekyll (The Genesis of the Jamstack)

#182
post #181
post #180

Earlier quoted context omitted.

> For all the text you have written, you have not really stated which of those to cut out, and what to replace it with. Neither one of these claims are true. You're again ignoring the context on record. You yourself stated, "You can't cut out the browser, so the only thing left was that single binary you first replied to", and the general tone is implying that being this explicit for something so obvious is superfluo…

So instead of taking me at my word, you assume the opposite of that, that I in reality do understand what you mean. Pot, kettle etc. No, I truly still don't understand what you were or are suggesting. Have you moved the generation software from your machine to serverside behind the colophon page, making it no longer static? If you don't want what you apparently consider an uncharitable interpretation the easiest way…

> Have you moved the generation software from your machine to serverside behind the colophon page, making it no longer static?

What? No. Geez. The /colophon page itself, as stated, already contains the "transformations that need to be applied to produce the desired output".

Aside from that page, there is nothing except the runtime baked in to the browser that you are already using. That content lives as a file inside the source repo of the site you're trying to publish—and y'know what, even though I suggested making it accessible from /colophon in the final product, in fact, that doesn't even matter! You could have it be called README.html in the source repo for all it matters, just like I already mentioned.

There is no need for a separately installed "full language runtime". There is no separate binary instead, whether self-contained or not. There is no separate browser extension. There is no separate haha-here's-an-application-server-so-it's-not-actually-a-static-site-after-all. There is no need for any of those things. Why do you continue throwing even more of these types of questions my way when every previous one has already been struck down by an answer in the negative (and a "yes" to any of them would contradict the very premise)? I strongly suggest you go through your exercise of having someone else read through this, because this is exasperatingly repetitive in a way that is not my fault.

https://www.youtube.com/watch?v=6ghB0mBugww>

Re: RIP Jekyll (The Genesis of the Jamstack)

#183
post #176

Earlier quoted context omitted.

This "machine [that] perform [s] those steps" sounds exactly like it is a static site generator.

Yes, that is the intended meaning. This static site generator is non-traditional; it should live as first-class content on one of the pages of the site it outputs. This is not the way traditional static site generators work, although they should.

Sounds like a fucking weird place to keep it, so I don't think they should.

Re: RIP Jekyll (The Genesis of the Jamstack)

#184

Earlier quoted context omitted.

My work has moved largely from Ruby to JS, so I've been enjoying Gatsby! It's probably overkill for simple sites, but I like how customizable it is.

For React-based projects, I would advocate for Next.js…but yeah, unless you know you need React for very specific reasons, it's definitely overkill. =)

Next.js is cool, but afaik takes a server, right? Gatsby is nice because you get React for component re-use + styling, but it builds into regular HTML+JS files and can live on (abundant, free) static site hosts.

Re: RIP Jekyll (The Genesis of the Jamstack)

#185
post #176

Earlier quoted context omitted.

Yes, that is the intended meaning. This static site generator is non-traditional; it should live as first-class content on one of the pages of the site it outputs. This is not the way traditional static site generators work, although they should.

Sounds like a fucking weird place to keep it, so I don't think they should.

Not weird to suggest that an organization's website should serve as that organization's knowledge repository. Weird is the tradition of building out websites that are little more than Potemkin villages for the entity they represent. A Engelbart-style DKR https://www.dougengelbart.org/content/view/190/> is certainly not bizarre as willingly participating in the inconvenience of relying on out-of-band documentation like a README that exists only in the source repository that lives on, say, GitHub, and a set of scripts/binaries that you have to download/install/configure separately and whose esoteric conventions you will have forgotten by the next time you try to update the site a year and a half later https://corytheboyd.com/posts/2020-03-09>—or worse, you find those tools no longer work, even though you do remember how to use them.

Re: RIP Jekyll (The Genesis of the Jamstack)

#186

Earlier quoted context omitted.

For React-based projects, I would advocate for Next.js…but yeah, unless you know you need React for very specific reasons, it's definitely overkill. =)

Next.js is cool, but afaik takes a server, right? Gatsby is nice because you get React for component re-use + styling, but it builds into regular HTML+JS files and can live on (abundant, free) static site hosts.

It's primarily used with a server, correct. However, you can use `next export` which will generate only static assets (like HTML, JS, and CSS). Certain features aren't available that require a server (like i18n routing) but you can still do a lot!

Re: RIP Jekyll (The Genesis of the Jamstack)

#187
post #61
post #50

Earlier quoted context omitted.

Yeah, I almost choked on my lunch when I read that. In addition to your well-said reasons, it just seems icky. In my not-so-humble opinion, Twitter (among others) has become a harmful echo chamber of dangerous ideas and hypocrisy. Requiring the use of Twitter is not a good signal to send.

I'm not sure why you're getting downvoted here, twitter is a pretty user-hostile platform for anyone who doesn't have an account, or you're a mobile user who doesn't want to install their app on your phone. Read access can/is restricted based on your platform, unless you're logged in. It's also difficult to search for specific issues/read threads, etc. There's better forum-style models to use for support.

Expressing disagreement with someone's opinion with a single click is sooo easy though ...
Post reply on HN