Unrelated but I like the website, he minimized the css and placed it right in <style> tags. Presumably the idea was to have such minimal styling you don't need to load a second file. Clever
I appreciate their minimalism too, but with http2 and http3 isn't this an anti-pattern? The overhead of loading an additional file is negligible in http2/3, but inlining causes you to have to re-download the CSS on every page instead of benefiting from the browser's cache.
No because that additional CSS file can only be fetched after the initial HTML file has been fetched, not simultaneously; thus requiring another roundtrip to the server. (HTTP/2 Server Push promised otherwise but it was never implemented correctly.)
Latency being much more constraining than bandwidth, embedding a stylesheet that’s small is nearly always the correct tradeoff.
Zig really annoys me. On the one hand, it seems like a very good language that I would find highly useful. But on the other, everywhere you look they remind out "it's not 1.0 yet" so anything you write might just stop working. I can't see how this is anything short of saying "don't use the language because we don't guarantee that anything you write will compile in future".
Well it means that you can use the language if you are willing to rewrite some of your code from time to time because we don't guarantee backwards compatibility between updates. That's the nature of a work in progress project.
If you want to help us get faster to v1.0 consider donating :^)
Doing work on the Zig language would require writing more code than I would likely have to rewrite if I was to use it in the current state and fix the breaks. I want to use programming language without having to maintain it's compiler and without having the compiler devs periodically breaking my code. The fact that they haven't even outlined some subset of the language which is resistant to change basically means that all code written in it has maintenance requirements going forward. By contrast, I can write that same code in C and leave it for a while then have it all be fine when I come back.
That's all fair, it just means that it's a bit too early for you to use Zig then.
The project can't come out already at v1 out of thin air, so it's a matter of being patient and waiting for the people working on it to make enough progress.
In the end it seems that all the writing around Zig has correctly communicated to you the state of things :^)
I hope all of these one-person/small-team projects also have succession plans in place. This [1] article recently shared here describes how vim has survived after its creator’s death
Unrelated but I like the website, he minimized the css and placed it right in <style> tags. Presumably the idea was to have such minimal styling you don't need to load a second file. Clever
I appreciate their minimalism too, but with http2 and http3 isn't this an anti-pattern? The overhead of loading an additional file is negligible in http2/3, but inlining causes you to have to re-download the CSS on every page instead of benefiting from the browser's cache.
No because that additional CSS file can only be fetched after the initial HTML file has been fetched, not simultaneously; thus requiring another roundtrip to the server. (HTTP/2 Server Push promised otherwise but it was never implemented correctly.)
Latency being much more constraining than bandwidth, embedding a stylesheet that’s small is nearly always the correct tradeoff.
Thank you for this post, I enjoyed it.
I like these kinds of posts, about wholesome satisfying work
I found a similar feed to HN on https://bearblog.dev/ at https://bearblog.dev/discover/ that might be helpful for persons to find new posts that are interesting.
I'll add miniflux to the list. It's been my RSS aggregator for like 5~ years now: https://miniflux.app/
I'm currently looking for a synchronizing CalDAV service if anyone has suggestions.
Zig really annoys me. On the one hand, it seems like a very good language that I would find highly useful. But on the other, everywhere you look they remind out "it's not 1.0 yet" so anything you write might just stop working. I can't see how this is anything short of saying "don't use the language because we don't guarantee that anything you write will compile in future".
Well it means that you can use the language if you are willing to rewrite some of your code from time to time because we don't guarantee backwards compatibility between updates. That's the nature of a work in progress project.
If you want to help us get faster to v1.0 consider donating :^)
Doing work on the Zig language would require writing more code than I would likely have to rewrite if I was to use it in the current state and fix the breaks. I want to use programming language without having to maintain it's compiler and without having the compiler devs periodically breaking my code. The fact that they haven't even outlined some subset of the language which is resistant to change basically means that all code written in it has maintenance requirements going forward. By contrast, I can write that same code in C and leave it for a while then have it all be fine when I come back.
That's all fair, it just means that it's a bit too early for you to use Zig then.
The project can't come out already at v1 out of thin air, so it's a matter of being patient and waiting for the people working on it to make enough progress.
In the end it seems that all the writing around Zig has correctly communicated to you the state of things :^)
I hope all of these one-person/small-team projects also have succession plans in place. This [1] article recently shared here describes how vim has survived after its creator’s death
[1] https://thenewstack.io/vim-after-bram-a-core-maintainer-on-h...
https://mozberg.com — Minimalist News search
Related: “Fast Software, the Best Software” – https://news.ycombinator.com/item?id=20517144
>> Will Debian Linux ever try to put ads into any of its software? The concept is absurd
Ubuntu, on the other hand...
Debian certainly inherits ads in software from our upstreams, Firefox is a prime example. We inherit other similar issues from upstreams too.
https://wiki.debian.org/PrivacyIssues
A few others that come to mind:
- Write.as
- NewsBlur
- Overcast
I think [BearBlog](https://bearblog.dev) qualifies too