Live data from Hacker News

RIP Jekyll (The Genesis of the Jamstack)

bridgetownrb.com

161–170 of 187 posts

Re: RIP Jekyll (The Genesis of the Jamstack)

#161

Earlier quoted context omitted.

Maybe this is just clickbait? Jekyll is in a fine state for an extremely mature project. It would be extremely souring to me if Jekyll decided to add webpack and other javascript dependencies with a newer version. One of the things I like about Jekyll is that it's a STATIC site generator that doesn't try to do everything. Some sites I want to be dead simple, and that's what you get with Jekyll. If I want more complex…

Is Hugo built with Ruby? Is Gatsby? Why are we saying that someone can only use the biggest Ruby-based SSG if they want something incredibly simple that will never change, otherwise they need to look somewhere else. Rails has never had that limited value prop for example.

Isn't that asking the wrong question?

If I want an SSG, I want an engine that takes a relatively simplistic text markup format, like Markdown or Org, and create a series of HTML documents from it. Why would the technology that does the gruntwork matter to me as an user?

Also, with Jekyll's plugin structure, what is an example of a functionality that cannot be achieved in Jekyll, but can in another non-Ruby SSG?

Re: RIP Jekyll (The Genesis of the Jamstack)

#162

Earlier quoted context omitted.

> Jekyll is in a fine state for an extremely mature project. That's my impression as well, as an outsider. A recurring nightmare of mine as a maintainer is that I'll wake up one day and read someone's blog proclaiming the death of one of my projects, when all I've done is stopped adding new features to it. Especially so when it's someone who's made a living for themselves as a downstream user. And I'm in the same boa…

I never declared the death of the project. Frank, the remaining release maintainer of Jekyll after Parker Moore left, declared it. Read the article. :)

Right, you're just taking private words from someone who "refrain[ed] from making any public statement", publicizing them, and trying to capitalize on it four entire days after his obituary was published now that he's not around to speak for himself. Toootally different.

Re: RIP Jekyll (The Genesis of the Jamstack)

#163

Earlier quoted context omitted.

Open Source is Not About you - https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

It's not clear from the comment whether you're rebutting the gp or supporting them: when I first read it I assumed you were disagreeing/criticising @ThinkBeat, so just to expand a little on my own interpretation from the article: - the linked articles is about open source maintainers defining the relevancy and scope of their own projects, and telling critics / commentators (like Jared White in the OP) that their expe…

Correct. People might have the expectations of successful open source projects requiring marketing and community outreach pushes. Maybe those things aren't remotely interesting to the author?

Maintaining a public road map for example, that seems like boring busy work to me. If a project is truly dead anyone is free to fork or create a new project and spend their free time putting in the never-ending work.

"If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them."

Re: RIP Jekyll (The Genesis of the Jamstack)

#164

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

Hi Jared, that issue was an exciting read. Thanks for the link. I get why you started a fork. The thumbs-up in your last comment tells a story (https://github.com/jekyll/jekyll/issues/8085#issuecomment-60...) :) (spoiler: the thumbs-up is from DirtyF).

Re: RIP Jekyll (The Genesis of the Jamstack)

#165
post #157

Earlier quoted context omitted.

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 refu…

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

This is a point of confusion, since GitHub now has a few different things that could be called "releases": tags (a Git thing), tags that are labeled as "releases" (a GitHub thing), and released packages via one of GitHub's package indexes (including one that behaves like RubyGems).

Anybody who has push access to a repository should also have access to the first two, and probably has access to the third. The first is a Git-level consequence of access, and the second is just sugar on top of tags ("releases" don't behave any meaningfully different, and many projects do releases without using the release labeling). IOW, they should have sufficient permissions, as-is, to continue cutting releases. They might not have sufficient permissions to publish those releases to RubyGems, but that just means renaming the package to `jekyll-ng` or using GitHub's index instead.

> 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!

Yeah, these facts are in tension. Then again, looking further, a lot of the recent activity has been documentation and dependency tweaks, along with some light backporting activity (since they're also continuing to support Jekyll 3). So I think the needle I'd thread here is: "the project is receiving active attention, but is sufficiently stable to not warrant regular releases."

Re: RIP Jekyll (The Genesis of the Jamstack)

#167
post #76
post #68

Earlier quoted context omitted.

Good technology alone isn't enough to lead to adoption. Tiddlywiki, imo, is the best personal blogging tools. It is a static site, it got an embedded editor, it got cool concepts realised like transclusion, among many others. Go ask around, I bet hardly anyone talks about it. If a tree falls in a forest and no one is around to hear it, does it make a sound? https://tiddlywiki.com/

Having looked quite a bit for personal docs stores: tiddlywiki is definitely very interesting and fits its niche pretty well, and I too will highly recommend people take a look at it, but it's just not viable in many cases. E.g. mobile requires a browser plugin (... which is a broken link, and there seem to be both few alternatives and they have reviews that imply there may be problems) or separate app to allow savin…

I agree. There is a lot of great software out there that never really tried to update themselves to the mobile world, and thus fell behind. Tiddly being made in 2004 is a great example of that.

Re: RIP Jekyll (The Genesis of the Jamstack)

#168
As I understand it, Bridgetown is a Jekyll fork or clone. The author tried and failed to sell his bag of tricks to the Jekyll core team so he decided to go his own way. That's fine, but this article is a blatant attempt to slander Jekyll, sow FUD among its users, and attract attention to his own product. I find this disgusting and reprehensible.

Re: RIP Jekyll (The Genesis of the Jamstack)

#170
post #167
post #76

Earlier quoted context omitted.

Having looked quite a bit for personal docs stores: tiddlywiki is definitely very interesting and fits its niche pretty well, and I too will highly recommend people take a look at it, but it's just not viable in many cases. E.g. mobile requires a browser plugin (... which is a broken link, and there seem to be both few alternatives and they have reviews that imply there may be problems) or separate app to allow savin…

I agree. There is a lot of great software out there that never really tried to update themselves to the mobile world, and thus fell behind. Tiddly being made in 2004 is a great example of that.

Tiddlywiki got particularly heavily smacked down by browser and mobile-OS changes/decisions, to be fair. For a fair amount of time, you could open a static file on your disk and it'd have access to any other file on disk, and eventually could even write back to disk... then that was locked down because it became a security issue (which really isn't surprising, but it is unfortunate for legitimate uses). For a couple (few?) years, extensions could easily work around this... now it's a huge hassle. And through it all, mobile has either not had sufficient features for that at all, or has had much stricter permissions that effectively mean no disk access at all.

The whole concept of tiddlywiki (as a single mutable html file) has become extremely difficult to maintain, where it used to be extremely simple.

The rest of the stuff tiddlywiki does is still great - transclusion is a great idea, and it works well. Server hosting is extremely cheap and simple. The UI has some very one-or-few-users-friendly patterns, and it really does do non-linear quite well. There's a lot to like about it. But once you go to web hosting, you're competing with every other website - the ecosystem is quite literally like a million times larger than cross-OS-and-serverless, it's not surprising that it's not all that well known.

Post reply on HN