4 ms·

I started as a front-end developer, so doing lots of Angular, React and Vue. But over the past few years I've transitioned back to plain HTML (or at least templ

I started as a front-end developer, so doing lots of Angular, React and Vue. But over the past few years I've transitioned back to plain HTML (or at least templating on the server side), and I find it so much more enjoyable and much faster to developer as well. I don't have to constantly switch between front-end/back-end, having to build APIs, just so that my single SPA can consume them. Although I really miss the flexibility of of React/Vue components that can take different parameters, and have rendering logic inside them. jinja2/pug and the likes, just don't have that.

crabmusket 4y ago
I really think components are an incredible innovation, and I'm constantly shocked that mainstream backend template systems don't have them. Some are beginning to, e.g Laravel's blade.
- zelphirkalt 4y ago
  What are the innovative parts of web components, which have no equivalent in lets say mainstream OOP, lumping state and behavior together?
  - crabmusket 4y ago
    Oh I didn't mean innovative in the broad software landscape. I may have spoken a bit too emphasically. I just meant to compare them to their direct competitors, e.g. Jinja style server side templating. The best part of component-based templating to me is not when it resembles OOP, but when it's functional. Components as functions with all that entails (scope, most significantly) is a step up from the very procedural, preprocessor-style template engines.
    - zelphirkalt 4y ago
      Hm. I see it exactly the opposite way: A template renders the same every time, given the same input. Rendering a template is like a function. It encourages people to put their logic elsewhere (separation of concerns) and first get the data they need, to only then render the template. Templates are merely views. A web component in contrast has internal state, which it mutates, or at least can have internal stage and often does have such. Also it relies on global state, which is accesses. It seems to me like a step down from preprocessed templates, because state and behavior are lumped together again and because of internal mutating state. The view layer is no longer cleanly separated. In practice the resulting DOM often is more convoluted and styles are defined in less obvious ways ultimately on the website. It makes writing user stylesheets and user scripts harder. You can re-use web components, but realistically every projects adapts or writes their own component anyway and you can only re-use for the same framework or one based on the framework, for which the component was written. Re-use of components seems even less than it was for "my classes from the other project" in OOP, because not only does one have language specific classes, but framework-family specific components. While not directly necessary for web components in general, I also find that syntax annoying, which mixes some kind of HTML look-alike with JS blocks inside of it. Kind of a reminder of PHP outputting HTML, which contains PHP blocks, which output JS, which modifies HTML. It is also annoying, because now I have to learn an HTML look-alike, which has new rules about what may be nested into what and those rules do not always make sense. I cannot nest as freely as in real HTML. What I write in a web component is not what ultimately gets output, but instead if will be translated at the end of the process. In a template I would simply write my HTML and compose them in such a way, that I have separate templates for semantically separate things, enabling re-use of templates. It is easy to do and the code is real HTML, no need for any indirection of translating a look-alike into ultimately HTML again. Seems to me, that many lessons of the past have been forgotten.
      - woutr_be 4y ago
        This doesn't seem like a fair comparison, when I mentioned components, I wasn't referring to their state, or two-way bindings, I was purely referring to their templating methods. This also leads into my point about the syntax, they write just like regular HTML, just with a custom tag and custom data attributes. Since I'm already writing HTML, I really prefer this. My point about JSX was also mainly related to that, since I'm already using TypeScript, I can just continue to use that in my rendering logic. Or at least, the logic reads like any programming language, not this psuedo-like syntax. Jinja/pug/handlebars and the likes, have their own templating language, which is always different from the programming language you're already using. And I personally don't find HTML that difficult to write, that I need to compile into it. So what I would like to see, is a templating language (such as Jinja/pug/handlebars), but that uses plain HTML, with the ability to use JSX and write custom components (that will just output plain HTML). I don't need any of the state mangement or two-way bindings.
        zelphirkalt 4y ago
        In many Scheme dialects there is SXML, which looks just the same as normal Scheme code and actually also is normal Scheme code. You simply nest HTML tag names like so: `(div (p "here is my text" (span ,(calling-my-own-function-for-some-text)))) This builds up a tree structure, which ultimately gets fed into some function, which transforms it into an HTML string, which is send to the client. Before the transformation you can treat the tree just like any other tree, avoiding to have to parse anything. You can for example recursively search for something to pattern match on and transform in arbitrary ways. The thing is, that it requires the developer to have some disciplin to divide view from the logic behind it. Simply make a folder called "templates" and put your Scheme files containing SXML stuff in there. For disciplined developers, this works well. In Scheme this works well, compared to for example PHP outputting HTML, because Scheme code in general has a tree structure already and as such an expression can be transformed into an HTML document. No need for any additional language like a templating language, but also not making the mistake to treat HTML as mere string, like PHP does. JSX kind of treats its HTML-look-alike as a string as well, kind of. In the code you have a backstring wrapped string, which is processed later. There needs to be an additional parser for that, which performs the magic behind the scenes and checks the nesting of elements, allowing JS blocks inside that "template string". No such additional parsing is needed in SXML. Given the mere string before processing it into some internal tree, which is hidden away in the machinery processing JSX, I cannot simply transform the tree it represents, because it is merely a string. I would need to make use of JSX processing tooling, to get an actual tree and work with that. That might be possible. The only advantage JSX has over SXML is not one, which stems from JSX itself, but from the fact, that JS runs in the browser and as such can run on the client side. If that were not the case, JSX would simply be worse in every way, forcing people to learn another language. Another language, because what one types in JSX template strings is not actual HTML, but something else, which has new rules about what elements exist, how elements can be structured, what attributes exist ("class" ...) and how elements can be nested, without receiving a type error. All that could be avoided, if we had something as elegant as SXML in JS. However, I am not sure, whether it is even possible to have something like SXML in JS. How would one go about quasi-quoting and unquoting? I don't know. I would actually prefer to simply use JS objects to express the HTML document, so that I can work with them like with any tree. There could be magical attributes, which you can assign some closure to, so that it gets the dynamic behavior like in JSX. Not sure any framework has gone that way. It would be cleaner than inventing an HTML-look-alike and it would allow for more efficient processing, since it does not have to be parsed again, before outputting HTML.
- dsego 4y ago
  I feel the same. I tried playing around with server-side JSX in Deno and HTMX. JSX seems like a good solution for backend components, esp. since it's more suitable for reusable smart components with logic or data fetching and not just "dumb" templates. https://github.com/dsego/ssr-playground/ https://github.com/dsego/ssr-playground/
seanwilson 4y ago
> Although I really miss the flexibility of of React/Vue components that can take different parameters, and have rendering logic inside them. jinja2/pug and the likes, just don't have that. What is Jinja missing here when it has variables and logic in templates? You mean the rendering logic is less powerful so the template file alone can't encapsulate all the logic?
- woutr_be 4y ago
  I do find the rendering logic less powerful, I know that in Jinja you have includes and macros, but I miss being able to extract specific logic to methods. I also like being able to use the language that I'm working in, to write extra logic in my templates, in React that would be JSX. With Jinja it's this "weird" syntax that's completely different from Python and HTML. If that makes sense.

crabmusket 4y ago

I really think components are an incredible innovation, and I'm constantly shocked that mainstream backend template systems don't have them. Some are beginning to, e.g Laravel's blade.

zelphirkalt 4y ago
What are the innovative parts of web components, which have no equivalent in lets say mainstream OOP, lumping state and behavior together?
- crabmusket 4y ago
  Oh I didn't mean innovative in the broad software landscape. I may have spoken a bit too emphasically. I just meant to compare them to their direct competitors, e.g. Jinja style server side templating. The best part of component-based templating to me is not when it resembles OOP, but when it's functional. Components as functions with all that entails (scope, most significantly) is a step up from the very procedural, preprocessor-style template engines.
  - zelphirkalt 4y ago
    Hm. I see it exactly the opposite way: A template renders the same every time, given the same input. Rendering a template is like a function. It encourages people to put their logic elsewhere (separation of concerns) and first get the data they need, to only then render the template. Templates are merely views. A web component in contrast has internal state, which it mutates, or at least can have internal stage and often does have such. Also it relies on global state, which is accesses. It seems to me like a step down from preprocessed templates, because state and behavior are lumped together again and because of internal mutating state. The view layer is no longer cleanly separated. In practice the resulting DOM often is more convoluted and styles are defined in less obvious ways ultimately on the website. It makes writing user stylesheets and user scripts harder. You can re-use web components, but realistically every projects adapts or writes their own component anyway and you can only re-use for the same framework or one based on the framework, for which the component was written. Re-use of components seems even less than it was for "my classes from the other project" in OOP, because not only does one have language specific classes, but framework-family specific components. While not directly necessary for web components in general, I also find that syntax annoying, which mixes some kind of HTML look-alike with JS blocks inside of it. Kind of a reminder of PHP outputting HTML, which contains PHP blocks, which output JS, which modifies HTML. It is also annoying, because now I have to learn an HTML look-alike, which has new rules about what may be nested into what and those rules do not always make sense. I cannot nest as freely as in real HTML. What I write in a web component is not what ultimately gets output, but instead if will be translated at the end of the process. In a template I would simply write my HTML and compose them in such a way, that I have separate templates for semantically separate things, enabling re-use of templates. It is easy to do and the code is real HTML, no need for any indirection of translating a look-alike into ultimately HTML again. Seems to me, that many lessons of the past have been forgotten.
    - woutr_be 4y ago
      This doesn't seem like a fair comparison, when I mentioned components, I wasn't referring to their state, or two-way bindings, I was purely referring to their templating methods. This also leads into my point about the syntax, they write just like regular HTML, just with a custom tag and custom data attributes. Since I'm already writing HTML, I really prefer this. My point about JSX was also mainly related to that, since I'm already using TypeScript, I can just continue to use that in my rendering logic. Or at least, the logic reads like any programming language, not this psuedo-like syntax. Jinja/pug/handlebars and the likes, have their own templating language, which is always different from the programming language you're already using. And I personally don't find HTML that difficult to write, that I need to compile into it. So what I would like to see, is a templating language (such as Jinja/pug/handlebars), but that uses plain HTML, with the ability to use JSX and write custom components (that will just output plain HTML). I don't need any of the state mangement or two-way bindings.
      - zelphirkalt 4y ago
        In many Scheme dialects there is SXML, which looks just the same as normal Scheme code and actually also is normal Scheme code. You simply nest HTML tag names like so: `(div (p "here is my text" (span ,(calling-my-own-function-for-some-text)))) This builds up a tree structure, which ultimately gets fed into some function, which transforms it into an HTML string, which is send to the client. Before the transformation you can treat the tree just like any other tree, avoiding to have to parse anything. You can for example recursively search for something to pattern match on and transform in arbitrary ways. The thing is, that it requires the developer to have some disciplin to divide view from the logic behind it. Simply make a folder called "templates" and put your Scheme files containing SXML stuff in there. For disciplined developers, this works well. In Scheme this works well, compared to for example PHP outputting HTML, because Scheme code in general has a tree structure already and as such an expression can be transformed into an HTML document. No need for any additional language like a templating language, but also not making the mistake to treat HTML as mere string, like PHP does. JSX kind of treats its HTML-look-alike as a string as well, kind of. In the code you have a backstring wrapped string, which is processed later. There needs to be an additional parser for that, which performs the magic behind the scenes and checks the nesting of elements, allowing JS blocks inside that "template string". No such additional parsing is needed in SXML. Given the mere string before processing it into some internal tree, which is hidden away in the machinery processing JSX, I cannot simply transform the tree it represents, because it is merely a string. I would need to make use of JSX processing tooling, to get an actual tree and work with that. That might be possible. The only advantage JSX has over SXML is not one, which stems from JSX itself, but from the fact, that JS runs in the browser and as such can run on the client side. If that were not the case, JSX would simply be worse in every way, forcing people to learn another language. Another language, because what one types in JSX template strings is not actual HTML, but something else, which has new rules about what elements exist, how elements can be structured, what attributes exist ("class" ...) and how elements can be nested, without receiving a type error. All that could be avoided, if we had something as elegant as SXML in JS. However, I am not sure, whether it is even possible to have something like SXML in JS. How would one go about quasi-quoting and unquoting? I don't know. I would actually prefer to simply use JS objects to express the HTML document, so that I can work with them like with any tree. There could be magical attributes, which you can assign some closure to, so that it gets the dynamic behavior like in JSX. Not sure any framework has gone that way. It would be cleaner than inventing an HTML-look-alike and it would allow for more efficient processing, since it does not have to be parsed again, before outputting HTML.
dsego 4y ago
I feel the same. I tried playing around with server-side JSX in Deno and HTMX. JSX seems like a good solution for backend components, esp. since it's more suitable for reusable smart components with logic or data fetching and not just "dumb" templates. https://github.com/dsego/ssr-playground/ https://github.com/dsego/ssr-playground/

seanwilson 4y ago

> Although I really miss the flexibility of of React/Vue components that can take different parameters, and have rendering logic inside them. jinja2/pug and the likes, just don't have that. What is Jinja missing here when it has variables and logic in templates? You mean the rendering logic is less powerful so the template file alone can't encapsulate all the logic?

woutr_be 4y ago
I do find the rendering logic less powerful, I know that in Jinja you have includes and macros, but I miss being able to extract specific logic to methods. I also like being able to use the language that I'm working in, to write extra logic in my templates, in React that would be JSX. With Jinja it's this "weird" syntax that's completely different from Python and HTML. If that makes sense.