It would be much better to use HTML for that and simply toggle the display/visibility of DOM elements via CSS or JS.
It would be much better to use HTML for that and simply toggle the display/visibility of DOM elements via CSS or JS.
- We want to generate HTML from our data (eg. database) - We want an interactive experience (eg. with toggling visibility)
You could argue that we should generate the HTML on the backend, but then you are still generating HTML, and now you have two systems that interact with the HTML instead of one.
Why in the heavens would you ever choose to use a templating library and blur the lines between content (user input) and UI structure? Why reinvent the control-flow wheel?
Templating represents programmers realizing that this newfangled browser thing can already parse HTML, and hey, can't we do something clever with that - sure, if we unnecessarily serialize to a string first, yes! No thank you.
But I can sympathise with where you're coming from, as I have not so fond memories of backbone + [insert templating library]. A lot the problems can be addressed through better tools & a pre compilation stage where the templates are transformed into JS & data input are escaped for security reasons. One example of this is Ember.js's HTMLbars which address basically all of what you just listed there.
edit: That said if for whatever reason I couldn't use Ember, I'd probably choose some flavour of JSX over most other templating libraries, lol
If you toggle visibility with CSS, you still have to put everything in the DOM. Sometimes, putting things in DOM can be very expensive. Consider a date picker, a fairly complicated thing with many sub-elements. If you have to put thousands of date pickers in the dom, that's going to take a lot of time. Especially if the user only sees one if they click on an event to edit it.