The rendering reminds me of typeset math from the 60s. Not a fan.
Instead of trying to come up with a compromise on rendering, a better idea might be simply not rendering your entire blog on one page... A plain HTML page with svg images weighing in at a shocking 2.6MB is not gonna load “instantly” anyhow. You can keep the source in a single markdown file if you wish, but there’s no reason you can’t split up the posts during processing, and that’s a much easier technical problem than this math rendering compromise.
> The rendering reminds me of typeset math from the 60s
I'd like to congratulate the author on building something like this. It obviously serves a niche, and represents an approach to that is useful.
That said, there is a trade-off to giving up beautiful math rendering. Aesthetics in math does matter for all but the roughest of jots -- even if you never show your jots to anyone.
When I was in academia, I kept my jots in a single continuous LaTeX file. I was fluent in LaTeX so I could jot down math almost faster than I could write them down on paper (keyboard + LaTeX macros + rapid copy-paste of repeated structures helped -- you wouldn't believe how much time you can save by making say "\sum_i^n\sum_j^m" a macro in index-heavy fields like mine).
I threw snippets and stuff into it, and because it was so beautiful, I would regularly review it and coalesce new ideas from it. Also, for the kind of math I was doing, I needed more symbols and structures than was supported, so I had to pull in packages. But the result was a set of notes that, for me, was pleasant to use. Render time? 3s on avg.
Good typeset is important, even if only psychologically.
> Far more importantly, it provides spatio-temporal locality. I add things in chronological order to tbe blog, as I learn thing. If I need to recall something I had studied, go to that location in the blog based on a sense of when.
> When I do get to a location I want, the scrollbar gives me a sense of where I am in the file. this is important to me, since it hepls me reason spatially about what i know and what I've learnt. It's someting I love about books, and deeply miss when navigtaing the web.I'm determined to keep this spatio-temporal locality on my little slice of the internet.
And:
> I need a single file to edit, so I can rapidly jot down new ideas. This is the essence of why I'm able to log most of what I study: because it's seamless.
I really wish I _could_ get used to the usual way of doing things, but it just doesn't sit right with me, unfortunately.
I thought those are all about your single markdown source file, not the HTML output. Still, this may work well when the website is sitting on your local disk, but probably not so well when it’s served remotely, especially not when it grows to say 10MB.
I understand your intention, the non-linear hypertext affects cognitive abilities badly in many ways. But your approach has limits. You might have 9000 lines of text now, but any non-trivial corpus of knowledge will make things explode. You have to split the file at some point. Otherwise - in your analogy - you will not read a book, but a library in a linear fashion.
Obviously you should use whatever language you want on your projects, but in case you’re interested:
> unfortunately, asking rust to treat UTF-8 string as a "ball of bytes" is hard, when it's stupidly easy with C.
String::as_bytes seems pretty easy, and there are byte literals b'?' of type u8 and b"???" of type [u8]. You can avoid interacting with the UTF-8 types at all if you don’t want to.
> Plus, I wanted to use arena-style-allocation where I make huge allocations in one go and then don't think about memory, something that I don't have control over in Rust.
Perhaps the bumpalo and typed-arena crates would interest you.
Unfortunately `&[u8]` is missing a lot of convenience methods that are on `&str`. It is getting better over time but I have definitely encounter the problem before where I tried to switch some string-based code to byte-based and was disappointed by the missing functionality.
Specifically Chrome on Linux the GPU tile rendering is far slower than I can scroll, perhaps because some text blocks are large enough that the out-of-tile culling leaves too much work for each tile rendered?
Perhaps the custom font has something that really slows down rendering or something?
Just because the page is huge shouldn't theoretically make the top bit of the page load slowly... After all, the number of words on the screen for my GPU to render isn't higher just because the scrollbar is a mile long...
Practically, if the draw culling algorithm is bad, rendering will get slow, which looks like it might be happening here.
I like Knuth’s attempt at math typesetting much more, and
I think that we’d be in a better place right now if all web browsers supported Plain TeX out of the box.
I tried to partially bring the ecosystem of TeX to the Web via SVG[1] a while ago, but I really hope there is an alternative to TeX for the Web to avoid the hassle of conversion. Matthew Butterick's Pollen[2] seems to be a good start, but currently the ecosystem is too small. It needs some more attention.
You can render math statically with KaTeX and some standard static site-generator too. Here an example from my blog (using Pelican):
https://depot.traits.de/pages/2020/02/21-markdown-example.ht...