Interesting topic, and funny that I personally consider the text width and font size of danluu’s blog to be a “bug”. It is well known that we can read faster with narrower text columns (remember newspaper columns when they were printed on paper). This is why I always read this particular blog with Apple’s Reader mode, which renders the text using larger font and narrower width.
also reader on ios interprets it wrong as it picks up the first heading as the article’s title, and that makes me think that it could skip some content as it’s prone to do, so back to poorly readable layout I go.
That's a cop out in this specific instance: he knows the defaults are a bug, he can change it with maybe 2x lines of CSS, but he is blind to the fact that it's a bug.
After all, he is complaining about the defaults in other software, but he is blind to the defaults he presents the user.
There is no way to specify a good size in CSS - a size that looks good on current computers will be too big on old computers, and a size that looks good on old computers looks too small on current ones. Browsers and users are the ones who can fix this.
I think your knowledge of CSS might be outdated.
What's wrong with the following CSS snippet for example?
body {
max-width: 70ch; /* Limits the text column to a comfortable reading width */
margin: 0 auto; /* Centers the text column on large screens */
padding: 1.5rem; /* Prevents text from touching the edges on small/mobile screens */
line-height: 1.6; /* Gives the lines room to breathe */
}
> What's wrong with the following CSS snippet for example?
It doesn't achieve a reasonable readable font size which was presumably the goal. Your padding won't be the right size for all screens either. (And personally I hate excessive line height).
> respect the browser's default font size
The browser's defaults are also bad. But they shouldn't be. The browser is in a position to actually fix this; the webdev isn't.
The problem is you're imposing your own idiosyncratic preferences on strangers. Your "improvements" cost valuable screen space. I paid good money for my screen space and I don't appreciate designers unilaterally wasting it because they personally think it looks better. The decision of how much (if any) space to spend on padding should be made by the user.
The designers' job is good usability. Limiting line length is important, humans cannot deal well with extremely long lines of text. This is not a matter of taste.
There is no objective definition of "extremely long". Whatever value you choose will be incorrect for some readers. Therefore the correct place to set it is in the web browser's preferences (or the window manager if you prefer).
Useful things to know, but how do they undo a designer wasting my screen space? If you're going to tell me to learn something, it should be CSS. At least Firefox can still be configured to follow its traditional role as "user agent" and allow me to override the bad decisions of designers, by setting toolkit.legacyUserProfileCustomizations.stylesheets and editing chrome/userContent.css . But it would be convenient if more people used the default CSS like danluu.com .
Not sure, as I don't have any wasted screen space, due to the techniques mentioned above. On really bad sites I try reader view first, View/Page Style/No Style (on Firefox) second, and if that doesn't work I close the tab. Pretty rare though.
A website should be readable, even if the browser is set to fullscreen. It could be that the user is on a kiosk system where she can't resize the window or doesn't want to, just to improve legibility.
I’m doing rebasing a lot these days, especially since I started using gh stack. The main struggle I have with rebasing is for git to recognize that a branch has actually been merged when its commits have changed (e.g., if I forgot to delete the local branch with old commits and come back months later and trying to figure out if it was actually merged or not). My understanding is that this is nicer with jj when you work locally, but if you sync with GitHub, I think your still faced with the same problem, or?
What are people doing to workaround this? I’ve tried to ask LLMs, but the complexity is frankly a bit off putting (I don’t have the suggestions handy)
Don’t you have an id system, like an issue tracker? That’s your source of truth for change requests.
The common advice is to never have long standing branches for WIP. But if you do, squash it to have a small number of commits, then replay it on top of the default branch. The try to understand why there’s any diff or conflict (refactor, update to the design, code removal, was not merged at all,…). As I squash merge, I always remove the PR branch from the main repo. And I keep it for about a week on my local repo (In case the PR is reverted and I needed my drafting version of it).
The 24% more PRs was merged, not «landed». Presumably after human code review (but I didn’t check the paper…) Not sure about this particular study, but I «think» my own productivity (coding wise) has improved by more than 30%. In many ways I wouldn’t even have started on many of the things I’ve completed these last six months because I would have viewed their effort to be insurmountable within my time budget as a professor (with all my other duties).
Does anyone know how this compares to Supacode (https://supacode.sh)? I just started using Supacode a few days ago and have been enjoying it so far; it is based on libghostty.
Supacode is macOS only and is a terminal emulator itself. Herdr is cross-platform and is just a multiplexer. You can use it in any terminal emulator. If you want you can even run Herdr in Supacode
I’m in academia and I try to convert everyone I know… I only recently started using it for a few things, and I used Claude to do some pretty advanced stuff that I wouldn’t have ventured to even try with latex. That is, I think a lot of the relevant CTAN packages can be developed using LLMs more quickly than you might expect.
For next year, I plan to prepare a thesis template for our university and encourage students to try it instead of latex (most of our students use latex now).
I’ve been using Typst lately and it has been great. I’ve made an exam template for my university and made an export feature so that I could generate the exam in the json format that our online exam system (WISEflow) expects, with support for multiple choice and essay style questions.
It is so snappy and with great error messages. I encourage people to try it out. The typst tutorial is very approachable. Thanks to the Typst devs for this great piece of software.
I’ve been using Typst lately and it has been great. I’ve made an exam template for my university and made an export feature so that I could generate the exam in the json format that our online exam system (WISEflow) expects, with support for multiple choice and essay style questions.
It is so snappy and with great error messages. I encourage people to try it out. The typst tutorial is very approachable.
I should note, it's still not on par feature-wise compared to TeX ecosystem, but it gets there with incredible speed. As for UX - it beats anything TeX-based ten times over.
Currently experimental, but looks like the first Intel arch will arrive in the next release in about 3 months. They are also going to support a portable layer.
Wondering what people here think about the approach the Go team is taking; I think they would appreciate more eyeballs on their design. (I’m not competent in this space (yet))…
I think there will be a "portable" wrapper that will also support other architectures (arm, riscv, even wasm) in the future based on the Highway C++ library.
