←back to thread

218 points mdhb | 2 comments | | HN request time: 0.437s | source
Show context
shermantanktop ◴[] No.44392381[source]
A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues.

This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example.

If a proposal like this succeeds, it lives a time in the sun, but then spends most of its useful life being the old thing that people are trying to work around, just like the DOM API, just like ECMA versions, just like old browsers, just like every other useful bit of tech that is part of the system but can't be touched.

Is it possible to think about entropy, extension and backcompat as primary use cases?

replies(5): >>44393403 #>>44393411 #>>44393439 #>>44395752 #>>44396407 #
1. quotemstr ◴[] No.44393403[source]
> A basic lesson we've learned over and over is that API/ABIs aren't final

I dunno --- getElementById has been stable for, what, 25 years? "There's no such thing as a stable API" is something said by people unable or unwilling to create interfaces that last. It's a statement of personal resignation, not cosmic impossibility. There are tons of counterexamples.

Application needs, like other needs, are infinite. You satisfy these needs by adding new APIs, not breaking working ones.

replies(1): >>44394901 #
2. bryanrasmussen ◴[] No.44394901[source]
I think you'll find that even the most unstable APIs have extremely stable parts to them.

At the same time I don't think there is actually anything that most people would consider an API that is open to public usage that has maintained that kind of stability that getElementById has, which after all is something most people would describe as a method of an API.