Hacker News Reader

Comment by daemonk | Hacker News Reader

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?

View on HN

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-extensib...

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.

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.

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

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.

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

Edit: Confused Shadow DOM and Virtual DOM.

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

Thanks for the correction, confused the two.

Reply on news.ycombinator.com