4 ms·

Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with

Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with JSX as relatively light syntactic sugar on top) that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. Of course, using React has all the issues of SPAs, and trying to use something like Next seems somewhat fiddly due to keeping client-side and server-side state in sync and managing hydration. I'm entirely in favor of a framework that allows writing a server-rendered app with a decent templating language (and ideally a good path for writing client-side interactivity if I need it); it looks like Fresh might do that. I'd love to hear about other frameworks (JS/TS or otherwise, though I definitely prefer statically-typed languages) that match up with what I want, though.

qudat 4y ago
> that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. This is exactly what I find frustrating about go templating. I lose autocomplete and type hints.
- DylanSp 4y ago
  Same. I've also found .aspx templates in .NET to have similar issues, although those are more complicated with all the data binding functionality.
- zelphirkalt 4y ago
  Makes me think of Scheme and SXML, where you never leave the context of the language. Transfer that to something statically typed, and you would get what you want. Maybe something like that exists in Haskell or a similar language?
  - qudat 4y ago
    Tsx is the templating language that is also typescript. So the “controller” and the template are the same function.
    - zelphirkalt 4y ago
      So, if I throw `tsc` at the `.tsx` file, you are saying it will work, without any other library (only `npm install tsc`, nothing else allowed)? Don't you have to install additional frameworks, that work with tsx/jsx for that? Afaik `tsc` deals with `.ts` files and nothing else, making typescript and `tsx` actually 2 separate languages, as the name suggests "typescipt extended", but maybe I am wrong.
      - qudat 4y ago
        It’s baked into tsc: https://www.typescriptlang.org/docs/handbook/jsx.html https://www.typescriptlang.org/docs/handbook/jsx.html
        zelphirkalt 4y ago
        Hm: > TypeScript ships with three JSX modes: preserve, react, and react-native. These modes only affect the emit stage - type checking is unaffected. The preserve mode will keep the JSX as part of the output to be further consumed by another transform step (e.g. Babel). So the only non-React dependent mode would be "preserve", which just keeps it like it is. The other modes of compilation/output would need to be processed by React. On the other hand: OK, it can be processed by tsc, so technically, they have built-in some React support into TypeScript. Not sure I am a fan of such framework specific features in a compiler. Would have been nicer to have an actual standard for web components, which is not dictated by "this is how React does it" and which can be output without being framework specific. Then each framework can choose to interpret that output however it wants.
zelphirkalt 4y ago
> Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with JSX as relatively light syntactic sugar on top) that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. I get that. The thing is, that you are already using a "new language" when writing TSX/JSX/whatever. The philosophy of it does not even try to prevent you from making any mistakes. It is like in Python Mako vs Jinja2. In Mako you can run arbitrary Python code easily, so you need a lot of discipline to not screw up. In Jinja2 you are mostly just handing in the data to render the template, perhaps apply some filter or so. This help inexperienced developers to keep clear boundaries between the view layer and other layers. But with TSX/JSX/etc. all that is thrown out of the window again and people will do anything they want in a place, where there should be view code only. Whether I need to learn which elements can be inside which other elements in TSX/JSX, as it is not HTML + JS or anything and it does not allow mostly (!) arbitrary nesting like HTML, or I learn a templating language, which is more traditional ... I have to learn a new little language (perhaps DSL, or whatever one could call it) anyway. And with the swing back to server-side rendering, the question arises, whether we really should mix all that state and behavior together again and forget mostly about the lessons of the past.

qudat 4y ago

> that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. This is exactly what I find frustrating about go templating. I lose autocomplete and type hints.

DylanSp 4y ago
Same. I've also found .aspx templates in .NET to have similar issues, although those are more complicated with all the data binding functionality.
zelphirkalt 4y ago
Makes me think of Scheme and SXML, where you never leave the context of the language. Transfer that to something statically typed, and you would get what you want. Maybe something like that exists in Haskell or a similar language?
- qudat 4y ago
  Tsx is the templating language that is also typescript. So the “controller” and the template are the same function.
  - zelphirkalt 4y ago
    So, if I throw `tsc` at the `.tsx` file, you are saying it will work, without any other library (only `npm install tsc`, nothing else allowed)? Don't you have to install additional frameworks, that work with tsx/jsx for that? Afaik `tsc` deals with `.ts` files and nothing else, making typescript and `tsx` actually 2 separate languages, as the name suggests "typescipt extended", but maybe I am wrong.
    - qudat 4y ago
      It’s baked into tsc: https://www.typescriptlang.org/docs/handbook/jsx.html https://www.typescriptlang.org/docs/handbook/jsx.html
      - zelphirkalt 4y ago
        Hm: > TypeScript ships with three JSX modes: preserve, react, and react-native. These modes only affect the emit stage - type checking is unaffected. The preserve mode will keep the JSX as part of the output to be further consumed by another transform step (e.g. Babel). So the only non-React dependent mode would be "preserve", which just keeps it like it is. The other modes of compilation/output would need to be processed by React. On the other hand: OK, it can be processed by tsc, so technically, they have built-in some React support into TypeScript. Not sure I am a fan of such framework specific features in a compiler. Would have been nicer to have an actual standard for web components, which is not dictated by "this is how React does it" and which can be output without being framework specific. Then each framework can choose to interpret that output however it wants.

zelphirkalt 4y ago

> Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with JSX as relatively light syntactic sugar on top) that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. I get that. The thing is, that you are already using a "new language" when writing TSX/JSX/whatever. The philosophy of it does not even try to prevent you from making any mistakes. It is like in Python Mako vs Jinja2. In Mako you can run arbitrary Python code easily, so you need a lot of discipline to not screw up. In Jinja2 you are mostly just handing in the data to render the template, perhaps apply some filter or so. This help inexperienced developers to keep clear boundaries between the view layer and other layers. But with TSX/JSX/etc. all that is thrown out of the window again and people will do anything they want in a place, where there should be view code only. Whether I need to learn which elements can be inside which other elements in TSX/JSX, as it is not HTML + JS or anything and it does not allow mostly (!) arbitrary nesting like HTML, or I learn a templating language, which is more traditional ... I have to learn a new little language (perhaps DSL, or whatever one could call it) anyway. And with the swing back to server-side rendering, the question arises, whether we really should mix all that state and behavior together again and forget mostly about the lessons of the past.