Also, NPR has had a text only site for ages
NPR set up a text site in late 2001. A developer reworked the text site in 2005. We have made very few changes since then.
The site is a set of a few PHP scripts querying our MySQL CMS database directly with no caching. The HTML and JS were aimed at providing a decent mobile experience in 2005. That included a lot of hacks and workarounds for extremely defunct platforms.
The newsroom asked us to make some improvements. The main features:
- display more news stories following editorial order rather than reverse chron,
- remove the obnoxious interstitial "read more" view for stories,
- put the text site behind Akamai like our other web properties,
- configure HTTPS on the text site (still in progress and won't be the default due to TLS overhead)
It should be a lot faster and more pleasant to use.
Thank you to everyone who made lots of noise about CNN's text offering. There is a small contingent of developers at NPR who love the text site to the point that they've created replacements as personal projects. They were very excited to improve it for the public!
Read More ... ( 19213 bytes )
Brilliant!
Unrelated, seems like I can't listen to podcasts. There's an <audio> tag (which doesn't use data unless you click on play if you set preload="none" [1]), so that's an interesting choice.
$ curl http://thin.npr.org/t.php?tid=1001
[...]
Total wall clock time: 2.7s
$ ping thin.npr.org
[...]
round-trip min/avg/max/stddev = 76.407/78.359/86.985/2.442 ms
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/au...
PHP has warts, but I find it unlikely that it would be the reason for a 2.7 second page load.
* To overcome government censorship and surveillance.
* To stop internet providers from injecting ads and tracking scripts.
But the site isn't being censored? Also https won't stop the government from knowing that you connected to those servers. I agree that we want to avoid censorship and surveillance in general, but it really doesn't seem relevant here.
>To stop internet providers from injecting ads and tracking scripts.
Is your ISP actually doing that to you right now? Or is that just hypothetical?
How do you know? Without https, a MITM-attack might already be in place, and you wouldn't even notice.
Yes there are multiple instances where my isp was injecting stuff. More frequently at public wifi spots.
I was on a Southwest flight earlier this week which did exactly this, using HTTP injection to display an overlay on every HTTP page. It's certainly useful to provide flight information (or Amber alerts, weather information, billing alerts), but it's Just Wrong™ to violate the integrity of a communication to do so. Perhaps there should be some standard protocol for ISPs to send messages to clients, permitting the connected OS to determine how to display them?