in defense of html
[hawk] consists of that [userspace] software which admits of
[ubiquitous html5 clients].
urbit precepts on “real software”
modern web development is not diamond perfect.
npm is malware, build systems suck, security is hard, & authentication is a hassle.
i agree.
but slow down a for second, there's a baby in that bathwater.
it turns out that html is a wonderful way of thinking about interfaces.
most interfaces are just arrangements of text, inputs, buttons, and media, nested within a visual tree structure.
my One Simple Trick to
“stop worring and love the browser”...
is to think not in html, but in the $manx.
the manx is a beautiful rendition of
The Associative Array: father of all data structures.
forget about the ugly angle brackets, and the wasteful characters of serialized XML.
none of that exists in the $manx. it's just another noun: easily programmable from within your hoon programs.
the ;form(method "post") -> redirect cycle is an intuitive programming pattern.
it allows your interface to “think” in the same semantics as your backend command interface.
this programming pattern is the same as:poke-ing with a card, then peek-ing the same location.
simply ignore the idea of client-side state and focus on building in the timeless and single-layered way.
aka, server-side rendering.
yes, there is network latency on all actions.
in the long run, we hope that local moons with automatic syncing will remove that latency from the user experience.
in the short run, patterns like htmx allow progressive enhancement of the
;form(method "post") -> redirect
cycle.it has proved sufficient for many classes of user-facing software.
yes. at some point of interface complexity you do need client-side state.
luckily, in the context of browsers, i believe web components actually solve this.
you can make DOM attribute APIs to stateful abstractions, and use them just like all the other html elements.
they do not muddy your “diamond perfect single layered manx”, and you don't need a build system.
yes and no.
i am quite interested in server rendering for native platforms.
i hope one day something comes along and replaces chromium... but when this replacement arrives, i'm positive that it too will support the mighty $manx.
but currently the browser has some huge structural advantages:
it is permissionless, unlike app stores
every modern device has a web browser
manx documents are simple to build and maintain (it can be as simple as markdown!)
web browsers allow users to think in terms of “tabs viewing into a namespace” as opposed to “applications, where there is only one of each”. this is necessary for multitasking, explorability, and full programmability.