4 ms·

I often see packages or solutions to problems related to browsers/servers on hackernews. Why don't people who make browsers or servers implement these things as

by daemonk 10y ago

I often see packages or solutions to problems related to browsers/servers on hackernews. Why don't people who make browsers or servers implement these things as a standard? IE. There seems to be so many people using jquery/react. Why not just implement some of their functionalities natively into the browser? There seems to be a trend of making un-opinionated software that acts as more of a sandbox for down-stream developers. I think that's great because we are now seeing the great solutions coming out of that sandbox. But at what point do we start to have a general consensus and implement some of these great solutions natively to remove the resource overhead?

halomru 10y ago
Where JQuery was once a necessity for building complex dynamic crossbrowser web pages, on today's browsers the popular parts of JQuery mostly just make the syntax sightly shorter and fix tiny inconsistencies. JQuery functionality is for the largest part integrated in modern browsers, JQuery is living on because of momentum, it's ecosystem and the desire to support older browsers. React meanwhile is popular in some places, but hasn't reached nearly the age and ubiquity that would warrant a native browser implementation.
rictic 10y ago
A number of the core jquery innovations have been implemented in the browser. document.querySelector is the clearest example I think. The big push in browser standards is the Extensible Web Manifesto[1]. The idea being that we should first give web developers powerful and general purpose primitives to explore and build solutions with, because there are many more web devs than there are browser implementors, and the standardization process is slow. We can then explore standardizing the most successful and useful results. This project is using service worker, one of the canonical extensible web APIs as it gives sites tremendous control over their network use. [1] https://www.w3.org/community/nextweb/2013/06/11/the-extensible-web-manifesto/ https://www.w3.org/community/nextweb/2013/06/11/the-extensib...
dexterdog 10y ago
Do you really have to make them standard? There are not that many versions of most of these. Caching every common version of jQuery is pretty trival. The problem is that many people host it themselves or use one of many CDNs to serve it up and then expose users to the potential tracking that CDNs can do. Why don't the browsers just cache based on the integrity hash of the css and js links when it is there instead of the url? Then everybody can host his own copies for the cases where the user doesn't have it and cache hits will be much more common.
- dexterdog 10y ago
  Concept covered in more depth here: https://mntr.dk/2016/content-addressable-browser-caching/ https://mntr.dk/2016/content-addressable-browser-caching/
nathancahill 10y ago
Shadow DOM, arguably one of React's biggest innovations, is indeed becoming standardized in browsers: https://www.w3.org/TR/shadow-dom/ https://www.w3.org/TR/shadow-dom/ Edit: Confused Shadow DOM and Virtual DOM.
- niftich 10y ago
  Shadow DOM is the cloaking of the insides of a particular element, and thus a tool for web componentization and encapsulation. IIRC, while React encourages building reusable, encapsulated components, it doesn't hide the internal state from view [1]. Perhaps you're thinking Virtual DOM, which is a technique to apply only diff-ed state changes to the real DOM, which isn't actually standardized (yet), although alternate implementations (outside of React) exist? [1] https://facebook.github.io/react/tips/inline-styles.html https://facebook.github.io/react/tips/inline-styles.html
  - nathancahill 10y ago
    Thanks for the correction, confused the two.
erikpukinskis 10y ago
One of the reasons the web has succeeded so much more broadly than other UI toolkits, like Windows.Forms or Cocoa is that the web is very underspecified. The lack of a comprehensive framework has led to a proliferation of frameworks, each with different strengths and weaknesses. Competition between these has created thousands upon thousands of tools optimized for very specific use cases. Because there are strong standards on a platform like iOS, you see almost no competition in many parts of the stack, and so that platform is limited by Apple's developer resources and constrained by the necessity of designing the architecture for the lowest common denominator. The general philosophy in web standards groups has been to start by providing the simplest possible API that will give developers access to the functionality they need, allow developers to build frameworks on top of that. And then as common use cases emerge, back port the most widely used features into the API.

by daemonk 10y ago

halomru 10y ago

Where JQuery was once a necessity for building complex dynamic crossbrowser web pages, on today's browsers the popular parts of JQuery mostly just make the syntax sightly shorter and fix tiny inconsistencies. JQuery functionality is for the largest part integrated in modern browsers, JQuery is living on because of momentum, it's ecosystem and the desire to support older browsers. React meanwhile is popular in some places, but hasn't reached nearly the age and ubiquity that would warrant a native browser implementation.

rictic 10y ago

A number of the core jquery innovations have been implemented in the browser. document.querySelector is the clearest example I think. The big push in browser standards is the Extensible Web Manifesto[1]. The idea being that we should first give web developers powerful and general purpose primitives to explore and build solutions with, because there are many more web devs than there are browser implementors, and the standardization process is slow. We can then explore standardizing the most successful and useful results. This project is using service worker, one of the canonical extensible web APIs as it gives sites tremendous control over their network use. [1] https://www.w3.org/community/nextweb/2013/06/11/the-extensible-web-manifesto/ https://www.w3.org/community/nextweb/2013/06/11/the-extensib...

dexterdog 10y ago

Do you really have to make them standard? There are not that many versions of most of these. Caching every common version of jQuery is pretty trival. The problem is that many people host it themselves or use one of many CDNs to serve it up and then expose users to the potential tracking that CDNs can do. Why don't the browsers just cache based on the integrity hash of the css and js links when it is there instead of the url? Then everybody can host his own copies for the cases where the user doesn't have it and cache hits will be much more common.

dexterdog 10y ago
Concept covered in more depth here: https://mntr.dk/2016/content-addressable-browser-caching/ https://mntr.dk/2016/content-addressable-browser-caching/

nathancahill 10y ago

Shadow DOM, arguably one of React's biggest innovations, is indeed becoming standardized in browsers: https://www.w3.org/TR/shadow-dom/ https://www.w3.org/TR/shadow-dom/ Edit: Confused Shadow DOM and Virtual DOM.

niftich 10y ago
Shadow DOM is the cloaking of the insides of a particular element, and thus a tool for web componentization and encapsulation. IIRC, while React encourages building reusable, encapsulated components, it doesn't hide the internal state from view [1]. Perhaps you're thinking Virtual DOM, which is a technique to apply only diff-ed state changes to the real DOM, which isn't actually standardized (yet), although alternate implementations (outside of React) exist? [1] https://facebook.github.io/react/tips/inline-styles.html https://facebook.github.io/react/tips/inline-styles.html
- nathancahill 10y ago
  Thanks for the correction, confused the two.

erikpukinskis 10y ago

One of the reasons the web has succeeded so much more broadly than other UI toolkits, like Windows.Forms or Cocoa is that the web is very underspecified. The lack of a comprehensive framework has led to a proliferation of frameworks, each with different strengths and weaknesses. Competition between these has created thousands upon thousands of tools optimized for very specific use cases. Because there are strong standards on a platform like iOS, you see almost no competition in many parts of the stack, and so that platform is limited by Apple's developer resources and constrained by the necessity of designing the architecture for the lowest common denominator. The general philosophy in web standards groups has been to start by providing the simplest possible API that will give developers access to the functionality they need, allow developers to build frameworks on top of that. And then as common use cases emerge, back port the most widely used features into the API.