No, the template is usually a static file that is read into memory and served over HTTP or locally if it's a JS only site. But before being served, it's being picked at via imperative operations. And if it's really bad, then when a user presses a button it triggers some event that actually statefully changes the view itself.
I don't see template operations as imperative, rather I see them as declarative: you write the HTML and declare lists/placeholders inside the HTML. You also don't generally do much with the data except insert it into HTML; the rest of the backend is responsible for fetching/etc the data.
Yeah, but the function itself doesn't return that view. The framework you're working in essentially composes the view based on the associated code and template. This is fundamentally different from just returning the view itself in the function. These are all declarative approaches, but leaving your view in code is a lot better.
Every template-based framework I've seen has involved a lot of magic, syntax and DSL. That's not to say that JSX isn't a DSL as well but you can return regular React.Elements just as easily. You shouldn't need to remember a unique expression system just to be able to conditionally render. The premise that you're just not doing much with the data except dumping it into HTML is less true the more complex your site becomes. Think of the loads of conditions and evaluations that happen when you go to your Facebook wall or friends list.
It's okay because despite JSX being a DSL you don't have to use it even though everyone does?
Your line of thought is a large part of why I prefer ClojureScript to Javascript for SPAs. With reagent your components just work like the language, with nothing particularly special to remember.
Surprisingly enough, I'm a clojure developer and I really do like the hiccup syntax in Reagent. I haven't had the courage to use it in anything professional yet though.
EDIT: To answer your question, I actually think that JSX is a downside to React. I get that it was needed to convince the web crowd to adopt the library, but we need to stop pretending like we're writing HTML. We're not. The framework will take our JSX and do whatever it wants to it. I wish we just treated the DOM like a compilation target. That's actually what I like about Flutter - it treats the view as a render target and not as a document that you write to. Flutter web actually uses the canvas API to draw actually. And because of this, you can define your View model in a much more sane way (while still being fast). E.g. Flutter's Layouts make much more sense than HTML and flexbox/grid. They managed to separate the layout from elements. https://docs.flutter.dev/development/ui/layout
Amrita for ruby. That was one of my favorite template frameworks. It parsed your HTML document as HTML and used element attributes to mark which elements corresponded to which keys in your data model. Incredibly simple and unreasonably powerful.
These days.. I just an Amrita like engine I've built myself and I just use <template> elements directly in the document. It only takes 40 lines of code to match child elements to data model items and fill in the template. Your browser already has a powerful parser and literal templates built in.. why invent a whole new language just for HTML templates?
I've never been able to fully apprehend the reasoning for JSX.
That is a usual way this is done but not what it means. In fact, HTML recently got a `<template>` tag which is definitely not a separate file or served separately. Vue.js also refers to the HTML-ish portion of a component as "template".
