Slashdot Mirror
Facebook iOS App Ditching HTML5 For ObjectiveC
Wrath0fb0b writes "The New York Times reports that Facebook is overhauling their iOS App to ditch their HTML5 based UI for a native ObjectiveC one. This is an about face from their position a few months ago in which FB said HTML5 would allow them to write once run anywhere. While WORA certainly has a lot of appeal for both programmers (due to desire not to duplicate effort) and management alike (due to desire not to pay programmers to duplicate effort), the large number of negative reviews that FB for iOS has illustrate that this approach is not without drawbacks. No matter how the new app is received, this is more fuel on the native vs. web-app fire."
Native code is _always_ better.
..don't panic
Has appeal in theory (and sometimes practice); looking great on paper, but it is easy to get swept up in enthusiasm for the concept and not really think though how applicable it is to any given environment.... and even when it does work it is pretty rare for something to truly 'work anywhere' in the real world.
Weird, their web browser app is what I use since their app sucks. Guess this is why?
They're having trouble returning a few hundred lines of text and 10 photos. Methinks HTML rendering speed is not even remotely their problem.
That's good, but I don't think it's fair to blame the poor quality of Facebook's app entirely on HTML5. For example, the app will occasionally chew through hundreds of megs of space, crash randomly, or even navigate to the wrong page when you click a link. Pretty glaring bugs that even the greenest QA testers would have noticed.
At some point you have to blame management for not spending the time for proper testing and bug fixes. It *should* be a fairly straightforward app no matter how it was written.
There's no -1 for "I don't get it."
If it were purely about performance, then they could just use web services to grab the data they needed, style it on the client side and run it in an HTML control. How would drawing content using a native app help performance if the data requirements are the same -- rendering HTML isn't *THAT* slow on iOS, is it?
And with a web app, they have far more control over QA and the release process, and can potentially turn around minor updates much faster than if they had to jump through the App Store release process.
OTOH, they think they have a problem, then good for them. The current client has been buggy for me for quite a while, with navigation buttons sending me to random parts of the application -- they clearly have QA issues that aren't going to be helped (and likely will be made worse) by an app rewrite.
Debug Everywhere . . .
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
They are a multi-billion dollar company dealing with an app running on one of (if not the) most relevant and widely-used smartphones in the market. They should dedicate a team specifically for the iPhone. And if Apple changes the API every week, they would be wise to rewrite the app every week just to maintain that market.
I don't care for Facebook and have my issues with Apple, but this is just a business decision on ROI.
Write once, run anywhere? Didn't they say that about Fortran? Write it all in Fortran and get off my lawn.
Ray Seyfarth, ray.seyfarth@gmail.com, http://rayseyfarth.blogspot.com
This is just Facebook trying to blame their shoddy implementation on someone else.
None of the bugs and issues reported by users are HTML5 caused problems.
I'm out of my mind right now, but feel free to leave a message.....
I think the problem with the Facebook "app" was that it didn't seem to store anything locally -- meaning every UI event involved a request over the internet, which does not make for a responsive UI.
This is just Facebook trying to blame their shoddy implementation on someone else.
None of the bugs and issues reported by users are HTML5 caused problems.
(You are absolutely correct. I was being ironic.)
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Does the Android version use HTML5 as well? Because it is beyond horrible. I can't figure out why the app would actually be SLOWER and harder to deal with than viewing their site on a browser, but somehow they have managed it.
UI Rendering speed is exactly the same for native code and html elements. The reason is, guess what browsers do to show you lists, buttons, drop down boxes, etc?? They use *NATIVE* UI elements. It is plainly obvious you understand nothing on this topic.
The issue is UI *latency*. HTML based UI cause increased round trips from mobile devices to their data-centers creates a terrible experience for users when compared to native apps. Mobile devices already are worse off when it comes to network latency, and this exaggerates the problem.
HTML + CSS + JS is the worst "modern" paradigm to base any kind of UI on. Don't get me wrong.. its also a horrible data/text layout language too. It can't even do what layout programs used for producing magazines 50 years ago did. Not to mention the standards themselves are so horrible that nobody in the entire world has ever in the history of standardization been able to produce a reference implementation. And judging by the several hundred KiB sizes of webpages these days, it would be more efficient if you just hosted a damn PDF file, at-least it would look the same everywhere.
In reality, your logic and communication bits should be abstracted anyway - isn't that the hallmark of good programming practice?
I agree in principle. However, sharing components among versions of an application for different platforms works only if all the platforms can run programs written in the same language, and in practice, there are a lot of platform pairs that lack a shared language. For example, how do you share a component between an application for Windows Phone 7, which runs only C# and other languages that compile to verifiably type-safe CIL and do not use the DLR, and the corresponding component for iOS, which runs Objective-C++? Xamarin's answer is to let the Windows Phone 7 port dictate the choice of implementation language for all platforms. This way, components shared with an application for WP7 run in Xamarin's CLR reimplementation for non-WP7 platforms, which Facebook can afford but many individual developers cannot.
Ask any Mobile Developer, simultaneously writing for iOS and Android.
The need for the Android NDK (Native Development Kit) answered that question. Java-like approaches are fine for certain classes of apps but for many classes native is better.
fix what's broken and allow the same functionality as the website. I hate it when apps like Pandora, FB, or even G+ or any others that have an app and a website where the website gives you many more options. They only give you the basic experience on the mobile app and am still tied to a computer for doing anything more than basic.
It seems to me that the Facebook app's issues are not so much about HTML5 performance, but rather the way that they handle transactions with their servers. The network performance of the app is atrocious. Look at the traffic of the iOS app and compare it to the Facebook mobile website. How many hundreds of XMLHTTPRequests do you think it should take to render a page?
There's nothing inherently wrong with the HTML5, it's their ludicrous network activity that kills the app.
Given that Apple is integrating FaceBook support into iOS 6 (I've got it on my phone right now, and the 'post' button works exactly as advertised), it seems to me that this is probably being done in no small part because Apple is doing a bunch of stuff in Obj-C anyway. I have no idea what the FB API stuff is like (or even if it's available to devs like me) but there's clearly *something* going on under the hood.
So Apple does some of the heavy lifting, and the FB programmers just piggyback off of it. At that point, why not switch?
They dropped Flash not due to "performance and battery" issues, but simply put that Flash would eat away at Apple's walled garden.
Having experienced Flash on Android, I think you're mistaken. And the fact that Adobe basically gave up on making it useable on mobile devices supports Apple's stated position.
#DeleteChrome
If 50% of your modules have GUI calls, you're developing your software wrong. MVC isn't just for webpages. If you have UI specific code in your business logic, you fail.
If the GUI code is more than a tiny fraction of your overall code, you're working on absolutely trivial software. I can't say I've ever worked on a GUI app where the GUI itself was more than 5-10% of the code.
Basically, there's two ways of writing cross-platform apps:
1)Write your main business logic as a library. Then for each platform, write code that runs the UI and calls it as appropriate
Pros: Can take advantage of all the features of the OS, and make a customized experience for it. Easy to fit in with design standards for the OS. Minimizes bugs due to differences in APIs and capabilities between platforms.
Cons: May not be possible to write the buisness logic in this way, or may not be easy. May require ugliness in the business logic to do so. May be hard to maintain the line of abstraction between the two halves, depending on how the platform is implemented.
2)Abstract away the UI and OS specific calls into a library, and implement them for each OS.
Pros: Easy to do, with a little bit of discipline. It's always possible to do it this way, and *if* you can implement each API call so they act identically on all platforms then maintenance is a breeze and no ugliness in the business logic.
Cons: Subtle differences between how platforms handle common APIs can cause bugs. Differences between how they handle less common APIs can cause major issues. Cannot take advantage of advanced OS specific features, may not be able to follow UI standards for each platform. You'll end up with features not working on some platforms if they don't provide a needed API.
It's probably about a 50/50 split between the two paths (and I won't suggest a path, it really depends on your code and target platforms). But this is how it's done. And in either case, in fact in ALL well designed software the GUI is far separated from the business code.
I still have more fans than freaks. WTF is wrong with you people?
FB can afford to piss away money on a proprietary app now that they're a multi-billion dollar company. The vast majority of companies can't. I just don't see a huge resurgence of native apps replacing web functionality. Very few companies have the resources to develop for multiple platforms like that, and you really can't afford to just ignore android, or whatever else comes out into the mobile world in 5 years.
AccountKiller
Yeah that's true. But the iOS Facebook app is an exception, it's really just a frontend for an HTML5 site and it's super-buggy, slow and annoying. So I'm glad they are rewriting it.
You should write (or recommend) a tutorial called "JavaScript for Jquery developers" which shows the standard cross-platform-compatible JavaScript equivalent to the major JQuery functions.
The Web is like Usenet, but
the elephants are untrained.
Apple's formula for success under iOS:
1. Control the hardware
2. Control the software
3. Make others do the work and because (1) and (2), you get to take a BIG cut of their business. No, not BIG... HUGE.
Part of (2) is to not allow any development that might result in GOOD write-once/run-anywhere software. Backing HTML5 is a perfect example. The amount of effort required to produce a decent product is just plain insane. Even big companies like Facebook can't do it. Little companies don't even try. In the end, damn near everybody who tries to deploy an application that runs on an iOS device comes to the same sad realization: cough up the dough or go home.
Products that actually worked, and worked well (e.g. Flash, Silverlight, etc.) were killed with feeble excuses like battery consumption and quality control. How the DoJ didn't launch an investigation into anti-competitive practices is a mystery to me. The "browser included in OS" investigation of Microsoft seems a pale shadow of the "you don't run software on iOS devices- despite the fact that their OWNERS want you to- unless you pay us a shiatload of money." /Bitter? You betcha.
Wow, that's lazy. So I guess you didn't have anything specifically in mind then?
Let's start with the biggest one: selectors. Hey, that was the whole reason jquery was written, right? .querySelector and .querySelectorAll work in all major browsers and has had broad support for years.
The most common case I see jquery abused is selecting elements by class name. Of course, most of the time it's used instead of a more appropriate solution, still, it's a popular use. .getElementsByClassName() has been around, again, for ages. For older versions of IE there is the ever popular "Ultimate GetElementsByClassName" function.
Now, in place of these well-supported (yet surprisingly little-known) functions jquery gives you a bit of illegible code:
Say you want all the elements with a particular tag contained inside another dom element.
The javascript way, works cross-browser:
var mystuff = document.getElementById("myform").getElementsByTagName("input");
The jquery way, requires useless bloated library:
var mystuff = $.makeArray($("#myid input")); // because $("myid input"); won't give you an array.
The difference? One is obvious and readable. The other looks like Larry Wall's used TP and requires a bloated poorly-designed library
Required reading for internet skeptics
Nope, I'm going to stick by my original statement. In 11 years of professional development, the majority of which had a GUI in some shape or form- 10% is the highest I've ever seen, the average is probably on the order of 3-5%. GUIs just aren't that hard to write and don't really do that much.
Using a 3rd party library can work as well- if your platform supports the toolkit you want to use, and supports it well. Swing last I checked was a nightmare that never worked the same on any two platforms. I'm going to assume it's been fixed, as it's been years since I've used it, but trust me, it was shit. Tk looks like shit on all platforms, it's an ugly UI. It's good for a quick one off, but you'll never see it in professional software.
Then there's the question of what OSes you target. If you ever want to target a proprietary hardware OS, all of those get thrown out. They won't work, and porting them would take more time than rewriting by orders of magnitude. Nor would an OEM selling your stuff ever want to bloat the ROM with a whole QT library. And don't forget, until about a year ago the phone market was dominated by proprietary OSes, until Android came.
Then there are the smartphone OSes- Android, iOS. They don't support any of those. So once again, you're back to not using them.
And in the end, that's why you don't use them- because they aren't truly universal. Because you can't count on them being available on the next port. And the tiny cost to encapsulate the small amount of functionality you actually need is well spent to have the flexibility to say yes when an opportunity to port to a device for a few million comes up.
Now if you're only porting to Windows, Mac, and Linux you're probably good with one of those libraries. Which are all those 3 run on.
I still have more fans than freaks. WTF is wrong with you people?
This is definitely true. The Financial Times native app got replaced with a nearly-equivalent HTML5 "app". Safari asks for permission to store extra data locally, and then it generally feels pretty responsive (relative to other news apps, which in all honesty feel a bit bloated). I'm not sure how compatible it is with other platforms, though - it might have a bunch of really ugly ipad-specific hacks behind it, who knows.
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
In jquery, if I wanted to do something with each element with a particular tag contained inside another dom element, I'd do something like this:
Or perhaps like this:
In bare javascript I'd have to write a loop, either recursively or iteratively.
Anyway, I don't see javascript libraries going away anytime soon. Bloated? Maybe. Useless? Depends on your point of view. If you're really dedicated to luring programmers away from jQuery, I suggest you write (or recommend) a reference such as I suggested. Otherwise, you're just making noise in an inappropriate forum.
The Web is like Usenet, but
the elephants are untrained.