[listenallyall]

> a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals

The more complex the business logic, and the more options there are, and the more it is expected to change, the more it benefits the development team to write that code in their language of choice on the backend, close to the data store(s), using native classes/objects -- rather than being forced to write it in JS/TS, serialize everything to/from JSON, reliant on magic under the hood to lay it out in the DOM, with more and more "state" necessary to be managed client-side.

[_gabe_]

> the more it benefits the development team to write that code in their language of choice on the backend

Why?

TS is maintainable and very pleasant to code in. Most people’s computers are way faster than making round trips to a server. You talk about serializing everything to/from JSON, but my phone can do that in milliseconds (if not faster). Compare that to 100-200ms of latency between a faraway server, and all of a sudden doing things client side makes sense.

Engineering is all about tradeoffs. I’m tired of people trying to make blanket statements like “React is always better”, or “SSR is always better”. It’s not, and we know it’s not. There are several successful, performant, maintainable apps written using React. There are plenty written using a backend framework and SSR too. Heck, there’s successes that use both!

The common denominators in the success stories? Competent engineers. And I expect a competent engineer can analyze requirements and determine what would be the best outcome for their target users. A booking site absolutely benefits from a front end framework that handles client side logic. It probably also benefits from a clever backend for processing the data after the user is finished with it. Let’s not pretend there’s a one sized solution that fits everything, because there isn’t.

[porker]

> Why?

A tangential answer (focusing on backend not language) is because I'm (we're) going to have to reproduce much of the fronted complexity of the business logic on the backend to validate what the frontend sends.

I'm mostly agreeing with you. I've built multiple web-platformed insurance systems and booking systems in the last decade and moved from fully server rendered pages to client rendered forms. The complexity increased with that change but as you highlight once it's done the ability to test different frontend flows is great.

But I'd like a way to share more of the business logic rather than writing it twice.

[listenallyall]

> Compare that to 100-200ms of latency between a faraway server

A complex booking engine like an airline or Stubhub needs constant, almost real-time connectivity with a database, otherwise you risk selling product at a stale price, double-selling, selling to an unauthenticated person, getting taxes and fees wrong, missing custom post-sale add-on opportunities, and lots of other potential problems. The client has to make a lot of network calls, so you're going to deal with latency, there's no client-side solution that avoids it without risking the issues above.

[_gabe_]

> almost real-time connectivity with a database

If only they actually worked like this. I’ve experienced, as I’m sure many other people have, problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails because I was too slow. It’s also much faster to only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page.

All that to say, there are tradeoffs. Finding the solution with the best latency and the best experience requires a careful analysis of all these details and figuring out which approach (or combination of approaches) solves that problem the most efficiently. Of course it’s not easy, but nothing you’ve said here indicates one solution would always outperform another solution.

[listenallyall]

> problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails

Because they are typically written using popular heavy frameworks! Big, expert teams of developers can't get it all bug-free and fast and smooth when working with them. Thank you for making my point better than I could.

> only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page

You have revealed by this statement that you have no idea how HTMX works. You are making an argument against something you've clearly never looked at.

[_gabe_]

I don’t understand why you’re bringing HTMX into this? This is a blog about HTML first, and the comment I originally responded too seemed to imply a more traditional MVC or SSR site was the way to go. It feels like you’re just searching for a “gotcha” argument at this point and not arguing in good faith.

My whole argument can be succinctly summed up by this comment from a different Hacker News user from when React was first announced:

> One of the biggest problems with the web platform is that we've spent the last 20 years trying to shim applications into a document framework. HTML was designed to help academics share research papers, not to replace native thick-client applications, yet that's the direction it's been evolving towards.

> I'm really happy to see Web Components (inc. Polymer, Angular, x-tags, and React) landing into HTML. If we accept that web apps != web pages at a spec level, hopefully we can build an awesome platform on which to create tools that leverage all the great parts of the web (linkable, available, auto-updating, device-agnostic) without the mess that we've made trying to make the web do something it wasn't designed for.[0]

This sentiment, after 10 years, is still spot on. The web isn’t academics sharing research papers anymore. Interactive web apps, whether you like it or not, require a ton of client side state management. React was developed to address concerns with managing that state and improving performance where HTML5 fell short. It still succeeds at that.

Of course, if you have a static site, don’t use React! But let’s not pretend there’s no use case for it either. There’s tradeoffs. And I’ll repeat that til the end of time. No matter what you choose, there’s tradeoffs.

[0]: https://news.ycombinator.com/item?id=5789055

[listenallyall]

> I don’t understand why you’re bringing HTMX into this?

Maybe because HTMX fits all the principles listed by the author? Or because it's specifically referenced in the article (3 times)?

[codeptualize]

How are you going to do the updates without FE logic? Refresh the page constantly?

The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.

You make a great point why we use client side solutions.

[listenallyall]

> How are you going to do the updates without FE logic? Refresh the page constantly? The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.

That's exactly why HTMX has gained immediate traction so quickly, it solves many of these exact problems elegantly and easily, much of the time without a single line of JS.