3 ms·

This looks neat! What's the performance like? I thought about trying to build something similar but I figured performance would be awful if it was based on nai

This looks neat! What's the performance like? I thought about trying to build something similar but I figured performance would be awful if it was based on naive string appending. I presumed GC would dominate the runtime from allocating a thousand copies of half an HTML doc. Does this do any kind of memo-ization/caching? That's where I ultimately wanted to end up. I wanted the Page to use generics to pick a struct for the parameters used in building the HTML, and then maintain a cache mapping hashed inputs to already-built output. I never decided whether it was better to memo-ize the whole page as a template or memo-ize just the components so it could do partial re-renders. It's ideologically very similar to React

markusw 3y ago
Honestly, I don't know. I've never measured because it's never been a problem. Most of it is writing string literals to an io.Writer, no idea what the overhead is there. Could be fun to write some benchmarks. :) With regard to caching, I think I would opt for a solution at a different layer. For example, render the page and just cache the output in memcached, Redis or similar. Or just in memory maybe. As always, it depends.
- everforward 3y ago
  > With regard to caching, I think I would opt for a solution at a different layer. For example, render the page and just cache the output in memcached, Redis or similar. Or just in memory maybe. As always, it depends. I totally get that, it is dramatically simpler and it probably does well enough for most things. My theory was that you can effectively cache parts of a page, and then build pages out of the cache. Like if my page relies on a user ID and some kind of "is logged in" boolean, the "is logged in" parts have probably already been rendered before so we only have to dynamically render the parts that rely on this user ID (presuming we haven't seen this user ID and cached those parts already). Caching the whole page requires rendering both the user ID and the "is logged in" part, because it caches over the totality of the parameters. Now that I'm writing this out, it does seem a touch excessive lol. It's kind of like server side React, but I'd probably rather push that processing onto the client device because I don't pay for their CPU cycles.

markusw 3y ago

Honestly, I don't know. I've never measured because it's never been a problem. Most of it is writing string literals to an io.Writer, no idea what the overhead is there. Could be fun to write some benchmarks. :) With regard to caching, I think I would opt for a solution at a different layer. For example, render the page and just cache the output in memcached, Redis or similar. Or just in memory maybe. As always, it depends.

everforward 3y ago
> With regard to caching, I think I would opt for a solution at a different layer. For example, render the page and just cache the output in memcached, Redis or similar. Or just in memory maybe. As always, it depends. I totally get that, it is dramatically simpler and it probably does well enough for most things. My theory was that you can effectively cache parts of a page, and then build pages out of the cache. Like if my page relies on a user ID and some kind of "is logged in" boolean, the "is logged in" parts have probably already been rendered before so we only have to dynamically render the parts that rely on this user ID (presuming we haven't seen this user ID and cached those parts already). Caching the whole page requires rendering both the user ID and the "is logged in" part, because it caches over the totality of the parameters. Now that I'm writing this out, it does seem a touch excessive lol. It's kind of like server side React, but I'd probably rather push that processing onto the client device because I don't pay for their CPU cycles.