Facebook and the media: united, they attack the web
baldurbjarnason.com
Facebook and the media: united, they attack the web
1–10 of 36 posts
Re: Facebook and the media: united, they attack the web
#2The article was better than I expected from the title.
It's not about Facebook, and it's not exactly about online media either. It's about failed expectations with (particularly mobile) online media, and how conflicting needs far too often neglect the user experience.
Speed matters. Performance is crucial. Load times are atrocious. And above all: screen real estate on mobile is precious. A badly transferred advert that happens to sort of work on desktop, when the user has >20Mbps connection - it murders the UX on mobile. And as a result, makes the entire site unusable. As a result, users are moving to anything that makes the content load faster, and where the ads are not as intrusive.
The irony of it all? FB is better at serving media than the producers and publishers themselves.
UX >> UI.
Re: Facebook and the media: united, they attack the web
#3[deleted]
Re: Facebook and the media: united, they attack the web
#4[deleted]
Re: Facebook and the media: united, they attack the web
#5I agree with the overall sentiment expressed that web developers can and should do better as it comes to performance.
There were a few inaccurate or misleading remarks in the article that I'd like to draw attention to:
1) Guess how those Instant Articles are formatted? HTML. Guess how those articles get to the app? HTTP.
This is misleading because it seems to equate pulling in content with loading an article. By loading these articles into the app (as opposed to launching a browser), Facebook gains the ability to do the following:
- Provide the basic styles from app-install time. Most of your css doesn't need to be downloaded.
- Skip app boot time. App's take a while to cold start, meaning I don't have to start safari before I start the web request.
- Prefetch. I don't know if they do or will do this, but facebook could reasonably prefetch articles and their resources before you click
2) Stop buying into the ‘native is better’ myth. (It’s just different.)
Another phrase for "different" is "better at different things". It turns out that the app model provides some amazing guarantees that the web can't match (and vice-versa):
- Preloaded styles and logic. Content changes, but presentation stays the same. Only download content. (no caching is not a valid solution, because exercising new parts of the code would require a download. Though some appmanifest magic may let you get pretty close)
- Cheap library inclusion. If an app is an extra MB or so it's no big deal most of the time. You can use that to load in libraries that vastly speed up developer work and can do "progressive enhancement" by supported new APIs on old OS versions. Libraries are way more costly on the web as the author points out.
- Consistent (with the OS) UX and much cheaper animations
- Lower memory footprint
These things do matter! The web is amazing, yes. No, it's not dying, but there is value in native apps and they're not equivalent. Smart engineers will make the choice based on their needs which is what both facebook and these news sources are doing.
Re: Facebook and the media: united, they attack the web
#6From the article: "The web definitely has a speed problem due to over-design and the junkyard of tools people feel they have to include on every single web page. However, I don’t agree that the web has an inherent slowness. The articles for the new Facebook feature will be sent over exactly the same connection as web pages. However, the web versions of the articles have an extra layer of cruft attached to them, and that’s what makes the web slow to load. The speed problem is not inherent to the web; it’s a consequence of what passes for modern web development. Remove the cruft and we can compete again."
I've been bitching about this ever since it became clear that CSS made web pages bulkier. (Yeah, it was supposed to make them shorter. Didn't happen.) We had much faster loading pages when people created HTML 3.2 with Dreamweaver and tables, and most of them looked about the same. Now we need HTTP2 so that all the "assets" can be loaded more effectively. There are even content management systems which generate bloated custom CSS for every page, with huge numbers of classed tags customized for each page. This eliminates any useful caching.
Some major sites have figured this out. The Wall Street Journal's home page has become shorter and simpler at the HTML level. Two years I looked at it, and some content management system was inserting the entire sign-up-for-a-subscription machinery on every page. They've fixed that. The Washington Post is inserting the same block of Javascript for each story. Somebody should tell those guys about functions.
I have a web service which strips all active content (Javascript, Flash, Active-X, Silverlight, etc.) from a page, parses it, and redisplays it. Most major news sites seem to work OK in that mode. Instagram is fine. (WhatsApp looks awful.) Much of the junk that slows page loading is providing little, if any, benefit to the user.
Re: Facebook and the media: united, they attack the web
#7I agree with the overall sentiment expressed that web developers can and should do better as it comes to performance. There were a few inaccurate or misleading remarks in the article that I'd like to draw attention to: 1) Guess how those Instant Articles are formatted? HTML. Guess how those articles get to the app? HTTP. This is misleading because it seems to equate pulling in content with loading an article. By load…
For what it's worth the Facebook app takes forever to load (like 3 minutes or more) on my 3-year old iPhone 4, while browsing for stuff on Safari stills works reasonably well, bar the odd website which throws a huge advert at you.
People would probably advise me to change my phone, to get a newer one, but why should we change our phones every 2 years? Why create more waste? Why spend money uselessly on stuff that should work for at least 5 years?
Re: Facebook and the media: united, they attack the web
#8The gist is for me: The speed problem is not inherent to the web; it’s a consequence of what passes for modern web development. Remove the cruft and we can compete again.
My guess is, the cruft will not be removed, but will just be sped up with WebAssembly etc. Building a web site that's functional and fast stays an art form that's not accessible to everyone. Native apps are just a quick-&-dirty cop-out from that problem.
Re: Facebook and the media: united, they attack the web
#9The gist is for me: The speed problem is not inherent to the web; it’s a consequence of what passes for modern web development. Remove the cruft and we can compete again. My guess is, the cruft will not be removed, but will just be sped up with WebAssembly etc. Building a web site that's functional and fast stays an art form that's not accessible to everyone. Native apps are just a quick-&-dirty cop-out from that pro…
WebAssembly won't do anything for the latency delays of a myriad of support files (javascript, CSS, images) which is the key problem for small apps and non-applicatino pages, HTTP2's better handling of multiple files (or for HTTP(S) grouping everything into one minified block) won't help if they are coming from different 3rd parties, ...
That is an issue that needs to be addressed by people changing how they currently build some pages/apps. It is particularly bothersome when mobile and stuck on a slow high-latency connection.
Re: Facebook and the media: united, they attack the web
#10I feel like I'm living under a rock, sheltered from all this except when ever so often I click on a link on HN an get taken to some website from hell. Complaining about that world is like complaining about how pointless broadcast TV is. You can't fight it and there isn't anything there worth fighting for, you're not missing out on anything.