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.
> "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.
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.
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 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.
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.
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.
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."
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.
[+] [-] rhencke|7 years ago|reply
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.
[+] [-] cup-of-tea|7 years ago|reply
[+] [-] chiefalchemist|7 years ago|reply
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.
[+] [-] jetti|7 years ago|reply
[+] [-] pitaj|7 years ago|reply
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.
[+] [-] nicoburns|7 years ago|reply
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.
[+] [-] coder543|7 years ago|reply
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.
[+] [-] MR4D|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] simplify|7 years ago|reply
[+] [-] rhencke|7 years ago|reply
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.
[+] [-] TylerE|7 years ago|reply
[deleted]
[+] [-] coder543|7 years ago|reply
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.
[+] [-] mwerty|7 years ago|reply
[+] [-] codezero|7 years ago|reply
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
[+] [-] covermydonkey|7 years ago|reply
[1] https://www.zapper.com/
[+] [-] gtirloni|7 years ago|reply
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.
[+] [-] abiox|7 years ago|reply
https://en.wikipedia.org/wiki/Zapper:_One_Wicked_Cricket
[+] [-] c22|7 years ago|reply
https://en.wikipedia.org/wiki/NES_Zapper