glebm

Elias-Fano would probably be a better option here

*fully elastic

Using Typed Racket adds 7+ MiB to the binary.

While I agree with the overall sentiment, browsers like Dillon and Lynx don't even implement HTTP caching correctly (they cache everything regardless of the headers).

JavaScript is not their biggest problem, as they can plug in one of the existing engines (in fact one of the links forks does just that).

Freedom of speech does not cover incitement nor hate speech.

Perhaps from the implementation standpoint, but from the user standpoint it's second to none. For example, it's the only one I know that supports dual subtitles (--secondary-sid in mpv). For more advanced features, it also allows you to pass CLI flags to mpv, e.g. for things like `--video-stereo-mode=sbs2l` (subtitles and UI for 3D videos).

Also, enable "Run mpv in its own window" under Preferences -> Advanced. This removes all the issues caused by the default mode of embedding the mpv window (such as subtitles being on the video and not in the black bars).

Thank you for your work on mpv!

SMPlayer is a great frontend for mpv.

Roaming costs are price gouging, the associated costs of providing roaming are nowhere near.

I've played around with it. These CPUs are fast enough (certainly faster than Heroku and the like). However, ScaleWay still does not provide automated disk backups, and manual snapshot requires you to shut down the instance first, so I went back to Linode.

We've built the Thredded forums engine (https://thredded.org) with the same goals in mind. The entire CSS is 10KiB, JavaScript loads asynchronously and is optional.

> The "front page" with the list of existing boards is particularly bad

A possible solution: https://github.com/thredded/thredded/pull/525

What do you think?

Thank you for your feedback!

> It has a lot of whitespace [...]

Whitespace can be reduced across the board by adjusting a variable:

https://github.com/thredded/thredded/blob/1a60bcc7618270afeb...

For the homepage, I'm going to try removing the vertical spacing between the cards.

> on a desktop [...] maybe put the name besides the post instead of on top

Definitely going to try that!

> A lot of elements have dynamic positions (e.g. the date, the author) which makes it quite hard to quickly scan the overviews for them.

I didn't realize there is a use-case for scanning through these. No good ideas yet on how to improve this.

> Image support?

By default only externally referenced images are supported, but integrating with third-party uploading services is easy. For example, here is how to do it with Shubox.io:

https://shubox.io/blog/2016/08/05/how-thredded-uses-shubox

We wrote the Thredded forums engine focusing on these things:

1. Client-side performance. Little JavaScript and lean CSS. Even the KaTeX math plugin renders math server-side.

2. Clean but discoverable UI. The focus is content. Not a single dropdown nor a hamburger menu.

3. Extensible, but critical features are built-in to provide a foundation for plugins. Features such as notifications, moderation, permissions system, and full text search.

4. Pleasant on mobile for both browsing and content creation. This means a textarea instead of a rich text editor (by default).

5. Everything degrades gracefully when JavaScript is off. For example, preview-as-you-type becomes a "Preview" button if JavaScript is disabled.

6. The relational database for everything, including full text search. Data integrity is easy, no out-of-sync elasticsearch databases here. Runs on Postgres, MySQL, and SQLite.

Boring technology => easy to deploy and run in production.

The codebase is written in Ruby, has slowly developed over the years, and has extensive test coverage.

I am very curious to hear what you think, and whether you've ever felt a need for a forum like that.

> some instances of these decisions where it is doubtful that any linter would be able to lint it.

Such issues are rarely style issues. They are more in the design territory where the focus of code reviews should be.

> most linters for most languages are unable to do this,

In the long run improving the linter is better for everyone. The examples given by the OP as infeasible are feasible.

Focus on the design over trivial style issues. Your style guide should be 95% covered by the linter. If it isn't, fix your linter.

> Broadly missing a point

My points is: Underestimating static analysis will lead you to the wrong conclusions.

> These things can hardly be judged by an automatic process like linting

Both of these (if vs guard clause, loop vs each) are enforced by the Rubocop linter in Ruby.