Live data from Hacker News

RIP Jekyll (The Genesis of the Jamstack)

bridgetownrb.com

151–160 of 187 posts

Re: RIP Jekyll (The Genesis of the Jamstack)

#151
post #141
post #138

Earlier quoted context omitted.

Presumably because generating your site with B was faster than writing HTML directly.

...where does "writing HTML directly" come from? We're still talking about using a static site generator, whether Runtime A and Runtime C are being used, or Runtime A together with binary B, or just Runtime A.

From the same place as your:

> If you're into cutting out prereqs when you can, why not cut out one more?

You can't cut out the browser, so the only thing left was that single binary you first replied to.

Re: RIP Jekyll (The Genesis of the Jamstack)

#152

> Those concerns led me to fork Jekyll and create Bridgetown. Please, Jared, contribute to Jekyll instead. There are many contributors, and you will probably get better code reviews. Bridgetown is your one-person show where you contribute the most commits ( https://github.com/bridgetownrb/bridgetown/graphs/contributo... ). Who is reviewing your changes? :) YOU can revive Jekyll :)! I would like that. No offence, but…

Been there. Done that!

https://github.com/jekyll/jekyll/issues/8085

This was before I had the slightest inkling of ever attempting anything like a fork. :)

And I'm truly thankful for all the people who are placing their trust in the long-term health of Bridgetown as warranted by the extremely active and robust 16-month commit and release history so far.

Re: RIP Jekyll (The Genesis of the Jamstack)

#154
post #137

Jekyll is already feature complete. I haven't updated my jekyll build container in years. (I update the site it builds often.) What is this "dead" nonsense? It isn't a story, it's a tool, and it's complete. By that logic my framing hammer is "dead" now, too. "No more updates" isn't always a bad thing.

Plenty of people are not asking for Jekyll to be feature complete. It's fallen woefully behind relative to its competition.

As for the "dead" nonsense and where that's actually coming from, did you read the article? :)

Re: RIP Jekyll (The Genesis of the Jamstack)

#156
post #21

I use Jekyll for a static site and I guess I just don't really understand why it needs further development. I haven't upgraded my version of Jekyll since I think 2017 because it does what it says on the tin. Sometimes it's ok for software to be "done".

My thoughts are the same. Jekyll “just works” for me, why does it need further development?

Yet Jekyll just doesn't work for lots of other people. That's why vital software dependencies always need further development…because over time they properly service a smaller and smaller subset of users—unless we're talking about an extremely specific single-use library of some fashion. That's not what Jekyll is!

Re: RIP Jekyll (The Genesis of the Jamstack)

#157
post #74

Earlier quoted context omitted.

I dunno, if you look at the releases instead ( https://github.com/jekyll/jekyll/releases ), they were doing monthly releases for a long time, and now it's been 6 months without a release. The last was April 2021, and OP quotes the "release maintainer" of Jekyll as declaring Jekyll dead in "May 2021"... Sounds like a "Hotel California" repo now, if you follow me. Which is unacceptable for a lot of distributors/users (…

This is where my outsider's perspective falls short: assuming that the old release maintainer isn't actively preventing the project from appointing a new release maintainer, what stops them from just keeping on? Deviations from their previous release schedule are certainly noteworthy, but release schedules also naturally length as projects mature. And then there's the Theseus-type questions: if Jekyll changes its nam…

I'm not familiar with Github release permissions because it's not a process I've ever used, but I assume it's a different capability from being able to push patches. A "release maintainer" & repo owner who won't release or isn't adding release capabilities isn't "actively preventing" anything; they are simply not doing anything.

At this rate, if the release maintainer continues to ghost the project (including by refusing to make any clear public announcement), Jekyll users are going to have to fork. You can't wait forever.

> but release schedules also naturally length as projects mature.

That's why I pointed out they had been maintaining a very steady monthly release schedule for years beforehand (and just look at the total release count!). Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!"...

Re: RIP Jekyll (The Genesis of the Jamstack)

#158
post #151
post #141

Earlier quoted context omitted.

...where does "writing HTML directly" come from? We're still talking about using a static site generator, whether Runtime A and Runtime C are being used, or Runtime A together with binary B, or just Runtime A.

From the same place as your: > If you're into cutting out prereqs when you can, why not cut out one more? You can't cut out the browser, so the only thing left was that single binary you first replied to.

> cut out [...] the single binary

That's a correct reading of my comment. To take that to mean, though, that you should start "writing HTML directly" is a logical leap—and one that happens to turn out to be wrong; it's not something I wrote, and it's not even something I implied. It's an incorrect reading of my comment.

Re: RIP Jekyll (The Genesis of the Jamstack)

#159
post #158
post #151

Earlier quoted context omitted.

From the same place as your: > If you're into cutting out prereqs when you can, why not cut out one more? You can't cut out the browser, so the only thing left was that single binary you first replied to.

> cut out [...] the single binary That's a correct reading of my comment. To take that to mean, though, that you should start "writing HTML directly" is a logical leap—and one that happens to turn out to be wrong; it's not something I wrote, and it's not even something I implied. It's an incorrect reading of my comment.

Correct or not, I would assume it's the reading everyone made. We all read in good faith and write in good faith, but if everyone misreads something you write, either everyone else has to try harder to decipher it or you can perhaps try to phrase it in a way that's less ambiguous.

Re: RIP Jekyll (The Genesis of the Jamstack)

#160
post #159
post #158

Earlier quoted context omitted.

> cut out [...] the single binary That's a correct reading of my comment. To take that to mean, though, that you should start "writing HTML directly" is a logical leap—and one that happens to turn out to be wrong; it's not something I wrote, and it's not even something I implied. It's an incorrect reading of my comment.

Correct or not, I would assume it's the reading everyone made. We all read in good faith and write in good faith, but if everyone misreads something you write, either everyone else has to try harder to decipher it or you can perhaps try to phrase it in a way that's less ambiguous.

You missed the "logical leap" part. It was a big logical leap—bordering on nonsensical which you pretty much acknowledged in your first response. If, when reading someone's comment, your first instinct is to say to yourself, "How could someone think that's a good idea?" then your second thought should be, "Yeah, how could someone think that? I'll bet they don't." This isn't Twitter; replying to a comment as if, out of the range of possible interpretations, what the author intended was the dumbest one—just because you can plausibly argue that's what their words really meant—is pretty much against the rules.

> I would assume it's the reading everyone made

Even after what just happened, you're still making assumptions?

> We all read in good faith

That's disputable. Actual observed behavior on HN lately seems to trend towards the easiest/shortest path to dismissal, or: How can I reaffirm that someone I want to disagree with is dumber than I am?, again à la Twitter.

> phrase it in a way that's less ambiguous

Okay, I'll bite. How should it have been phrased? By the time you had written the comment prior to your most recent one, I had already posted two other comments that were pretty damn specific, one of them excruciatingly so:

https://news.ycombinator.com/item?id=28524423>

https://news.ycombinator.com/item?id=28518839>

What you're demanding is to spend an inordinate amount of effort seemingly to optimize for folks who are some combination of (a) subject to guardrails on their thoughts but silent about it, (b) themselves unwilling to put two seconds' consideration into an idea posted on a site explicitly meant for curious discussion, and/or (c) possibly deliberately uncharitable/hostile. https://pchiusano.github.io/2014-10-11/defensive-writing.htm...>

Post reply on HN