HTML First

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

I mean, I am a big SPA framework guy. That's pretty much the main thing I use, day-in, day-out, because most of the projects I'm working on are complex enough that simply hand-coding the entire UI will not work.

And, while only a minority of projects are that complex, those projects are the ones most developers are working on. Most other projects are probably better served with a wordpress install and a bit of theme customisation. Which means it's going to be a minority of developers who work with the very minimal things that are sufficient in these sorts of cases.

Another web development prophet with quick solutions for simple cases.

* For DOB, what you typically need looks more like three text boxes. That said, the text boxes need to be able to work together in terms of validation - the 31st of February 2015 is not a valid date! This is why it's better to think of this as a single form control with multiple input fields. Alternatively, I want something where I can pick the year first, but this typically leads to lots of scrolling.

* For adding an appointment, I probably want something closest to the conventional date picker, but even then, if I'm making an appointment for a group, I might still want additional information about when people are available displayed directly in the calendar view as I'm choosing a date.

* If I want to browse for the cheapest date, then I want a way of seeing all the dates available and the prices of those dates at the same time, meaning a relatively rich date picker control. If all I have is "next day"/"previous day", then I need to manually click around a lot to get good deals.

* If I want to select a range of dates, then I want a single control that allows me to select that range immediately, not having to open a "start" field and an "end" field separately. I also probably want multiple months visible, depending on how long my range is, so I can see the whole range at a glance without having to click back and forth between months.

* This is more subtle, but a hotel visit requires a range of dates, but a flight to and from the hotel requires two discrete dates, which might potentially be indicated with yet another date picker variant.

These are all flows that require me to pick a date, most of them from a calendar, and all of them could arguably be considered important enough for a native element (in the sense that I use all of these elements in my day-to-day web browsing). But they're all very different, require different interactions and content, and have subtly different purposes.

The style presented is far from the norm at the moment not just because of gate-keeping and over-engineering, but because web software is refactored and improved so many times over.

For example, only supports a weird set of child tags. Personally I like , but due to this constraint it is not always appropriate. Certain aspects of its native style cannot be controlled.

Many event handlers are awkward encode into onclick if not impossible.

"Naked" HTML requires a lot of boiler plate. The form helpers that are discouraged relate to validation, error reporting, form authorization, and localization. It's not an obfuscation layer.

The encouraged styles are easier on the eyes for now, but it's easy to imagine them developing into issues which would be the subject of some ticket, or else disappearing due to general improvement to the code base (DRY principles, SoC, UI touch ups, etc).