Live data from Hacker News

Making Facebook's native mobile app faster using HTML5

sencha.com

161–166 of 166 posts

Re: Making Facebook's native mobile app faster using HTML5

#161
post #160

Earlier quoted context omitted.

Wait, your position is that it's impossible to make web apps function identically across different platforms?

In a consistent way down to pixel level in a 1:1 correspondence to Photoshop designs required by customers, across all required browser versions in all required operating systems, yes.

A pain? Sure. Impossible? Not by a long shot.

A few points:

1. The main discussion here was about HTML5 based apps using a native web-view app wrapper. That makes "OS version" and "browser version" identical, and puts you in an identical position to native apps in terms of number of platforms to deal with.

2. Even if you're dealing with multiple browser versions, there isn't very much difference between how a given version of a modern browser behaves under different OSes. And if a page works correctly in an old version of a browser, it is very unusual for it to start working incorrectly in a newer version of that browser.

3. Maintaining a single code base with special cases for different platforms is way easier than maintaining multiple disparate code bases. It's the old DRY principle.

The fact is this: writing an app and supporting multiple OSes (even multiple versions of the same OS) is hard. Doing so while making everything pixel-exact across different platforms is really hard, and usually pointless. But the idea that it would be somehow easier when maintaining entirely separate code bases is ludicrous.

Re: Making Facebook's native mobile app faster using HTML5

#162
post #160

Earlier quoted context omitted.

In a consistent way down to pixel level in a 1:1 correspondence to Photoshop designs required by customers, across all required browser versions in all required operating systems, yes.

A pain? Sure. Impossible? Not by a long shot. A few points: 1. The main discussion here was about HTML5 based apps using a native web-view app wrapper. That makes "OS version" and "browser version" identical, and puts you in an identical position to native apps in terms of number of platforms to deal with. 2. Even if you're dealing with multiple browser versions, there isn't very much difference between how a given v…

1. I don't understand wasn't the HTML5 model the portability everywhere? So why the constraint to mobile devices now?

2. It is always fun to see junior developers learn the quirks of CSS across browser versions of the same browser.

3. No different than methodologies for writing portable native code with the added benefit of control and performance.

> Doing so while making everything pixel-exact across different platforms is really hard, and usually pointless

Have fun talking to our Fortune 500 customers doing pixel counting on web applications, before signing the pay-check.

Re: Making Facebook's native mobile app faster using HTML5

#163

Earlier quoted context omitted.

Even when browsers are powerfull enough the mess what is trying to shoehorn technologies created for hyperlinked text into apps development will still be a mess. It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks. As for the appeal "run everythere"—that's just some more quirks. Good luck with th…

>trying to shoehorn technologies created for hyperlinked text Genetic fallacy. For 75% of its development, HTML has been taregeted at greater things than hyperlinked text. >It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks. I would say the opposite is true. Native doesn't protect you from quirk…

Adding forms in 1995 did almost nothing to change HTML from hyperlinked text documents to anything resembling modern web apps. It took about a decade before (somewhat cross-browser compatible) asynchronous Javascript appeared on stage, what changed the whole game. 10 years of forms gave us rainbow sparkle generators and rudimentary webmail. Then 7-8y of "AJAX" gave us a generation of kids that truly does no longer intuitively grasp the difference between native apps and web apps.

While the form element was probably a great improvement (I wasn't there, not until '98 until my first steps in HTML), think about literal meaning of the word "form" for a bit. It's still a document. HTML was normal documents with hyperlinks in it, add form elements and now you also got fill-in document with hyperlinks.

Yes you could potentially make web apps that way, but everything (everything) required a server-roundtrip. It may be a hard to imagine what a far cry that was from what we now consider a "web app". Every single UI change had to go through a form submission request and a response from the server that contained the entire page regardless of what was updated. "... but .. frames!", I can hear you wonder, well IMO frames weren't all that. They didn't really make selective updating possible in pretty much the same way as forms didn't really make web-apps possible either. Plus, I can't remember if there's been any time people weren't hating on frames (it broke navigation and bookmarking--sound familiar?).

I say this, because I remember discussing the idea of web-applications in 2002/03 or thereabouts with a friend in college. I had just discovered the SCRIPT SRC trick so you could actually load data from the server without reloading which was paradigm-shattering magic, at the time (the technique is still in use as part of JSONP, btw). I had already written a chat-client and it was beautiful, I wanted to pick his brain for more ideas of what to do with this new ability.

(please remember, this discussion occurred during the height of the Browser Wars, 1-2 years before the tide started turning. if you weren't there, or doing webdev at the time, imagine it 10 times worse. digital trenches, man)

My friend told me pretty much the exact sentiment I see pop up in this thread here, that HTML was intended as a document markup language, not for application building, and that while we could hack all these cool interactive features on top of a markup language, and surely these were some quite impressive feats of creative thinking, it would always remain on shaky grounds because you should build an application framework from the ground up with application framework foundations, not by bolting things onto a markup language. Back then, I knew this to be true (one picks up a few things about software design, studying CS) even though I didn't want it to be, because the tech was so cool and the possibilities so enormous (hackers should be able to relate to that feeling :) ).

Now, many years later, I got what I wished for, and my friend got to be right.

(at some point CSS and JS incompatibilities started to slowly disappear and the Browser Wars came to a sort of uneasy peace--this was a slow realization I can't really say when it happened, but I don't have to resort to black magic anymore to write a basic webpage that works in FF,IE,Chrome and Opera--particularly if I write it in Opera first)

Looking at the state of web-apps today, we are using that technology ("AJAX") to build things beyond my (I won't say "wildest") imaginations back then. But it's still clunky here and there. Javascript is still a pretty crummy language (though I love coding for that weird prototypal beast), and as soon as you write more than 5 lines of DOM-manipulation, you're going to want a framework like jQuery. And for some mysterious reason, people still manage to write JS code that works in one or two, but breaks in the latest versions of other major browsers. Minefields are hard to clean up I guess. There is more, but you get the idea--and IMO a lot of the problems can be traced back to bolting application-behaviour capabilities on top of a document markup language.

Still, I do believe we're heading in the right direction. Things can be made much cleaner than say 5 years ago, and there's new standards looming on the horizon that may make things even better. Sure, a from-the-ground-up design would have been so great and so clean. But the industry would have probably found a way to crud it up regardless. And given the global scale and heterogeneity of the Internet as a communications medium, the immense market forces that come with such an environment, personal computing capabilities over time, maybe this was the only way it could've been pulled off, who knows?

Re: Making Facebook's native mobile app faster using HTML5

#164
post #162

Earlier quoted context omitted.

A pain? Sure. Impossible? Not by a long shot. A few points: 1. The main discussion here was about HTML5 based apps using a native web-view app wrapper. That makes "OS version" and "browser version" identical, and puts you in an identical position to native apps in terms of number of platforms to deal with. 2. Even if you're dealing with multiple browser versions, there isn't very much difference between how a given v…

1. I don't understand wasn't the HTML5 model the portability everywhere? So why the constraint to mobile devices now? 2. It is always fun to see junior developers learn the quirks of CSS across browser versions of the same browser. 3. No different than methodologies for writing portable native code with the added benefit of control and performance. > Doing so while making everything pixel-exact across different platf…

>1. I don't understand wasn't the HTML5 model the portability everywhere? So why the constraint to mobile devices now?

Ideally, HTML5 apps would automatically be completely portable everywhere, but that ideal isn't realistic. HTML5 is still great for simplifying porting (which is not to say that it is without disadvantages) because it gives you a single code base that behaves nearly identically everywhere, and then you have to tweak it. Constrain your problem to a couple of mobile browsers, and the number of tweaks drops dramatically.

Now I understand the draw of simply maintaining separate code bases. It's the same draw as the urge developers have to rewrite a project from scratch. It feels like starting with a clean slate will be more efficient than hunting down and eliminating every blemish. But that's an illusion. Working from a clean slate, you'll still be tweaking out blemish — it'll just take longer before you even have the privilege of thinking about them.

>2. It is always fun to see junior developers learn the quirks of CSS across browser versions of the same browser.

Oh, they're there. But in aggregate, they aren't as bad as working across different native platforms.

>Have fun talking to our Fortune 500 customers doing pixel counting on web applications, before signing the pay-check.

Yes, I realize that some clients require it even though it's usually pointless. Some companies have more money than sense, after all. My point was that it's hard no matter how you develop the app.

Re: Making Facebook's native mobile app faster using HTML5

#165
I'd say the problems the Facebook team ran into were related to the universal difficulties of HTML5 development. The tools are nothing compared to native app development. In making native apps, developers can visually create the GUI, double-click an element and immediately program its response. But with HTML5, everything is done programmatically, with great pains. When you run into problems you have to debug JavaScript, CSS, HTML, and any client libraries, possibly written in yet another language. The tools just aren't there, so continuing to maintain an HTML5 app that performs quickly and nicely like "Fastbook" does is far too costly, considering how much more easily a native app can be created and maintained.

Re: Making Facebook's native mobile app faster using HTML5

#166
post #88
post #10

Why do we see plenty of articles saying that HTML5 can be as good or better than native code and no actual applications doing it? Facebook and Google tried and miserably failed, LinkedIn and Twitter are probably the ones closest to actually doing it, but users still prefer the native version, why? One I think is a big reason is clearly visible in the video: scrolling physics are different. It's annoying and feels wro…

We've yet to see a web app that meets or exceeds the experience offered by native desktop apps. Natively built apps are almost always "better" because they're closer to the OS and implement the native UI conventions. At the same time, web apps are almost always cheaper, because you don't have to develop for each platform from scratch (or suffer a lowest common denominator experience by using a cross-platform non-web…

Why would a HTML5 app need to exceed the experience of a native app ?

It needs to meet the needs of the user, that's all.

And if that can be done with X-platform HTML5 then that might be the advantage the developer is looking for.

Post reply on HN