4 ms·

I love that the pendulum is swinging back to file-based routing. It reminds me a lot of the simplicity of cgi and php scripts. I'm sure there's a point where

I love that the pendulum is swinging back to file-based routing. It reminds me a lot of the simplicity of cgi and php scripts. I'm sure there's a point where it explodes into a monster of complexity with enormous sites, but for everything smaller it's so much simpler and easier.

zelphirkalt 4y ago
Next (no pun intended) thing we will rediscover is using templating engines (only in JS or so), because we realize, that mixing state and behavior is a problem. Then we will have gone full circle, but probably with some unreasonable overhead as a result. Maybe the whole thing of rendering templates will somehow become a part of webpack and everyone will have to configure webpack. Good that classic web frameworks are still around and healthy, which have been rendering templates on the server side for a decade or so.
- DylanSp 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. 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
    > 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.

zelphirkalt 4y ago

Next (no pun intended) thing we will rediscover is using templating engines (only in JS or so), because we realize, that mixing state and behavior is a problem. Then we will have gone full circle, but probably with some unreasonable overhead as a result. Maybe the whole thing of rendering templates will somehow become a part of webpack and everyone will have to configure webpack. Good that classic web frameworks are still around and healthy, which have been rendering templates on the server side for a decade or so.

DylanSp 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. 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
  > 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.