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.

> I haven't gotten around to using turbolinks but its strongly makes me question whether I should I stop using js frameworks all together and go full on into turbolinks and go back to a simpler time of rapid development.

Exactly this. It is still faster to build websites with Rails, mainly thanks to the maturity of the ecosystem, so I still use it when render-HTML-on-the-server fits the bill. And Turbolinks 5 is surprisingly snappy, here is a demo of a forums site that I've just deployed running vanilla Turbolinks 5: https://thredded.org/.

Another developer/contributor here! We'd love to answer your questions!

You might like Thredded then. It is somewhat similar to Discourse, but runs just off the database alone, including full text search, and it is a Rails Engine so can be seamlessly interated into an existing Rails app. https://github.com/thredded/thredded

Poedit looks great, but different from what i18n-tasks offers.

i18n-tasks is on the command line, easily extensible, with configuration that can be easily tailored to the app from data layer to usage search. It is also very easy to integrate it into the test suite.

The default data adapter supports YAML and JSON by default, more common in many web communities (rails, node) than .po.

Such keys are supported to a certain extent (e.g they won't be reported as unused). A runtime tool that tracks runtime misses to the store is a part of ruby i18n gem and many other environments already. I have found such keys to constitute a minority in most projects I've worked on.

As of a few days ago it is complete enough to compile bootstrap-sass :) https://github.com/hcatlin/libsass/issues/231#issuecomment-3...

Thank you for these great suggestions, please keep making them! Later I'll publish them as a coherent list here: http://blog.glebm.com/2013/10/21/exploring-math-without-a-te...

Thanks, so it's packing it not compressing, I have updated the article accordingly.

The times were consistent, clone the repo and run `rake bm` to try it. max-ziplist cannot be set to the order of millions, since redis does have to unzip it on every access and you wouldn't get any range lookup boost. You can implement this in redis lua if app layer separation is a concern.

Thanks, this is a good way to partition hashes, added link to the post. When applying compression to real-life redis data, I usually also get a ballpark of 50% savings.

Instead of serving all fonts to all browsers, which would be slow, you can serve different styles based on the user-agent.

The font URL is not requested until after the CSS containing it, so there should still be a (smaller) delay and FOUC. SPDY should be enabled for both screenshots in the article.

Thanks for the heads up, this looks OK to use on Android 4+ and iOS 6+, I've updated the post. Surprised to see 600ms for parsing a 20KB base64 on some older mobile browsers.

All submodule updates will be reflected in the parent log. The screenshots are tied to commits, so you get per-shot history, diffs and know which commits changed which files. Git would not be more efficient at storing most compressed image formats than the filesystem.