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

31–40 of 54 posts

Re: UI vs. API. vs. UAI

#31

Post by gavmor »

cco wrote: post #12

We recently released isagent.dev [1] exactly for this reason! Internally at Stytch three sets of folks had been working on similar paths here, e.g. device auth for agents, serving a different documentation experience to agents vs human developers etc and we realized it all comes down to a brand new class of users on your properties: agents. IsAgent was born because we wanted a quick and easy way to identify whether a…

I feel OP is addressing the complementary, opposite use case in which behavior is to be unified across user agents.

Re: UI vs. API. vs. UAI

#32

Post by throwaway346434 »

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…

More or less? https://en.m.wikipedia.org/wiki/WHATWG is fairly neutral. As someone in userland at the time on the other side of it, it was all a bit nuts.

IE we got new standards invented out of thin air - https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Mic... - which ignored what hundreds had worked on before, which seemed to be driven by one person controlling the "standard" making it up as they went along.

Microformats and RDFa were the more widely adopted solutions at the time, had a lot of design and thought put into them, worked with HTML4 (but thrived if used with xhtml), etc etc.

JSON-LD/schema.org has now filled the niche and arguably it's a lot better for devs, but imagine how much better the "AI web UX" would be now if we'd just standardised earlier on one and stuck with it for those years?

This is the main area where I saw the behaviour on display, where I interacted most. So the original comment feels absolutely in line with my recollections.

I love bits of HTML5, but the way it congealed into reality isn't one of them.

Re: UI vs. API. vs. UAI

#33

Post by cco »

gavmor wrote: post #31
cco wrote: post #12

We recently released isagent.dev [1] exactly for this reason! Internally at Stytch three sets of folks had been working on similar paths here, e.g. device auth for agents, serving a different documentation experience to agents vs human developers etc and we realized it all comes down to a brand new class of users on your properties: agents. IsAgent was born because we wanted a quick and easy way to identify whether a…

I feel OP is addressing the complementary, opposite use case in which behavior is to be unified across user agents.

> Mostly I’ve just been stressing to my team that we need to consider these interfaces for our application as equal surfaces for how our application will be used. As we build features, we need to make conscious decisions about whether and how those features are accessible and legible in all three of those interfaces.

I read this to mean that they're thinking about all three experiences (interfaces) on equal footing, not as a unified one experience for all three user agents.

Re: UI vs. API. vs. UAI

#34

Post by MarkSweep »

com2kid wrote: post #20
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…

> 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 pages would become way more common Except JSX is being used now all over the place and JSX is basically the return of XHTML! JSX is an XML schema with inline JavaScript. The difference now days is all in the tooling. It is either precompiled (so…

Speaking of PHP, XHP predates JSX I believe:

https://en.wikipedia.org/wiki/XHP

Same idea: an XML-like syntax for creating object trees typically used to model HTML.

Re: UI vs. API. vs. UAI

#35

Post by wvenable »

dathinab wrote: post #28
wvenable wrote: post #23

Earlier quoted context omitted.

HTML being lenient is what made progressive enhancement possible -- right down the original tag. The web would not have existed at all if HTML was strict right from the start.

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

Re: UI vs. API. vs. UAI

#36

Post by FridgeSeal »

paulddraper wrote: post #16
arscan wrote: post #10

Earlier quoted context omitted.

> Protocols and standards like HTML built around "be liberal with what you accept" have turned out to be a real nightmare. This feels a bit like the setup to the “But you have heard of me” joke in Pirates of the Caribbean [2003].

Or "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Sure, this holds for any government “current state” but it shouldn’t be used as an excuse to _keep doing dumb things_.

Re: UI vs. API. vs. UAI

#37

Post by JimDabell »

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…

> 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 with strict parsing for everything else. If you make syntax error with JSON, it stops dead. How often is it that you run into a website that fails to load because there is a syntax error in JSON? It’s super rare, right? Why is that? It’s because syntax errors are fatal errors. This means that when developing the site, if the developer makes a syntax error in JSON, they are confronted with it immediately. It won’t even load in their development environment. They can’t run the code and the new change can’t be worked on until the syntax error is resolved, so they do that.

In your hypothetical world, they are making that syntax error… and just deploying it anyway. This makes no sense. You changed the initial condition, but you failed to account for everything that changes downstream of that. If syntax errors are fatal errors, you would expect to see far, far fewer syntax errors because it would be way more difficult for a bug like that to be put into production.

We have strict syntax almost everywhere. How often do you see a Python syntax error in the backend code? How often do you run across an SVG that fails to load because of a syntax error? HTML is the odd one out here, and it’s very clear that Postel was wrong:

https://datatracker.ietf.org/doc/rfc9413/

Re: UI vs. API. vs. UAI

#38

Post by jnmandal »

metayrnc wrote: post #2

This is already true for just UI vs. API. It’s incredible that we weren’t willing to put the effort into building good APIs, documentation, and code for our fellow programmers, but we are willing to do it for AI.

Yeah, this is so true. Well designed APIs are also already almost good enough for AI. There really was always a ton of value in good API design before LLMs. Yet a lot of people still said, for varying reasons, let's just ship slop and focus elsewhere.

Re: UI vs. API. vs. UAI

#39

Post by jnmandal »

darepublic wrote: post #3

if you want your app to be automated wouldn't you just publish your api and make that readily available? I understand the need for agentic UI navigation but obviously an api is still easier and less intensive right. The problem is that it isn't always available, and there ui agents can circumvent that. But you want to embrace the automation of your app so.. just work on your API? You can put an invisible node in your…

This is true but also your API needs to actually implement all the use cases (often its only for a subset) and it needs to work well (often there are many nuances or inconsistencies). But I agree there are lots of overlap. No need to completwly reinvent the wheel here. Actually CQRS systems work incredibly well with LLMs already.

Re: UI vs. API. vs. UAI

#40

Post by mort96 »

com2kid wrote: post #30
mort96 wrote: post #29

Earlier quoted context omitted.

Nobody is generating JSX dynamically.

Not directly as strings of course, but a for loop that outputs a bunch of JSX components based on the array return values from a DB fetch is dynamically generated JSX.

No, it's not. The JSX, as in the text in the source file, is static. You can't accidentally forget to escape a string from the database and therefore end up with invalid JSX syntax, like you can when dynamically generating HTML. You're dynamically generating shadow DOM nodes, but the JSX is static.
Post reply on HN