[kellysutton]

The original post could have been a bit more precise on this point. Basically, this math assumes something where the server-provided data changes in concert with the frontend.

If we're using jsonapi, GraphQL, Thrift, or any other protocol that's not HTML, we need to do the following:

- Make the change on the server to support the new functionality. Deploy.

- Make the change on the client to adopt the new functionality. Deploy.

- Remove the old functionality from the server (optional)

Because the client is a separate application, it becomes riskier to deploy those changes together. I need to think about it more as a developer.

With server-authored HTML, this separate client + server deploy is not required.

[Lutger]

There are a couple of reasons this is not convincing either:

- Other factors can often dwarf the separate deployment overhead, especially given that the deployment steps are done so often it will force the team to make it efficient and get used to it.

- There is no hard requirement for separate deployment in the first place, if we are just talking about react / spa you can deploy it in a single step. (Not saying you should)

The point is: yes there is quite a lot of overhead. From separate deployments, from separate state management and I think the big ones are often having two different programming languages and having to align schema on frontend and backend. It is hard to deny this. But then saying that because of this overhead, these kinds of apps take 2x time to code implies denying there are benefits as well, that under given circumstances can outweigh the overhead.

I think it is more interesting to assume that in some cases the benefits outweigh the cost of the overhead, and in others they do not.

[leptons]

>With server-authored HTML, this separate client + server deploy is not required.

SSR has been a thing in react for a long time.

[runako]

If the app has a backend, aren't we still talking about modifying two distinct apps (React + backend app) vs a single one?

Obviously unless the team has committed to React SSR + React backend (is this common?)

[silversmith]

Not necessarily. Most of Rails+React apps I have worked on have had the frontend code live in the same repository, and get deployed during the same step.

Yes, you have to keep API compatibility in mind when doing changes, because long-lived sessions might still exist. But has not been that much of a big deal in my experience.

[erikerikson]

Not necessarily. We write Typescript for front and back ends, using statically rendered SolidJs, skipping SSR, and hosting the corresponding Typescript in Lambdas.

[runako]

Would love to hear more about the deployment for that.

[erikerikson]

CDK BucketDeployment to S3 fronted by CloudFront using a simple CloudFront function that redirects all paths to the index (main entry) file.

`aws s3 sync` could have been fine.

Was that the piece of deployment you were curious about? If not feel free to be more specific.

[runako]

It sounded like your app includes Lambdas as well? I assume there is another deployment pipeline for those?

Thanks!

[z33k]

The fashionable thing for a while now has been to write your react webapp as a single app. Here is one example of a "fullstack" react template: https://create.t3.gg/

[runako]

Interesting setup. Looks like getting to a zen state like this would have required them to migrate their backend from Rails to ts at some point. I can understand the engineering decision not to do that.

[bryanrasmussen]

yeah and it sort of sucks in comparison to most other server-authored HTML solutions, in this statement I am of course thinking of Next but I suppose various forms of suckage will be found in other solutions.

[zelphirkalt]

And to me both suck, compared to traditional template rendering like Jinja2 or Django Templates and those suck compared to SXML. React because of JSX and NextJS because of JSX and its assumptions about directory/file structure mapping to request routes, unless you change routing. JSX templates have that same feel, that PHP has from back in the day. Treating HTML as a string, implementing a wannabe HTML, that is not actually HTML, but slightly differen (for example the class attribute of HTML elements, or Fragment, <>) and enabling people to put JS logic inside the that string, mixing everything again, requiring to have a separate parser.

Separate parser is basically what Jinja2 has or other templating engines like Django templates. React could have used any templating engine that already existed.

But compare it to the elegance of SXML and treating HTML as the tree that is it, as structured data, enabling pattern matching on that, avoiding the need for a parser, and all other things that are in the language. Use. Structured. Data. It is so simple.

Mainstream frameworks got a lot to learn still. They are still on the Kindergarden level of treating HTML as a mere string for most parts.