Every time something new is announced on HN, we get the same old "this name is already used" comments.
Unless there's a templating engine also called Zapper, or a major web framework called Zapper, something in the same space at least, I don't see the point.
> Zapper’s two biggest limitations are that it does not currently support conditional rendering or nested templates (like foreach loops over the elements of an interior list).
More context: "At the moment, Zapper’s two biggest limitations are that it does not currently support conditional rendering or nested templates (like foreach loops over the elements of an interior list). Zapper could be extended to support those things, I just haven’t implemented them yet. Due to the design of Zapper, those features should have effectively no performance impact on templates that choose not to use them, which is nice."
On the demo page, you might consider dropping the number of rows by default from 10,000 to 1,000. Though Zapper's rendering handles it very quickly, the browser struggles a bit to keep up in Chrome and FF. It gives a pretty snappy experience doing live-typing editing at 1,000 though.
It varies from computer to computer. I could definitely see an older/weaker computer struggling with rendering the output from 10k rows, even with the truncation I implemented, but I wanted it to render enough rows that it could actually measure how long it took with some accuracy by default.
The Spectre attack mitigations mean that browsers only provide 2ms to 3ms resolution on their JavaScript/WASM timers now, which makes the measurement accuracy very rough in WASM unless the operation being measured takes a few tens of milliseconds.
Basically, there's a disconnect between how fast Zapper's actually rendering the text string, and how fast your browser can deal with such a massive chunk of text actually being requested for display.
Zapper gets its job done in 40ms, but the browser.. doesn't.
Try dropping the number of rows - I had good luck with 1,000.
This is versus the rust implementation of Handlebars. I'm not sure what the internals of that look like (whether it complies templates to native code or what).
I do know that the JS version compiles templates directly into string concatenation, so I wonder how Zapper running as wasm compares to rendering a compiled handlebars template.
I would enjoy seeing that comparison too, but I have been too busy lately to put time into more comparisons.
If someone can show that the Rust implementation of handlebars is slower than the JavaScript one, that would be really fun and interesting to see on its own! I would imagine the Rust one is reasonably efficient, but HashMaps are tremendously slower than the fixed enums my code is generating at Rust compile time, and the Rust Handlebars implementation uses HashMaps extensively for substitutions.
I did a whole bunch of benchmarking of template engines, and even went as far as to write my own a few tears ago when mobile devices were slow and I was trying to eke out extra performance.
Turns out the bottleneck is almost never interpolating the template, it's the browser parsing/creating the resultant DOM. This is true with both the innerHTML and createElement approaches to constructing the DOM.
This is interesting. I am planning on writing a static site generator to help me learn Rust and was deciding on what template engine to use. I was going to chose Haml (and started on a Haml library) but I may end up going with Zapper.
> "Zapper’s two biggest limitations are that it does not currently support conditional rendering or nested templates."
Is it possible to do a partial (?), that is the concat'ed result of a foreach and then inject (?) that result (string) into the parent view (?)?
If this can he done securely then it seems to me your two limitations are not only solved, but force a better sense of structure on building with your tool.
22 comments
[ 2.9 ms ] story [ 60.4 ms ] thread[1] https://www.zapper.com/
https://en.wikipedia.org/wiki/NES_Zapper
Unless there's a templating engine also called Zapper, or a major web framework called Zapper, something in the same space at least, I don't see the point.
I wish this was added to the list of comment guidelines of things to avoid – one could argue it is a shallow dismissal.
https://en.wikipedia.org/wiki/Zapper:_One_Wicked_Cricket
Sounds useful.
There's no inherent reason those two features can't be supported, and I want to add support for them when I have some time.
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
On the demo page, you might consider dropping the number of rows by default from 10,000 to 1,000. Though Zapper's rendering handles it very quickly, the browser struggles a bit to keep up in Chrome and FF. It gives a pretty snappy experience doing live-typing editing at 1,000 though.
The Spectre attack mitigations mean that browsers only provide 2ms to 3ms resolution on their JavaScript/WASM timers now, which makes the measurement accuracy very rough in WASM unless the operation being measured takes a few tens of milliseconds.
Zapper gets its job done in 40ms, but the browser.. doesn't.
Try dropping the number of rows - I had good luck with 1,000.
This is versus the rust implementation of Handlebars. I'm not sure what the internals of that look like (whether it complies templates to native code or what).
I do know that the JS version compiles templates directly into string concatenation, so I wonder how Zapper running as wasm compares to rendering a compiled handlebars template.
If someone can show that the Rust implementation of handlebars is slower than the JavaScript one, that would be really fun and interesting to see on its own! I would imagine the Rust one is reasonably efficient, but HashMaps are tremendously slower than the fixed enums my code is generating at Rust compile time, and the Rust Handlebars implementation uses HashMaps extensively for substitutions.
Turns out the bottleneck is almost never interpolating the template, it's the browser parsing/creating the resultant DOM. This is true with both the innerHTML and createElement approaches to constructing the DOM.
Is it possible to do a partial (?), that is the concat'ed result of a foreach and then inject (?) that result (string) into the parent view (?)?
If this can he done securely then it seems to me your two limitations are not only solved, but force a better sense of structure on building with your tool.