7 ms·

Not getting it tbh. Why would you go nuclear and develop a React or Vue app and then not actually use it on the browser side? For content-oriented websites ther

Not getting it tbh. Why would you go nuclear and develop a React or Vue app and then not actually use it on the browser side? For content-oriented websites there are much simpler workflows based on SGML and other classic markup processing and content management practices. I mean the point of "content-oriented" and web sites in general really is that an expert in the field, rather than a web developer, can achieve useful results as an author.

4m1rk 4y ago
I suppose it's just a different templating engine (plus some optional features for the client side). Probably as a front-end developer people are more familiar with that compared to Jinja for example? Though I think if the target is static web sites then it's simply overkill.
cercatrova 4y ago
Developer experience writing React is much nicer than using other markup languages. That's why I use it at least, the fact that it spits out a fully JS-free website at the end is the icing on the top.
- tshaddox 4y ago
  Nothing about the developer experience of React seems better than any old HTML template language (and hardly better even than plain HTML), if you're not doing any interactivity and are just going to render once and spit out the HTML.
  - cercatrova 4y ago
    Have you used React before? It's miles above HTML templating. I honestly don't use frameworks that have regular templating anymore, like Vue or Svelte.
    - acdha 4y ago
      Yes. JSX is nice for escaping by default but encourages total spaghetti coding hiding app logic in the templates and various footguns like non-standard attributes className and breaking id. Running it on the server side mitigates the React performance hit somewhat but the selling point is interactivity.
    - alanwreath 4y ago
      What are you referring to? I am unaware of what “regular” templating you’re referring to or what react is achieving that is not available or cumbersome under react or svelte. I mean if JSX is considered as something particularly powerful (not saying it does) doesn’t Vue actually do that https://vuejs.org/guide/extras/render-function.html https://vuejs.org/guide/extras/render-function.html ?
      - zdragnar 4y ago
        Think of JSX as a macro, rather than "regular" templating, which is typically string substitution. For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered. You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).
        ricardobeat 4y ago
        Some day we have to stop repeating this nonsense. JSX requires much more learning than simple templating, there is no inherent benefit. Even a simple conditional is more complex than your average template.
        4y ago
  - nsonha 4y ago
    > Nothing about the developer experience of React seems better than any old HTML template language Is that a joke? You get autocomplete from typescript and props to be fully typed functions, or any kind of object for that matter. That compares to autocomplete that's just some ad-hoc, bug ridden tools that locks you into some IDE or editor, and who cares because all the attributes have the same type (string) anyway.
- cutler 4y ago
  You have to be joking, surely? React/Vue as a mere static template languages? Dedicated static site frameworks such as Jekyll and Middleman are a much better experience. My favourite is still Perl's Template::Toolkit.
  - cercatrova 4y ago
    TypeScript, that's the differentiator. Having fully typed variables in the templates cannot be replicated in templating languages (well technically they might be able to but that's not as ergonomic as fact).
    - cutler 4y ago
      Talk about sledgehammer to crack a nut - honestly, why does anyone need type safety in a simple templating operation? Dynamic languages have their uses, you know. Type safety is a tool, not an ideology.
      - cercatrova 4y ago
        I basically never use dynamic languages anymore. If there aren't algebraic data types in a language I simply don't use it. Sometimes people think I'm exaggerating but it's truly great to use a language with ADTs that you get spoiled.
        cutler 4y ago
        So what do you use for shell scripting?
        cercatrova 4y ago
        I like using Nim or Rust, or TypeScript, depends on the script. If it's just a few lines, sure I'll write it in bash, but if it gets a little larger, I convert it into a real programming language.
- bryanrasmussen 4y ago
  and what's your experience writing other markup languages that you base this statement on? I can definitely agree it is nicer for a data intensive sites, and with effort can be made somewhat equivalent in most document heavy sites, but there are definitely some scenarios I've encountered where the match of technology to use case was disastrously not in React's favor. Specifically I can think of parts of the websites' functionality is editing highly technical structured data documents by highly trained domain experts. I mean basically where years of developer productivity was thrown down a React hole when it could have been months in SGML / XML based tooling for what was required. I can say that because I have built big solutions in both stacks, though.
  - cercatrova 4y ago
    I've used many, Handlebars, Pug, Vue's, Svelte's, Zola's, many. They're all somewhat similar in that they try to recreate loops and conditionals, all without strong type support unlike in JSX. I've never used SGML though, another commenter told me that it is more powerful.
chasingtheflow 4y ago
You get the speed of SSR but can sprinkle interactivity into the app using the same SPA style frameworks via isolated “islands”.
jen729w 4y ago
It might be all you know. I'm not a web dev by trade but I have a website for a hobby project. I had taught myself React thinking I might make an app. (I never did.) So now I want to maintain this thing on the side with not much effort using what I already know. And that keeps those skills fresh, which is great. I'm very interested in Astro.
manigandham 4y ago
Component-based UI frameworks and ecosystem has made building frontends much nicer, especially when you need some optional interactivity since you're already writing in JS. Having that productivity and flexibility without the SPA complexity and other JS cruft has real value.
- whostolemyhat 4y ago
  In that case, it'd be interesting to see the benefits of Astro vs something like Gatsby
  - lf-non 4y ago
    Frameworks like Gatsby didnt have any special support for interactive islands. You can choose to have: a. A completely static site with no frontend javascript and no client side hydration, or b. client hydration in which case all the components needed in the page will need to be loaded in the client. If you want something in between, ie. only some sections need to be interactive, it requires jumping through some hoops eg. creating separate webpack entrypoints that call ReactDOM.render for specific DOM nodes. It is doable but more work and maintenance effort. Astro simplifies handling for these kind of islands by using a server side templating language that is component aware and familiar to users already writing jsx.

4m1rk 4y ago

I suppose it's just a different templating engine (plus some optional features for the client side). Probably as a front-end developer people are more familiar with that compared to Jinja for example? Though I think if the target is static web sites then it's simply overkill.

cercatrova 4y ago

Developer experience writing React is much nicer than using other markup languages. That's why I use it at least, the fact that it spits out a fully JS-free website at the end is the icing on the top.

tshaddox 4y ago
Nothing about the developer experience of React seems better than any old HTML template language (and hardly better even than plain HTML), if you're not doing any interactivity and are just going to render once and spit out the HTML.
- cercatrova 4y ago
  Have you used React before? It's miles above HTML templating. I honestly don't use frameworks that have regular templating anymore, like Vue or Svelte.
  - acdha 4y ago
    Yes. JSX is nice for escaping by default but encourages total spaghetti coding hiding app logic in the templates and various footguns like non-standard attributes className and breaking id. Running it on the server side mitigates the React performance hit somewhat but the selling point is interactivity.
  - alanwreath 4y ago
    What are you referring to? I am unaware of what “regular” templating you’re referring to or what react is achieving that is not available or cumbersome under react or svelte. I mean if JSX is considered as something particularly powerful (not saying it does) doesn’t Vue actually do that https://vuejs.org/guide/extras/render-function.html https://vuejs.org/guide/extras/render-function.html ?
    - zdragnar 4y ago
      Think of JSX as a macro, rather than "regular" templating, which is typically string substitution. For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered. You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).
      - ricardobeat 4y ago
        Some day we have to stop repeating this nonsense. JSX requires much more learning than simple templating, there is no inherent benefit. Even a simple conditional is more complex than your average template.
        4y ago
- nsonha 4y ago
  > Nothing about the developer experience of React seems better than any old HTML template language Is that a joke? You get autocomplete from typescript and props to be fully typed functions, or any kind of object for that matter. That compares to autocomplete that's just some ad-hoc, bug ridden tools that locks you into some IDE or editor, and who cares because all the attributes have the same type (string) anyway.
cutler 4y ago
You have to be joking, surely? React/Vue as a mere static template languages? Dedicated static site frameworks such as Jekyll and Middleman are a much better experience. My favourite is still Perl's Template::Toolkit.
- cercatrova 4y ago
  TypeScript, that's the differentiator. Having fully typed variables in the templates cannot be replicated in templating languages (well technically they might be able to but that's not as ergonomic as fact).
  - cutler 4y ago
    Talk about sledgehammer to crack a nut - honestly, why does anyone need type safety in a simple templating operation? Dynamic languages have their uses, you know. Type safety is a tool, not an ideology.
    - cercatrova 4y ago
      I basically never use dynamic languages anymore. If there aren't algebraic data types in a language I simply don't use it. Sometimes people think I'm exaggerating but it's truly great to use a language with ADTs that you get spoiled.
      - cutler 4y ago
        So what do you use for shell scripting?
        cercatrova 4y ago
        I like using Nim or Rust, or TypeScript, depends on the script. If it's just a few lines, sure I'll write it in bash, but if it gets a little larger, I convert it into a real programming language.
bryanrasmussen 4y ago
and what's your experience writing other markup languages that you base this statement on? I can definitely agree it is nicer for a data intensive sites, and with effort can be made somewhat equivalent in most document heavy sites, but there are definitely some scenarios I've encountered where the match of technology to use case was disastrously not in React's favor. Specifically I can think of parts of the websites' functionality is editing highly technical structured data documents by highly trained domain experts. I mean basically where years of developer productivity was thrown down a React hole when it could have been months in SGML / XML based tooling for what was required. I can say that because I have built big solutions in both stacks, though.
- cercatrova 4y ago
  I've used many, Handlebars, Pug, Vue's, Svelte's, Zola's, many. They're all somewhat similar in that they try to recreate loops and conditionals, all without strong type support unlike in JSX. I've never used SGML though, another commenter told me that it is more powerful.

chasingtheflow 4y ago

You get the speed of SSR but can sprinkle interactivity into the app using the same SPA style frameworks via isolated “islands”.

jen729w 4y ago

It might be all you know. I'm not a web dev by trade but I have a website for a hobby project. I had taught myself React thinking I might make an app. (I never did.) So now I want to maintain this thing on the side with not much effort using what I already know. And that keeps those skills fresh, which is great. I'm very interested in Astro.

manigandham 4y ago

Component-based UI frameworks and ecosystem has made building frontends much nicer, especially when you need some optional interactivity since you're already writing in JS. Having that productivity and flexibility without the SPA complexity and other JS cruft has real value.

whostolemyhat 4y ago
In that case, it'd be interesting to see the benefits of Astro vs something like Gatsby
- lf-non 4y ago
  Frameworks like Gatsby didnt have any special support for interactive islands. You can choose to have: a. A completely static site with no frontend javascript and no client side hydration, or b. client hydration in which case all the components needed in the page will need to be loaded in the client. If you want something in between, ie. only some sections need to be interactive, it requires jumping through some hoops eg. creating separate webpack entrypoints that call ReactDOM.render for specific DOM nodes. It is doable but more work and maintenance effort. Astro simplifies handling for these kind of islands by using a server side templating language that is component aware and familiar to users already writing jsx.