I dont often say this on the internet but WFT? I am autistic. I love coding. A single person can create wonderful software that is a gift to everyone as open source. I hate trying to be an extrovert and engage with a lot of people. I hate twitter and discord Does that mean that I and people like me cannot do open source in 2021? Most of these seem like detriments more than anything. * Engagement on Twitter * Official…
RIP Jekyll (The Genesis of the Jamstack)
171–180 of 187 posts
Re: RIP Jekyll (The Genesis of the Jamstack)
#172Earlier quoted context omitted.
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)
#173Earlier quoted context omitted.
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 o…
Are you suggesting that we use an extension/addon for Firefox or Chrome for generating ones site from .md over the thread-starting rust binary? If so, for what reason?
In the second comment you suggest "listing transformations" "and then have a machine perform those steps". We must have different views on "damn specific".
I'm not demanding anything. You posted something that was immediately downvoted, and asked why, and I spent time outlining a possible explanation. Maybe I'm wrong, maybe I'm not, but another perspective rarely hurts.
You do you, we all strive to be understood.
Re: RIP Jekyll (The Genesis of the Jamstack)
#174What do people use besides Jekyll?
Instead of a traditional static site generator, put some content at /colophon that lists the transformations that need to be applied to produce the desired output, and then have a machine perform those steps.
Re: RIP Jekyll (The Genesis of the Jamstack)
#175There’s been a fair amount of internet consternation since I published this article. While I do stand by everything in the post factually-speaking, I apologize for the insensitive timing of this article—coming so soon after Frank’s passing. I’m genuinely sorry this came across as a “Jared vs. Frank” debacle. Should I have waited a few more weeks or months? Probably. Perhaps it was originally a mistake for me to refrain from publicly commenting on the statements regarding Jekyll’s “permanent hiatus” back in May. It’s hard to say. At the very least, I hope we can all agree that Jekyll’s legacy as the “first among many” of modern static site generators is meaningful to a lot of people, even if we sometimes disagree on the best way to honor that legacy and push Ruby on the Jamstack forward. If the one thing that comes out of all this is that more people step forward to share their positive experiences with Jekyll, Ruby, and building websites, that’s a good thing.
Re: RIP Jekyll (The Genesis of the Jamstack)
#176Earlier quoted context omitted.
Instead of a traditional static site generator, put some content at /colophon that lists the transformations that need to be applied to produce the desired output, and then have a machine perform those steps.
This "machine [that] perform [s] those steps" sounds exactly like it is a static site generator.
Re: RIP Jekyll (The Genesis of the Jamstack)
#177Earlier quoted context omitted.
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 o…
I read your two linked comments, and am still not clear on what you mean. Are you suggesting that we use an extension/addon for Firefox or Chrome for generating ones site from .md over the thread-starting rust binary? If so, for what reason? In the second comment you suggest "listing transformations" "and then have a machine perform those steps". We must have different views on "damn specific". I'm not demanding anyt…
No. A download-this-extension step wouldn't be much different than a download-this-single-binary step. I am specifically talking about eliminating inessential bits and bobs from the pipeline.
> We must have different views on "damn specific".
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?
Ignoring that issue, I don't know what's unclear about dedicating a page example.com/colophon to work as a substitute for your static site generator binary. When you want to update example.com, you visit its /colophon, you let it ingest the directory containing your markdown sources and templates and other assets for processing—same as with any static site generator—and the result is a a bunch of post-processed files comprising your site's static resources—again: same as any other static site generator produces.
If I had to bet a month of warm showers on it, I'd go with my suspicion that guard rails on your thoughts are the source of confusion here, and not that I failed in any identifiable way to state exactly what I'm talking about.
Re: RIP Jekyll (The Genesis of the Jamstack)
#178*Update I've posted to the top of the article:* There’s been a fair amount of internet consternation since I published this article. While I do stand by everything in the post factually-speaking, I apologize for the insensitive timing of this article—coming so soon after Frank’s passing. I’m genuinely sorry this came across as a “Jared vs. Frank” debacle. Should I have waited a few more weeks or months? Probably. Per…
Re: RIP Jekyll (The Genesis of the Jamstack)
#179Earlier quoted context omitted.
I read your two linked comments, and am still not clear on what you mean. Are you suggesting that we use an extension/addon for Firefox or Chrome for generating ones site from .md over the thread-starting rust binary? If so, for what reason? In the second comment you suggest "listing transformations" "and then have a machine perform those steps". We must have different views on "damn specific". I'm not demanding anyt…
> Are you suggesting that we use an extension/addon for Firefox or Chrome No. A download-this-extension step wouldn't be much different than a download-this-single-binary step. I am specifically talking about eliminating inessential bits and bobs from the pipeline. > We must have different views on "damn specific". Respond to the message in context. Even if you still fail to understand them, are you arguing that thos…
Ok, let's get down to brass tacks.
The post you originally responded to was:
> Oh interesting, that's a Rust-based SSG. Definitely something nice about a single binary and not needing a full language runtime installed.
That's someone stating that it's nice not needing anything outside of a rust binary, some reading, and of course, as you state, a browser for reading the resulting site.
You then responded with, verbatim:
> Well, one program to generate the site, and then an implicit assumption that you'll use another program (your Web browser) at some point to verify the output.
> If you're into cutting out prereqs when you can, why not cut out one more?
You are suggesting cutting out one more. For all the text you have written, you have not really stated which of those to cut out, and what to replace it with. Is there a product or project you can recommend?
> If I had to bet a month of warm showers on it, I'd go with my suspicion that guard rails on your thoughts are the source of confusion here, and not that I failed in any identifiable way to state exactly what I'm talking about.
You can either blame everyone else for not getting you, or imagine a scenario where your thoughts to you make complete sense, but when translating that to writing, some steps are ignored and you're being downvoted because the suggestions either doesn't contribute anything (as it's written, which is the correct reason to downvote something), or sounds dismissive/rude to the comment you were replying to (equally likely reason why you were getting downvoted).
You're arguing with me to change something about my interpretation, despite me having spent likely 10 times more effort on it than any other person on here did with your comment.
But hey, I might be wrong, maybe I'm too stupid to get it. I have no power over how you communicate. I have tried making myself very clear many times over, and I assume you have too. But obviously we're not understanding eachother.
Good luck in all your future endeavours. You win whatever it is you wanted to win.
Re: RIP Jekyll (The Genesis of the Jamstack)
#180Earlier quoted context omitted.
> Are you suggesting that we use an extension/addon for Firefox or Chrome No. A download-this-extension step wouldn't be much different than a download-this-single-binary step. I am specifically talking about eliminating inessential bits and bobs from the pipeline. > We must have different views on "damn specific". Respond to the message in context. Even if you still fail to understand them, are you arguing that thos…
> 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…
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 superfluous (and I'd agree). Even so, there's my reply in the affirmative. So the combo of so-obvious-it-doesn't-need-to-be-stated + having it stated anyway is working against you here on the claim that I never clearly described which to cut out.
As for the second part, I assert that putting up a /colophon page that can function "as a substitute for your static site generator binary" similar to the hypothetical README.html that I mention in comment 28407936 https://news.ycombinator.com/item?id=28407936> in fact _very_ straightforwardly addresses the "what to replace it with" issue.
> Is there a product or project you can recommend?
That's a subtle change in criteria. Many people are not content to use anything except a homegrown static site generator, and my original reply was only supposed to refer to the concept of using the runtime that you already get for free in your browser to cut out the need for either a separate runtime ("full language" runtime, in their words) or a separate binary that needs to be installed and maintained out-of-band. It was not supposed to be a recommendation of a specific project, nor does the context demand it.
> sounds dismissive/rude to the comment you were replying to (equally likely reason why you were getting downvoted)
That's a new claim original to this comment only—again, changing context—and in any case is another bad reading.
> But hey, I might be wrong, maybe I'm too stupid to get it
I don't think you're too stupid to get it; I think you're just committed to not understanding, or that you're possibly feigning a lack of understanding well past the point where you really do understand, e.g. because your real commitment is to the issue of whether I have communicated clearly—and a sudden realization on your part (esp. of something that _was_, on a second reading, adequately conveyed but earlier missed) would conflict with that commitment.