3 ms·

This could be a very dumb question, since I don’t use any JS frameworks (on the client side), but… would it make sense to standardize (on the web platform) cert

This could be a very dumb question, since I don’t use any JS frameworks (on the client side), but… would it make sense to standardize (on the web platform) certain aspects of JS frameworks (their internals), so that the frameworks themselves could become leaner. My thinking is, if the frameworks do similar things, i.e. provide similar functionality, maybe it would make sense to have browsers provide (standard) APIs for (some of) that functionality.

spankalee 11y ago
This is exactly what Web Components are: a standardized, minimal, HTML-compatible, component model that's understood by the browser. It solves DOM encapsulation, style scoping, element lifecycle, and DOM composition. Frameworks and libraries can then build on top of that to provide templating, data-binding, additional lifecycle stages, and other helpers, which Polymer and X-Tags do.
stupidcar 11y ago
This has happened, is happening, and will continue to happen. Huge swathes of the standardised additions to the web platform over the last fifteen years have been inspired or informed by features that were originally included in JS libraries and frameworks. Library and framework developers participate in standards bodies and give feedback to browser vendors (many of them work for browser vendors), and help to drive what goes into the web platform, based on what the implemented, and what they need for their software. The problem is, software development is a moving target. The current feature-set of the web platform would let you easily build a state of the art application... in 2005. But things have moved on. People's ambitions and expectations for the functionality, responsiveness across devices, performance, aesthetic appeal, touch friendliness, accessibility and offline capability of their web apps has skyrocketed. And at the same time, we've learned more about the coding strategies and patterns that work (and don't work) for writing, large, ambitious web applications. This is a good thing, because it means the web is moving forward, and so are we. However, it also means we're never going to reach a promised land where the web platform does everything we could ever need it to. There will always be new demands and new technology — retina screens, VR, fingerprint scanners, etc. — and the web platform will need to catch up in those areas. There will always be new frameworks, like React, that overturn existing best practices and experiment with new ways of doing things. This means will always be a need for libraries and frameworks at the cutting edge of web development, to pioneer the paths that can later be paved via standardisation. We also need to be wary of premature standardisation. Web components have arguably suffered from this, although its proponents couldn't have predicted it when they began. For years, component-based encapsulation libraries/frameworks gained very little traction on the web, and so Google launched an effort to deliver components natively via a set of standardised APIs. However, halfway through their effort, Angular and React blew up, and suddenly everyone was writing components as directives and JSX components. This has caused some friction, because components as implemented by these frameworks (and thus coded by the majority of web devs) don't quite match the vision set out in web components. Web components will still deliver useful features, such as Shadow DOM, which will find use in these libraries, but had the web components effort started after Angular and React had appeared, its design would likely have looked somewhat different.

spankalee 11y ago

This is exactly what Web Components are: a standardized, minimal, HTML-compatible, component model that's understood by the browser. It solves DOM encapsulation, style scoping, element lifecycle, and DOM composition. Frameworks and libraries can then build on top of that to provide templating, data-binding, additional lifecycle stages, and other helpers, which Polymer and X-Tags do.

stupidcar 11y ago

This has happened, is happening, and will continue to happen. Huge swathes of the standardised additions to the web platform over the last fifteen years have been inspired or informed by features that were originally included in JS libraries and frameworks. Library and framework developers participate in standards bodies and give feedback to browser vendors (many of them work for browser vendors), and help to drive what goes into the web platform, based on what the implemented, and what they need for their software. The problem is, software development is a moving target. The current feature-set of the web platform would let you easily build a state of the art application... in 2005. But things have moved on. People's ambitions and expectations for the functionality, responsiveness across devices, performance, aesthetic appeal, touch friendliness, accessibility and offline capability of their web apps has skyrocketed. And at the same time, we've learned more about the coding strategies and patterns that work (and don't work) for writing, large, ambitious web applications. This is a good thing, because it means the web is moving forward, and so are we. However, it also means we're never going to reach a promised land where the web platform does everything we could ever need it to. There will always be new demands and new technology — retina screens, VR, fingerprint scanners, etc. — and the web platform will need to catch up in those areas. There will always be new frameworks, like React, that overturn existing best practices and experiment with new ways of doing things. This means will always be a need for libraries and frameworks at the cutting edge of web development, to pioneer the paths that can later be paved via standardisation. We also need to be wary of premature standardisation. Web components have arguably suffered from this, although its proponents couldn't have predicted it when they began. For years, component-based encapsulation libraries/frameworks gained very little traction on the web, and so Google launched an effort to deliver components natively via a set of standardised APIs. However, halfway through their effort, Angular and React blew up, and suddenly everyone was writing components as directives and JSX components. This has caused some friction, because components as implemented by these frameworks (and thus coded by the majority of web devs) don't quite match the vision set out in web components. Web components will still deliver useful features, such as Shadow DOM, which will find use in these libraries, but had the web components effort started after Angular and React had appeared, its design would likely have looked somewhat different.