31–40 of 97 posts
Earlier quoted context omitted.
Browser option to make hyperlinks clickable when rendering text files? Or client-side browser rendering of text-based markdown.
Having browsers intelligently render `text/markdown` sounds like a great idea. And while we're waiting on the browser implementation, maybe we can find some sort of temporary workaround to send a markdown parser to the client?
Earlier quoted context omitted.
There is a thing in HTML5 called Subresource Integrity ( https://developer.mozilla.org/en-US/docs/Web/Security/Subres... ). It looks like this: I wonder if browsers could keep a cache with those hashes as keys and whenever the integrity hash has a match, then it can take the JS from the cache. That would save huge amounts of bandwidth and pages would be so much faster to load. Probably right now we're fetching the sa…
> There is a thing in HTML5 called Subresource Integrity It piqued my interest, but I was disappointed to discover that it's only supported by Gecko & Blink[1] - not supported by Safari or IE/Edge. Javascript is currently unavoidable for offline apps. 1. http://caniuse.com/#search=integrity
Just use pure HTML/CSS and the web sites will fly by comparison.
For a single page load, sure. For subsequent page loads you're loading a lot more than necessary (a JS app can fetch just the content that's changed, and without a blank page in between), so a pure HTML and CSS solution is a great deal slower. Plus, if you users have unreliable internet connections then a JS app can use a service worker to cache the entire app to work offline, and only load in new content when possib…
Earlier quoted context omitted.
There is a thing in HTML5 called Subresource Integrity ( https://developer.mozilla.org/en-US/docs/Web/Security/Subres... ). It looks like this: I wonder if browsers could keep a cache with those hashes as keys and whenever the integrity hash has a match, then it can take the JS from the cache. That would save huge amounts of bandwidth and pages would be so much faster to load. Probably right now we're fetching the sa…
Currently, SRI is not enough for browsers to implement content-addressable storage as you describe here, because it is subject to cache poisoning. See https://news.ycombinator.com/item?id=10311020 - basically, the browser can't know if a script can actually be loaded from the claimed domain without requesting it. This can be used to violate CSP. Though it would be nice for the browser to cache it for domains that hav…
Earlier quoted context omitted.
From back when LAMP (Linux being the L) was the buzz.
oh LAMP .. and if you were enterprise, it was SOA (Service Orientated Architecture) and today it's Microservices. So buzzy.
It's a pretty interesting talk. Just thinking about this kind of stuff can make way skinnier web pages than AMP. I mean really, if we designed pages for 56k modems, the web would be much much fast on mobile.
Earlier quoted context omitted.
HTML/CSS are slow. The true way is ".txt" Edit: I mean this as a sort of lazy way of making a reductio. I don't think .txt is better than HTML/CSS for pages (and I hope that's obvious). I also don't think having no JS is a good idea. I believe in progressive enhancement, and to a first approximation, I think that all websites have at least one feature that they could implement in JS that would be "a good thing".
I agree 90% with this; .txt files get most of the job done! ;-) The other 10% where i don't fully agree comprises of hyperlinks; i need me some clickable hyperlinks. :-)