There's nothing stopping an HTTP API from returning both HTML and JSON from the same endpoint. Just have the client send "text/html" or "application/json" in the Accept header, depending on what it needs.
One challenge is that JSON is for data and HTML is for UI. When a client gets JSON it can transform the data to make it ready for the UI. With HTML, the client is locked into the UI chosen by the server.
What if the client wants to render the output of an API in different ways depending on what screen is visible? If the server API outputs JSON, this is trivial. If it outputs HTML the client is stuck into rendering what the server gives it.
However it would make sense to have a separate json api for other applications. That way the html endpoints can change without without api versioning, perfectly matching whatever the gui needs.
There absolutely is, this is just extra cruft you need to maintain, and who says that the HTML is universal enough to be used everywhere? This is exactly where a front-end or a backend-for-frontend (BFF) makes sense.
No they are not as susceptible - auto updating dependencies, post install scripts and culture of thousands of crappy micro packages (like left-pad) is mainly a NPM issue.
DHH switched from Mac to Linux and is in the process of experimenting with his setup, but since he's famous within tech, it's getting a lot of attention. There's really nothing special about it.
Haven't "launchers" existed for decades at this point though? I remember Crunchbang (RIP) having something similar for example, and that must have been almost two decades ago at this point.
In my first job I had to work with healthcare software and it horrified me. There is a standard for interop, HL7, but every system implements HL7 in its own special way so there are "integration engines" to massage the data so that they all conform to the same standard.
The history of HL7 is kind of nuts. It was originally developed for copper wire communication in 1979. Formalization was ongoing until maybe the early 1990s and lots of proprietary usage arose, because back in the 1990s none of these systems really inter-operated and everything eventually ended up on paper. It wasn't until after the ACA that a lot of interoperability pushes really got going at scale. Before that you had a few Health Information Exchanges at state levels so there was usually a local standard if there was an HIE. HL7 FHIR is much more standardized now.
I wouldn't call any of it a grift. It's just old tech built for a fragmented archipelago of systems that didn't communicate. Also you can write a pretty good HL7v2 parser in an afternoon, I've written maybe 5 of them.
The koan that unlocked why healthcare technology is the way it is for me:
I was working on automating health insurance claims processing on a mainframe system.
In their key interface, a key form had 8 blanks for ICD codes. If more than 8 codes were needed, a child claim was created and linked to the parent claim.
This was a long project, so I was staring at this interface for months, as linked child claims made automation more complex than it needed to be. (E.g. if a parent claim had aged, been archived, and needed to be reloaded to active overnight before processing the child claim)
Finally, I started asking around. "This is a computer system. Why are there a finite number of fields for something that might need more?"
Nobody knew. Project continued. I continued asking different people.
Finally, I asked a guy who had been working in the industry since the 1960s...
"Oh, because that's how many fields there were on the paper version of the form that preceded the mainframe app."
Which seems insane, until you think it through. There were innumerable downstream processes of that paper form.
Changing the number of fields on the digital version would have cascaded that change downstream to all those processes. In the interest of rapid implementation, the optimal approach was to preserve everything about the form.
And then nobody had a reason to go to the bother to change it for the next 50 years. (And that was a process within a single company!)
But you can split these claims into child claims upon printing. That's the thing with good software, the user model and the internal implementation are completely orthogonal. I think a good example of this is postfix.
I'm not sure RCT ever had a modding community, but it's predecessor, Transport Tycoon Deluxe, did. TTDPatch[0] had several gameplay and quality of life improvements, but it was eventually superseded by OpenTTD[1].
The problem isn't trustworthiness, we know very well what's going on here, "privacy not included", the issue is that if another nation that's not friendly to you controls huge swathes of your infrastructure, they could use that access to cripple you should a "disagreement" occur.
With the kind of infrastructure that holds Chinese technology in the west, they could shut down entire power grids, bring roads to a stand still, shut down entire countries worth of networking, cellular networks and worse. This is leaving out the surveillance and data collection potential as it's not the topic at hand.
To be clear, my issue isn't with China specifically, but as a westerner, they're not a friendly nation (to mine).
The same of course applies the other way around, and I can imagine a scenario of other citizens sitting in their respective nation having this same conversation about western technology.
As an european, the US doesn't appear to be very friendly to me, or rather, their friendliness is conditional on the EU acting like a vassal state (or vassal federation). The current US administration doesn't even pretend like that's not the case, but past administrations acted like this as well.
China seems very much like a more straightforward and predictable trading partner.
Trade isn't really the concern I'm implying here. US isn't likely to initiate a "special military operation" without our (European's) borders, but China could certainly get ideas from a more local aggressor.
Whether or not that's likely is another story, but it's possibly a non-zero chance and handing over control of critical infrastructure should be a concern.
That's the implication I was making; I know they're Chinese that's why I raised them, my point is, people are buying them presumably on brand recognition (the exception in that list), which is beyond me because I would _not_ buy an MG (Chinese or otherwise).
While I agree that the value of LLMs is wildly overstated, I disagree that it is less useful than bitcoin mining, which is entirely useless. At least LLMs can produce usable output.
