5 ms·

I'm curious if we ever will see the most popular JS/CSS frameworks/libraries integrated into the browser itself, and a simple attribute in the tag would allow l

I'm curious if we ever will see the most popular JS/CSS frameworks/libraries integrated into the browser itself, and a simple attribute in the tag would allow loading the internal version, but still allow failover to the hosted one. This could even prevent man-in-the-middle attacks on scripts that otherwise would never expire anyway like described here: http://thejh.net/written-stuff/want-to-use-my-wifi http://thejh.net/written-stuff/want-to-use-my-wifi

untog 13y ago
Seems like an administrative nightmare. Incorrectly loading JS libraries is just one of many problems when your network connections is compromised.
- larrybolt 13y ago
  Why would this be an administrative nightmare? I can see how deciding which JS/CSS libraries should be included can cause dispute, but apart from that, why not? I actually even always wondered why the default css applied to elements isn't standardised, so pages not containing reset.css or normalize.css-sheets render differently or how certain Javascript methods differ from browser to browser. But I guess that is a rather different discussion.
  - dudus 13y ago
    It is standardized but as many things in the web pre-HTML5 not all vendors agreed with the standards.
  - untog 13y ago
    I think it's part of the same discussion. It makes total logical sense for default CSS to be standardised. Why isn't it? Because coordination between browser manufacturers is extremely patchy. So, different browsers would have different libraries included depending on who made them. Possibly different versions too. It would just be very messy, with little reward.
acdha 13y ago
> I'm curious if we ever will see the most popular JS/CSS frameworks/libraries integrated into the browser itself No - release management would be a nightmare on both sides (“Is feature X worth not using the built-in previous version?” “Ooops, new jQuery point release. Time to ship a Firefox update!”) and it offers no advantages over simply using HTTPS to prevent injection attacks and Cache-Control headers to allow saving a properly versioned URL forever.
thomasfromcdnjs 13y ago
I've started work on something like this in the past -> https://github.com/cdnjs/browser-extension https://github.com/cdnjs/browser-extension Using the Extensions API I could even stop the DNS check and inject the Javascript before that which was pretty awesome. My version would simply just look for cdnjs.cloudflare.com links in the source before rendering but could be applied less strictly to other assets e.g. Google jQuery CDN (I co-started cdnjs.com a few years ago)

untog 13y ago

Seems like an administrative nightmare. Incorrectly loading JS libraries is just one of many problems when your network connections is compromised.

larrybolt 13y ago
Why would this be an administrative nightmare? I can see how deciding which JS/CSS libraries should be included can cause dispute, but apart from that, why not? I actually even always wondered why the default css applied to elements isn't standardised, so pages not containing reset.css or normalize.css-sheets render differently or how certain Javascript methods differ from browser to browser. But I guess that is a rather different discussion.
- dudus 13y ago
  It is standardized but as many things in the web pre-HTML5 not all vendors agreed with the standards.
- untog 13y ago
  I think it's part of the same discussion. It makes total logical sense for default CSS to be standardised. Why isn't it? Because coordination between browser manufacturers is extremely patchy. So, different browsers would have different libraries included depending on who made them. Possibly different versions too. It would just be very messy, with little reward.

acdha 13y ago

> I'm curious if we ever will see the most popular JS/CSS frameworks/libraries integrated into the browser itself No - release management would be a nightmare on both sides (“Is feature X worth not using the built-in previous version?” “Ooops, new jQuery point release. Time to ship a Firefox update!”) and it offers no advantages over simply using HTTPS to prevent injection attacks and Cache-Control headers to allow saving a properly versioned URL forever.

thomasfromcdnjs 13y ago

I've started work on something like this in the past -> https://github.com/cdnjs/browser-extension https://github.com/cdnjs/browser-extension Using the Extensions API I could even stop the DNS check and inject the Javascript before that which was pretty awesome. My version would simply just look for cdnjs.cloudflare.com links in the source before rendering but could be applied less strictly to other assets e.g. Google jQuery CDN (I co-started cdnjs.com a few years ago)