I don't buy that argument at all. 1. The rate of change has been steadily increasing in browsers, hard to imagine it could have been faster. 2. One way the platform evolves is contending with actual problems, not perceived ones, so this is forcing the issue.
-
-
-
As one of the people who has pushed hardest on browser evolution, the deadweight losses are pretty obvious to me. Don't expect others to see them, or my perspective to be broadly accepted, tho.
- 1 more reply
New conversation -
-
-
if you swap browsers with the language and node with browsers, might this also apply to anything browsers have shipped that should have been in the language instead?
-
Great thought experiment; teases out what makes these different. For instance: - browser (DOM is largest, most widely used std lib, so relationship priority may be different - node/browser API overlap is left to developers, whereas browser/lang integration is one team
End of conversation
New conversation -
-
-
Can't say I remember a lull in browser feature demand just because we had a deterministic error handling convention that allowed flow control without throw/try/catch ceremony. The new modules have plenty of sync behavior too fwiw.
-
Do you mean that a graph has to be resolved to allow execution of the importer to proceed? If so...that's wildly different to sync require()
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.