# htx

first of all, what is `htx`?

I've spent a long time thinking about the fact that there's really not even
hobbyist alternatives to the Web other than technologies which predate it
(e.g. Gopher). Nobody has really tried to make a zero-deploy app runtime or a
distributed hypertext system that's not built ontop of the full web stack, as
far as I can tell.

There's pretty good reasons I think that's the case. It's a futile effort,
for one: the Web is so deeply entrenched and has such powerful network
effects, it's hard to imagine anything meaningfully displacing it. But I
think there's a place for a simpler system and experiments around different
ways of designing systems like it, so I'm making a hobbyist hypertext system
for my own entertainment purposes.

I want to experiment with the following ideas:

- Immediate mode rendering
- Using a real machine code ISA for client side code execution
- A massively simplified document format

A one sentence summary would be: I want to make something dramatically
simpler than the Web, but still useful.

# Values

- Use existing components to rapidly prototype, but limit their scope. Ideal
  candidates for this:
  - Vector graphics drawing (Skia)
  - Text layout and shaping (Skia/HarfBuzz)
  - CPU emulation (riscv-rust)
  - Network communication (tonic/reqwest/hyper)

These components should not be directly exposed to the "userspace" of the
hypertext system: some of them are big and complicated (Skia), some of them
are immature (riscv-rust), and, well, ok, I think it's OK to expose HTTP. Out
of all the Web technologies, HTTP is both the most entrenched and has the
most quality: it really works well.

- Don't worry too much about security. That's not to say that security is
  unimportant, design for security matters, but there's an infinite rabbit hole
  of mitigations and defense in depth that a real production system needs, and
  that's not really the point: that's a matter of labor. It's more important to
  prove out the conceptual model than to develop a fully productionized
  sandboxed multi-process implementation, for example.
- Prefer simplicity over functionality. This needs to work as a hobby
  project; if it gets too ambitious it'll never get off the pad. Prefer
  simple and _general_ features, with high leverage.
- Get something functioning fast and iterate on it, instead of trying to
  build "the right thing."