←back to thread

218 points mdhb | 1 comments | | HN request time: 0s | 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. btown ◴[] No.44393439[source]
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.