3 ms·
I know what you mean, but I'd argue while that works for technical details with defined inputs->outputs, it doesn't really work for UI which is a much more open
by davnicwil 7y ago
I know what you mean, but I'd argue while that works for technical details with defined inputs->outputs, it doesn't really work for UI which is a much more open ended problem/solution space which the user directly interacts with. Beyond even the practical concerns with locking yourself down to certain modes of doing UI, there's also just evolving taste, trends of usage, device types etc. I just don't think UI is something you can ever call done.
- akiselev 7y agoI don't think what the GP is describing would restrict anyone from innovating in the UI space. What we need is a standard API for framework+component life cycles, tracing - i.e. a currentComponent api for tracking the relationship between JS scopes and DOM elements, and context/slot apis powerful enough to bridge between the parent-child semantics in React/Vue/etc and more complex implementations like Svelte's slots. A better abstraction between browsers and OS accessibility layers also wouldn't hurt. Think aria attributes, window.requestAnimationFrame, source maps, and the JS debugger statement - not UI frameworks or new standard HTML elements.
- Polylactic_acid 7y agoAlso even if browsers did implement standard UI elements no one would use them. Its the same situation we have today where everyone re implements the browser default inputs because they are too basic and not flexible enough and work different on every browser.