Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UI vs. API. vs. UAI

joshbeckman.org

Post reply on HN
Print view View original

41–50 of 54 posts

Re: UI vs. API. vs. UAI

#41

Post by mort96 »

JimDabell wrote: post #37
mort96 wrote: post #13

Earlier quoted context omitted.

I'm not sure it's possible to have a technology that's user-facing with multiple competing implementations, and not also, in some way, "liberal in what it accepts". Back when XHTML was somewhat hype and there were sites which actually used it, I recall being met with a big fat "XML parse error" page on occasion. If XHTML really took off (as in a significant majority of web pages were XHTML), those XML parse error pag…

> If XHTML really took off (as in a significant majority of web pages were XHTML), those XML parse error pages would become way more common This is not true because you are imagining a world with strict parsing but where people are still acting as though they have lax parsing. In reality, strict parsing changes the incentives and thus people’s behaviour. This is really easy to demonstrate: we already have a world wit…

> This is not true because you are imagining a world with strict parsing but where people are still acting as though they have lax parsing. In reality, strict parsing changes the incentives and thus people’s behaviour.

Dude I lived in that world. A fair amount of developers explicitly opted into strict parsing rules by choosing to serve XHTML. And yet, those developers who opted into strict parsing messed up their XML generation frequently enough that I, as an end user, was presented with that "XML Parse Error" page on occasion. I don't understand why you'd think all developers would stop messing up if only strict parsing was hoisted upon everyone rather than only those who explicitly opt in.

> In your hypothetical world, they are making that syntax error… and just deploying it anyway.

No, they're not. In my (non-hypothetical, actually experienced in real life) world of somewhat wide-spread XHTML, I'm assuming that developers would make sites which appeared to work with their test content, but would produce invalid XML in certain situations with some combination of dynamic content or other conditions. Forgetting to escape user content is the obvious case, but there are many ways to screw up HTML/XHTML generation in ways which appear to work during testing.

> We have strict syntax almost everywhere. How often do you see a Python syntax error in the backend code?

Never, but people don't dynamically generate their Python back-end code based on user content.

> How often do you run across an SVG that fails to load because of a syntax error?

Never, but people don't typically dynamically generate their SVGs based on user content. Almost all SVGs out there are served as static assets.

Re: UI vs. API. vs. UAI

#42

Post by Mikhail_Edoshin »

mort96 wrote: post #13
showerst wrote: post #7

I really vehemently disagree with the 'feedforward, tolerance, feedback' pattern. Protocols and standards like HTML built around "be liberal with what you accept" have turned out to be a real nightmare. Best-guessing the intent of your caller is a path to subtle bugs and behavior that's difficult to reason about. If the LLM isn't doing a good job calling your api, then make the LLM get smarter or rebuild the api, don…

I'm not sure it's possible to have a technology that's user-facing with multiple competing implementations, and not also, in some way, "liberal in what it accepts". Back when XHTML was somewhat hype and there were sites which actually used it, I recall being met with a big fat "XML parse error" page on occasion. If XHTML really took off (as in a significant majority of web pages were XHTML), those XML parse error pag…

I remember "HTML 5 W3C Valid" buttons, proudly displayed by web pages. This was considered cool, so why doing the same for XHTML wouldn't be same?

Re: UI vs. API. vs. UAI

#43

Post by JimDabell »

mort96 wrote: post #41
JimDabell wrote: post #37

Earlier quoted context omitted.

> If XHTML really took off (as in a significant majority of web pages were XHTML), those XML parse error pages would become way more common This is not true because you are imagining a world with strict parsing but where people are still acting as though they have lax parsing. In reality, strict parsing changes the incentives and thus people’s behaviour. This is really easy to demonstrate: we already have a world wit…

> This is not true because you are imagining a world with strict parsing but where people are still acting as though they have lax parsing. In reality, strict parsing changes the incentives and thus people’s behaviour. Dude I lived in that world. A fair amount of developers explicitly opted into strict parsing rules by choosing to serve XHTML. And yet, those developers who opted into strict parsing messed up their XM…

> Dude I lived in that world. A fair amount of developers explicitly opted into strict parsing rules by choosing to serve XHTML.

No they didn’t, unless you and I have wildly different definitions of “a fair amount”. The developers who did that were an extreme minority because Internet Explorer, which had >90% market share, didn’t support application/xhtml+xml. It was a curiosity, not something people actually did in non-negligible numbers.

And you’re repeating the mistake I explicitly called out. Opting into XHTML parsing does not transport you to a world in which the rest of the world is acting as if you are in a strict parsing world. If you are writing, say, PHP, then that language was still designed for a world with lax HTML parsing no matter how you serve your XHTML. There is far more to the world than just your code and the browser. A world designed for lax parsing is going to be very different to a world designed for strict parsing up and down the stack, not just your code and the browser.

> I'm assuming that developers would make sites which appeared to work with their test content, but would produce invalid XML in certain situations with some combination of dynamic content or other conditions. Forgetting to escape user content is the obvious case, but there are many ways to screw up HTML/XHTML generation in ways which appear to work during testing.

Again, you are still making the same mistake of forgetting to consider the second-order effects.

In a world where parsing is strict, a toolchain that produces malformed syntax has a show-stopping bug and would not be considered reliable enough to use. The only reason those kinds of bugs are tolerated is because parsing is lax. Where is all the JSON-generating code that fails to escape values properly? It is super rare because those kinds of problems aren’t tolerated because JSON has strict parsing.

Re: UI vs. API. vs. UAI

#44

Post by DrScientist »

mort96 wrote: post #41
JimDabell wrote: post #37

Earlier quoted context omitted.

> If XHTML really took off (as in a significant majority of web pages were XHTML), those XML parse error pages would become way more common This is not true because you are imagining a world with strict parsing but where people are still acting as though they have lax parsing. In reality, strict parsing changes the incentives and thus people’s behaviour. This is really easy to demonstrate: we already have a world wit…

> This is not true because you are imagining a world with strict parsing but where people are still acting as though they have lax parsing. In reality, strict parsing changes the incentives and thus people’s behaviour. Dude I lived in that world. A fair amount of developers explicitly opted into strict parsing rules by choosing to serve XHTML. And yet, those developers who opted into strict parsing messed up their XM…

> Never, but people don't dynamically generate their Python back-end code based on user content.

Perhaps not much in the past - but I suspect with Agentic systems a lot more in the future - are you suggesting relaxing the Python syntax to make it easier for auto-generated code to 'run'?

Re: UI vs. API. vs. UAI

#45

Post by lucideer »

integralid wrote: post #22
lucideer wrote: post #17

Earlier quoted context omitted.

History has gone the way it went & we have HTML now, there's not much point harking back, but I still find it very odd that people today - with the wisdom of foresight - believe that the world opting for HTML & abandoning XHTML was the sensible choice. It seems odd to me that it's not seen as one of those "worse winning out" stories in the history of technology, like betamax. The main argument about XHTML not being "…

>The whole story of Is that really the story? I think it was more like "backward compatible solution soon about more pure, theoretically better solution" There's enormous non-xhtml legacy than nobody wanted to port. And tooling back in the day didn't make it easy to write correct xhtml. Also like it or not, HTML is still written by humans sometimes, and they don't like parser blowing up because of a minor problem. Es…

> There's enormous non-xhtml legacy than nobody wanted to port.

This is a fair argument if content types were being enforced but XML parsing was opt-in (for precisely this reason).

> And tooling back in the day didn't make it easy to write correct xhtml.

True. And instead of developing such tooling, we decided to boil the ocean to get to the point where tooling today doesn't make it any easier to lint / verify / validate your HTML. Mainly because writing such tooling to a non-strict target like HTML is a million times harder than to a target with strict syntax.

A nice ideal would've been IDEs & CI with strict XHTML parsers & clients with fallbacks (e.g. what Chromium eventually implemented)

Re: UI vs. API. vs. UAI

#46

Post by dathinab »

wvenable wrote: post #35
dathinab wrote: post #28

Earlier quoted context omitted.

> progressive enhancement possible no not at all extensible isn't the same as lenient having a Content-Type header where you can put in new media types (e.g. for images) once browsers support it is extensibility sniffing the media type instead of strictly relying on the Content-Type header is leniency and had been the source of a lot of security vulnerabilities over the years or having new top level JS object exposin…

> no not at all extensible isn't the same as lenient I never said it was. But lenient provides for extensibility that isn't planned for. The entire evolution of the web is based on that. Standards that were too strict or too inflexible have been long forgotten by history. That's not to say that isn't the source of security vulnerabilities and bugs but that doesn't negate the point.

that is just not true

web is mostly based on standards which always have been supper lenient, messy und had massive gaps of unclearity mainly because it was more "lets somehow standarize what browsers already do" then anything else

through I guess you could say that the degree to which you can polyfill JS is more lenient then many thing is good and that did help with extensibility,

Re: UI vs. API. vs. UAI

#47

Post by mort96 »

JimDabell wrote: post #43
mort96 wrote: post #41

Earlier quoted context omitted.

> This is not true because you are imagining a world with strict parsing but where people are still acting as though they have lax parsing. In reality, strict parsing changes the incentives and thus people’s behaviour. Dude I lived in that world. A fair amount of developers explicitly opted into strict parsing rules by choosing to serve XHTML. And yet, those developers who opted into strict parsing messed up their XM…

> Dude I lived in that world. A fair amount of developers explicitly opted into strict parsing rules by choosing to serve XHTML. No they didn’t, unless you and I have wildly different definitions of “a fair amount”. The developers who did that were an extreme minority because Internet Explorer, which had >90% market share, didn’t support application/xhtml+xml. It was a curiosity, not something people actually did in…

> No they didn’t, unless you and I have wildly different definitions of “a fair amount”. The developers who did that were an extreme minority because Internet Explorer, which had >90% market share, didn’t support application/xhtml+xml. It was a curiosity, not something people actually did in non-negligible numbers.

Despite being an extreme minority of strict parsing enthusiasts who decided to explicitly opt into strict parsing, they still messed up enough for me to occasionally have encountered "XML Parse Error" pages. You'd think that if anyone managed to correctly generate strict XHTML, it'd be those people.

Re: UI vs. API. vs. UAI

#48

Post by mort96 »

DrScientist wrote: post #44
mort96 wrote: post #41

Earlier quoted context omitted.

> This is not true because you are imagining a world with strict parsing but where people are still acting as though they have lax parsing. In reality, strict parsing changes the incentives and thus people’s behaviour. Dude I lived in that world. A fair amount of developers explicitly opted into strict parsing rules by choosing to serve XHTML. And yet, those developers who opted into strict parsing messed up their XM…

> Never, but people don't dynamically generate their Python back-end code based on user content. Perhaps not much in the past - but I suspect with Agentic systems a lot more in the future - are you suggesting relaxing the Python syntax to make it easier for auto-generated code to 'run'?

There's a difference between static chatbot-generated code that you commit to your VCS, and dynamic code generated based on user content. I'm not talking about the former case.

Re: UI vs. API. vs. UAI

#49

Post by JimDabell »

mort96 wrote: post #47
JimDabell wrote: post #43

Earlier quoted context omitted.

> Dude I lived in that world. A fair amount of developers explicitly opted into strict parsing rules by choosing to serve XHTML. No they didn’t, unless you and I have wildly different definitions of “a fair amount”. The developers who did that were an extreme minority because Internet Explorer, which had >90% market share, didn’t support application/xhtml+xml. It was a curiosity, not something people actually did in…

> No they didn’t, unless you and I have wildly different definitions of “a fair amount”. The developers who did that were an extreme minority because Internet Explorer, which had >90% market share, didn’t support application/xhtml+xml. It was a curiosity, not something people actually did in non-negligible numbers. Despite being an extreme minority of strict parsing enthusiasts who decided to explicitly opt into stri…

> You'd think that if anyone managed to correctly generate strict XHTML, it'd be those people.

Once more, they were operating in a world designed for lax parsing. Even if their direct choices were for strict parsing, everything surrounding them was lax.

Somebody making the choice to enable strict parsing in a world designed for lax parsing is a fundamentally different scenario than “If XHTML really took off (as in a significant majority of web pages were XHTML)”, where the entire technology stack from top to bottom would be built assuming strict parsing.

Re: UI vs. API. vs. UAI

#50

Post by DrScientist »

mort96 wrote: post #48
DrScientist wrote: post #44

Earlier quoted context omitted.

> Never, but people don't dynamically generate their Python back-end code based on user content. Perhaps not much in the past - but I suspect with Agentic systems a lot more in the future - are you suggesting relaxing the Python syntax to make it easier for auto-generated code to 'run'?

There's a difference between static chatbot-generated code that you commit to your VCS, and dynamic code generated based on user content. I'm not talking about the former case.

> I'm not talking about chatbot generated code that's committed to your VCS.

I'm talking about code that's dynamically generated in response to user input in order to perform the task the user specified. This is happening today in agentic systems.

Should we relax python syntax checking to work around the poorly generated code?

Post reply on HN