71–80 of 100 posts
> Rough estimates say we may have a billion users already. This cannot be true by a long shot. Or am I missing something?
Earlier quoted context omitted.
Anything that requires JavaScript to fetch and display content.
Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time.
Curl is pretty great to use, but be warned it has old smelly code and is probably full of security issues. I wouldn't use it for anything too critical.
Earlier quoted context omitted.
Anything that requires JavaScript to fetch and display content.
Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
I love curl so much. I just learned that you can 'copy to curl command' from the chrome inspector's network panel by right clicking on any request!! I want to make a library that reads the curl command (and maybe request syntax?) and outputs a function that will do that command.
https://shibukawa.github.io/curl_as_dsl/
And still better than wget, which only does http 1.0 and this has problems due to lacking a 'host' header. Curl just works.
> And still better than wget, which only does http 1.0 and this has problems due to lacking a 'host' header. Well I had to check, but this is not true at all: $ nc -l -p 9999 GET / HTTP/1.1 User-Agent: Wget/1.15 (linux-gnu) Accept: */* Host: localhost:9999 Connection: Keep-Alive Also wget can recursively mirror webpages and there are nice options to carefully select contents you want to download. It's quite dated tho…
I stumbled upon this info when writing a redirector app recently. You're right, I should have verified that it was true.
Earlier quoted context omitted.
Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly. Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when the…
No hours were wasted, and they didn't really switch back. They're just using HTML5's History API on browsers that support it now. Essentially the same mechanism under the hood, just prettier URLs for it.
Earlier quoted context omitted.
Anything that requires JavaScript to fetch and display content.
Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
[1] http://nerds.airbnb.com/isomorphic-javascript-future-web-app...