Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

Personally, I think the problem is people trying to be too clever, and loading too much content at once.

Loading tons of JavaScript means that Facebook loads very slowly on my phone on mobile internet. And what is it needed for? The most the JS needs to do is make a pop-down notifications panel, and do one or two AJAX requests to post comments and "like" items. Looking at the Network panel in Chrome, I see Facebook has pulled down 700KB of JavaScript. Why? How could they possibly need that much code?

Facebook also seems to think that sending full-size images down to my phone, instead of compressed previews, isn't a problem. No wonder the GPU memory is exhausted!

View on HN

If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now.

Sure, we can break up our JS into modules that only get loaded on-demand (something that is quite hard to do, by the way), but eventually there will be lots of Javascript on the page. Because, you know, it's an app. Any app of decent complexity will involve a lot of code. By definition.

(as far as image previews go, I agree, that's stupid. Especially given the performance concerns with large images on mobile browsers)

> If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now.

That doesn't follow. We'd only have to give up if you had to have that to display that amount of content. UX should come first. If you don't take care of your customer, someone else will do it for you.

Eh, I just find it hard to believe FB honestly needs that much just to load the homepage. Now, the whole mobile site? Sure, that seems reasonable, considering how much you can do. But if that's the case, I wonder why Facebook aren't modularising it.

>If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now.

Just blame the standard?

If you designed an app with a 700KB JS analytics dependency that's your issue.

It seems like a matter of inadequate tools more than anything.

When I write native code, I write apps that are broken up into relatively small chunks, which are then demand-paged off the disk when needed. A freshly launched copy of my app that hasn't touched most of its code takes up very little memory.

And of course, all apps work that way, because that's how the system is built. It's actually substantially harder to avoid that lazy loading functionality than it is to take advantage of it.

Obviously, the systems used to lazily load machine code stored locally are different from what would be needed to modularize and lazily load source code being loaded over the network, but surely there's some way to improve this without making programmers do a ton of grunt work. If pages are loading huge amounts of JavaScript code that goes unused simply because it's easier to code that way, doesn't that mean the tools are deficient?

>If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now.

Sure. Let's.

As of NOW they are inadequate for mobile devices, provide a sub-par experience to native apps, and move too much redundant BS over the network (even thin client-side-rendering style ones).

Heck, some Canvas/SVG demos even bring a Desktop browser to it's knees and the CPU to 100%.

My experience of Facebook code is that it's bloated and convoluted, having been an evolution of hacks built on top of each other. In fact it feels similar to Microsoft and legacy code that where carried into Windows and beyond. Granted certain FB teams have developed some really cool stuff internally, and I'm just looking at their client side stack. But can't help get the feeling, they are just not thinking creatively about HTML 5 and mobile.

Intuitively to me, 700kb seems excessive and could very probably be reduced. But even so, they could possibly break it up and cache 90% of that [1]. Or on demand loading (as others have suggested). Granted it needs to work across all platforms, but there are companies far smaller with fewer resources producing fast HTML5 apps for mobile.

And if they doing that already, then I just can't understand how something relatively simple, (posting and browsing content), can perform so poorly. One doesn't need 700kb of analytics to know the experience sucks. ;)

[1] http://stackoverflow.com/questions/5108376/how-do-you-cache-...

A large portion of that 700kb of js is for user-level analytics to track everything, which is fed back into everything from Ads to Page Insights to News Feed algorithms. There's a lot going on that has nothing to do with loading and displaying content.

There's a lot going on that has nothing to do with loading and displaying content.

-- This is exactly the problem. for users, content is king.

Just because it doesn't deal with directly showing content doesn't mean it has nothing to do with content.

Let's say Google used predictive algorithms based on what you've clicked/hovered on/looked at on the search page to generate your next query. That doesn't deal with loading and displaying content, but it is directly related to DECIDING which content is going to be shown. And if content is king, that's the most important thing of all.

Exception that proves the rule is google search. nobody wants to trade performance so they can be analyzed and ad-tracked "more better" for basic info...Example: 9x [!] do not track blocks @ http://www.independent.co.uk/

I know it's in vogue to rail on Facebook at every opportunity, but you're making an assumption that all this tracking and analyzation is ultimately only to serve you more targeted advertising or sell your info. While that might be part of the reason, Facebook also does a lot of work behind the scenes to determine what content to show you, just like Google does.

And while we're comparing Google and Facebook, why would it be ok for Google to analyze the heck out of your behavior but not for Facebook to do the same thing? Google and Facebook both make approximately the same percentage of their revenue (basically 100%) off of advertising, right?

To be fair, I think you mis-understood me. There's no mention of FB. My example was a news site with 9 trackers. Plain vanilla newspaper - Independent is in London UK. The odd-couter-example might be x, y, or z. It might be google or it might be facebook. but why not just have opt in? The default inference is that [insert number here] would not find it worthwhile enough to bother. [1]

_______________

[1] Also, I did not mention, but on that topic you asked: FB data can be considered more sensitive. They start broadcasting and sharing stuff. Taking it "out of context", and sent to your network. Kind of ironic, but true. It begs the question: Why do you like this? or Why do your read that? Do I want to put footnotes on everything I do? To explain the "context" and the logic of my thoughts? Not really... =D.

> This is exactly the problem. for users, content is king.

If I were someone significant at Apple or Google(+), I would pay attention here and formulate my attack plan based on this factor. Part of that would involve a browser add-on that syncs to multiple social networks, with the express purpose of taking power away from Facebook.

This would probably violate ToS for facebook.

they should abandon this concept altogether of pushing this burden onto the client-side (smartphone), they should be able to move any tracking logic server-side to get what they need from a mobile device, really I don't think companies should ever offload this burden onto a client-device, what are they tracking client-side (mousovers? keystrokes?) isn't this a bit invasive to the user?

They're tracking things like bounce rates and time on pages to find out who you interact with the most. Also, I'm sure they're analyzing how far you scroll the page, where you click away, and a variety of other things.

can you remove the word "loading" from your comment?

Yes, I'm sure Facebook and their stable of developers just never thought of that. How silly.

I think Facebook do know what they're doing, but are perhaps putting energy into the wrong things. Using a ton of JavaScript to avoid ever having to load another page is a nice idea, but it ends up bogging down the client. Using a lot of abstractions away from the DOM makes things slow. An occasional page load is probably beneficial.

I'm also unconvinced they can't scale down images server-side to make them more mobile-palatable.

@TazeTschnitzel agreed, but then what would fb engineers do all day? they gotta "keep shipping"

because they're a big company with a lot of staff, everything they do must therefore be "the right way"? That's a fallacy if i've ever heard one.

True, but it's incredibly easy to play "armchair project architect," when you don't actually know anything about how a project works or its requirements or constraints.

Maybe this is a personal flaw, but I can't count the number of times I've looked at a project and thought "that's a stupid way to do it" only to later realize the problem is far more nuanced than I thought.

While that is a problem, it wouldn't solve the uncanny valley problem with scrolling either way.

Standards for correct UI feel on iOS are extremely high, and you are looking at spending more development hours trying to create a write once run everywhere platform than just writing native code.

Huh?

I'm talking mobile web, not HTML5-written faux-native apps.

I see. Point still stands. Their timeline and newsfeed scrolling are still going to be problems regardless.

I'm unconvinced. Web pages scroll fine for me, why can't the timeline and newsfeed?

Scrolling and js performance differ radically between web pages in mobile safari and uiwebviews on iOS.

Because it's infinite scrolling. They add stuff while you scroll. That's much more difficult to make smooth.

Here's an insightful and rather good approach (at least to me when I tried to implement something along the lines of this): http://engineering.linkedin.com/linkedin-ipad-5-techniques-s...

Why can't they just load when you reach the end? I've found this tends to be what happens for me, anyway.

They could do that, but they don't want to. Their point is that web technologies can't deliver the experience they want. Telling them they want dumb things is not a legitimate response, especially as they can get the experience they want using other technology.

Seems like an issue they've struggled to solve unsuccessfully, and it's a pretty big problem for a core feature of their product unless they change the UI altogether for how they present the feed. Is there an example of an infinite scroll UI that pre-fetches text / image content on mobile web without the uncanny valley problem?

It's not all low-hanging fruit. The easiest way to pull in lots of code is make a library call. Libraries can depend on other libraries and how much gets optimized away is difficult to predict. Without good dashboards for watching the codebase and its effect on runtimes, it's easy to pull in too much.

Profilers and other performance tools allow people to make rational decisions about when to cut back, rather than groping around in the dark.

You have to make a trade-off between simplicity and user expectations though.

For example, 6 months before the iphone was released we developed a mobile app at my work that was universally compatible. It ran on the lowest WAP2 phone you could imagine, by virtue of not using any javascript, using nothing that wasn't in the XHTML basic standard, and putting few controls on each screen.

And then the iphone happened and our users very vocally told us that the look and feel of this app was not acceptable. So, we built a version that runs only on modern smartphones and a very narrow range of browsers, but users are ecstatic about it, even though it does exactly the same things as before.

This does not have to be a theoretical debate. Facebook content is available via their API. Most of the writes (liking, commenting, status updates, check-ins) are also available via API.

Reply on news.ycombinator.com