alt Hacker NewsWorth mentioning that while this was very nice work by a Helix enthusiast, it was proposed as a replacement for the official docs and mostly rejected, and for good reasons IMO. An instructive discussion!
https://github.com/helix-editor/helix/pull/12127#issuecommen...
It's rarely a good idea to do a bunch of work on a big change to an open source project in a direction that has not been validated by the maintainers. Or at least, if you do, do it for your own education and don't have high expectations that it will be merged. The contributor in question had a very good attitude about it.
Replies
> It's rarely a good idea to do a bunch of work on a big change to an open source project in a direction that has not been validated by the maintainers.
While this is good advice in general, it doesn't tell the whole story in the case of this specific project. The helix maintainers have a track record of giving very slow "no"s and wasting contributor time. They encourage contributors to fix various odds and ends, until the PR has been nit picked to death, and then finally the concept is rejected. Totally backwards, good project leadership would front-load the conceptual yay-or-nay before reviewing any actual code.
The Helix devs have a very specific and unusual taste, so I would never consider PR-ing anything more than a simple bug fix.
Not all open-source projects want contributors, many are open-source for different reasons.
Writing good docs is almost impossible, the existing ones weren’t good when I read them so I wouldn’t be so reverent about these norms or whatever. State your contribution as loudly as you want but be prepared to meet the light of reality. Also sometimes the people in charge are too stupid to understand you’re right.
> - The homepage right now is extremely lightweight and uses next to no javascript. The new design just looks like the same generic Starlight template I'm not sure we want to use a javascript framework. While it provides a lot of features, bitrot in the javascript ecosystem happens at a very fast pace (and pulls in thousands of dependencies). I have sites written both in gatsby and vuepress and between major version breaking changes and deprecations as frameworks cycle, it's a ton of work to keep up (e.g. vuepress -> vitepress/vuepress v2). Even mdbook upgrades have been a pain since we need to merge down theme updates. I'd prefer to see something simple, e.g. (https://docs.racket-lang.org/guide/). What do we do in five years when Starlight is deprecated by another framework, and Astro is several major releases ahead, with breaking changes?
This is a very valid point, and a mark of a mature developer who has been bitten by frontend churn, and wants something stable, simple, reliable, and predictable.