alt Hacker NewsA 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
Isn't that why you have versions and maintains backward compatibility with older versions, and don't change the "old" interfaces?
> spends most of its useful life being the old thing that people are trying to work around
But in the process, the base functionality has been propped up another level.
Incremental updates aren't worthwhile just because of userland requirements that will always discover new gaps, use-cases and blindspots.
> 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.
> A basic lesson we've learned over and over is that API/ABIs aren't final.
On the web they are. Once something is out in the open on the web, there will be people depending on this, in this exact form, forever.
That's why there are still APIs that end up in "smooshgate" because of decisions from 20 years ago: https://developer.chrome.com/blog/smooshgate
It's also the case that every feature in web standards means extra code that needs to be painstakingly maintained, and extra code that anyone trying to create a standards-compliant browser must implement. I want to see projects like https://servo.org/ actually have a chance to catch up over time, not always be chasing an expanding scope.
I want the web platform to have every possible capability that native platforms have (subject to privacy and sandboxing constraints, of course). And I want the developer experience of web developers to be incredible.
But these need to be balanced against the consequences of added complexity. And in this case, does native templating really improve developer experience? I'm not convinced the benefits outweigh the costs.