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
Thank goodness. Every app that I see on my iPhone that uses HTML to be portable suffers horrible performance. This includes FB, but also the iTunes store. Over the past few months, the iTunes store has become almost useless on my iPhone 4. FB was among the worst, but it did recently get much faster when they apparently upgraded their servers. It's still crap, don't get be wrong, but it's a good deal better than it was a month ago.
I don't know, but it works for me.
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.
They should have done the native implementation first.
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.
Real editing would allows me to take Slashdot seriously. Slashdot wonks suck at their job.
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."
Re:Ask any grey beard. Native code is _always_ better.
Ask any game developer, well those working on anything beyond the simple casual game segment.
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.
Fuck Facebook.
This will be the first nail in the FB coffin.
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.
What on earth is their app needing to do that native performance is required?? No thanks, i'll just visit the site.
But... isn't html 5 the latest and coolest thing, and Objective-C some really old thing that Apple inherited from medieval times?
And and... hang on... wasn't the coolness of html 5 the excuse for Apple not supporting some old and crufty thing called Flash?
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
The UIWebView on the iPhone is plenty snappy enough.
I venture to say their network communications layer is poorly implemented. The app is a memory pig. The app is a battery pig. It is 10.5 MB for what? A portal to browse the FB website. Seems way over-engineered to be that big and have a little functionality as it does.
....and he departed FB or said he was done with iPhone development or some other small-scale hubris?
Part of me thinks that FB doesn't really *care* if the iOS app works, they just want to know what platforms you use FB on and if they see regular use from an iDevice, they know that you fit in a specific demographic bucket of "iPhone owner".
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
Facebook is google's enemy
they are frenemies with Apple
why support HTML5 which also supports your enemy when you could make your frenemie's platform "better" with a native app and hurt your enemy
Will Facebook have to pay Apple if people use the new Facebook App Store?
...for those of us who choose to accept ad hominem fallacies, isn't switching to ObjectiveC a bad idea just because Facebook programmers think it's a bad idea?
I kid! I kid! C'mon, I admitted that it's a fallacious argument!
...on the desktop and handset.
Many performance issues with Ruby or PHP can be dealt with by adding more or bigger servers, but you can't throw more hardware into the consumer's handset (s/he can, but you can't).
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.
Its just that using HTML to build "native" apps for iOS has been proven to be poor over and over again.
Apple just does not want ANY competitive technology to shine on iOS. They dropped Flash not due to "performance and battery" issues, but simply put that Flash would eat away at Apple's walled garden. Building HTML apps that can be easily ported to other platforms wasn't going to be something that worked better then native iOS apps built for the walled garden.
It comes down to whether you want to be cheap and dirty or invest some time and effort into taking advantage of the native platform. There is no reason for Facebook to be cheap and dirty, they can hire a corporation worth of developers for each platform if they wanted to.
But if you are staring out and want to target all platforms but do not have the technical know-how or man-power to be able to write native apps for each platform, then use HTML, just don't be surprised when it is only an "acceptable" solution.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Sure, many find it useful anyway, but theirs is not a technological problem.
Mobile devices just don't have the CPU power and battery life to do HTML5 anywhere close to the efficiency of native code. WebOS made this point painfully clear many years ago.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
The standard way to write a cross-platform app is to write the main logic in C++ or C (which is pretty portable), then to write the UI in whatever the platform is forcing you to.
I agree, so long as an application is limited to Windows, Mac OS X, X11/Linux, Android, and iOS. So what's the best practice to introduce Windows Phone 7 into that mix? It only runs C# and other type-safe managed languages that don't use the DLR. C++/CLI doesn't count because any nontrivial C++/CLI code that will compile with /clr:safe is a syntax error in a compiler for Standard C++.
The only non-portable parts of the engine I work on are a few lines of startup code related to the fact that Windows makes modern OpenGL harder to use than most other platforms do.
Do the game consoles and Windows Phone 7 support OpenGL? I thought Xbox 360 and Windows Phone 7 used DirectX, and PS3 used something way off in left field because the OpenGL ES implementation that ships with the devkit isn't worth an expletive. Or is your game PC-only?
Can HTML5 applications for PlayBook or BB10 use a device's microphone or camera? If so, what JavaScript API do they use?
No, FB went public.
Ignoring a major mobile platform, no , ignoring the mobile platform with the user base most likely to spend money, is not an option.
what is proprietary about iOS?
The cryptographic key for verifying what is allowed to run on one's own device.
support for proprietary API's
Some features of the device, such as the microphone and camera, can be reached only through these proprietary APIs, not through Safari.
yes, he used to work for Mozilla. explains everything
he thought he was da sh1t and the app was always buggy
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?
Yeah, yeah, separate the GUI code from the "business logic", but a huge fraction of any GUI app is the GUI. No matter how you slice and dice and refactor your code, a full 50% or more of your modules will have GUI calls in them.
So what do you, create some kind of application-specific but platform-neutral set of GUI calls, and then you write drivers or plug-in modules for each target GUI OS? Instead of rolling your own, you use wxWindows? You program the front-end in Java and using Java Swing (yup, Matlab is a native-code app that does just that?)
Or if you roll your own GUI library that only needs to support widgets specific to your app, yeah, yeah, you don't have to implement the kitchen sink. Or do you? You will need menus and buttons and radio buttons and drop lists and scrollable bitmap canvas plots and vector plots, and pretty soon you are mapping the whole GUI. Which is wx does and also Swing, and those were not trivial apps to develop.
No, I refuse to buy the argument that the GUI logic can be modularized to some small corner of your app that you can rewrite for the different targets. The flavor of your target GUI with respect to the available options and configurations and features will color your entire app.
We had to enter FORTRAN II code on punch cards, hunched over a hot keypunch machine. To see the scope of our DO loops or IF statements, we had to rifle the punch card decks until our fingers bled . . . and we liked it!
Now, I have an Android phone so if it's remarkably different on iOS I could be off base here, but from what I saw of the app, it was exactly the same as the mobile web interface except that it also had access to your GPS and potentially camera. Having an app like Facebook turn on GPS as soon as I logged in was enough for me to limit myself to accessing it through the browser. *tightens tinfoil cap*
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
Apple broke phonegap style HTML5 apps in the last version of iOS.
It now clears any websql or localstorage every time you close the app. Persistent storage does not persist. There was a phonegap plugin that passes through to a native sql database, but now they're saying that's against the rules.
See, the spec doesn't guarantee how long they have to persist the data. So they decided to interpret it as "when the WebView leaves memory, the data is deleted".
Webapps pinned to the home screen will break in the same way. Running in Safari they will work - since it follows different rules. (Launching from a bookmark on homescreen launches an app with a WebUI widget in it - it doesn't launch mobile Safari).
Apple forced this decision by being either a) incompetent or b) just plain coder-hating douchebags.
This also broke the app I was working on. Fortunately, our business solution was "this only runs on Android". We're just sick of the effort, and since it's a biz type thing, this was an acceptable solution.
Actually, the decision was compounded by the fact that Apples shitty mobile devices (til iPad 3) don't have cameras capable of auto-focus, which means it can't scan barcodes with zebra-xing, and we just didn't want to deal with the people wondering why their iPad 2 doesn't work, but this other guys cheap droid tablet does.
Apple does something to break HTML5 based apps with each new release of iOS.
Shitty cameras, shitty hardware, awful software.
I can't wait to watch them slip back into obscurity. They really are setting the clock back about 10 years with their fucking nonsense.
Write Once Run Anywhere is a nice concept but it never works out. One big fault in the concept is the different platforms have different user interfaces, styling concepts, input devices, etc... So you end up writing half of it once and the other half you write it over and over again for each platform you want to support. This is coming from a Java developer too.
http://cappuccino.org/
"Cappuccino is an open source framework that makes it easy to build desktop-caliber applications that run in a web browser."
Learn More About Cappuccino & Objective-J http://cappuccino.org/learn/
Facebook's iPhone app is so crappy I started just using the mobile version of their website in Safari. It's more responsive, less prone to hanging during I/O, and lets me do everything the app did.
A web app UI framework that actually integrates with IB? Wow. I may have to play with that.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
Okay, what are the "major JQuery functions" according to you?
Required reading for internet skeptics
Apple just does not want ANY competitive technology to shine on iOS. They dropped Flash not due to "performance and battery" issues, but simply put that Flash would eat away at Apple's walled garden.
Really? Then why did Adobe themselves give up on a mobile version of Flash? Flash has severe performance, battery, and security issues, and Adobe had been unable to produce an acceptable mobile version after years of trying. As Jobs put it in his infamous "Thoughts on Flash" piece, Apple had been waiting for years for Adobe to produce a version with acceptable performance, and was no longer willing to wait after all their promises came to naught.
And it's not about competition. It's about control. Apple makes no bones about being loath to rely on any critical technology they don't control themselves. Apple's memory is long, and they remember how many years it took Adobe to release an OS X-native version of Photoshop, one of the flagship applications for Macintosh, and as Jobs said, it was unacceptable for Apple to have to depend on the update schedule of a third party in order to add features to their own products. It's about control of the vertical stack in order to deliver an experience they deem acceptable, not competition. Locking out potential competitors isn't their major focus; it's just icing on the cake.
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.
The ones with their own documentation page on jquery.com.
The Web is like Usenet, but
the elephants are untrained.
I think a big part of the problem is Mobile Safari. If you look at any applications that integrate a web view on iOS, you'll notice great slowdowns when there is a lot of graphics in the page and scrolling. I see it on my iPhone all the time. (iPhone 4)
Then consider that Apple hasn't done a serious Safari update on either desktop or mobile for quite some time. Safari on OS X is even slow.. compare it to Chrome or Firefox. It's pathetic. Apple needs to push a new build out to everyone ASAP and I'm not talking Mountain Lion.
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
Yes, a general purpose UI and OS abstraction framework is a non-trivial software development undertaking, and one starts out saying, "My app doesn't need the full feature set of Swing, so I will code a UI and OS abstraction library specific to my problem domain, and that won't be too complicated. Start adding features to your GUI and that sentiment starts to feel like Custer's initial assessment regarding a military engagement of Sitting Bull's fighters being no big undertaking.
I am also saying that if your GUI is below 10 percent of your code, you are working in a problem domain where your GUI doesn't have a high feature count.
I am also proposing method 3) Write your GUI in Swing (or wx, Tk, Qt, . . ., but don't reinvent the platform-independent abstraction of the GUI widget set) and keep your legacy "business logic" in native code. That is what Matlab, Maple, and Mathematica do.
It's called web services, that return a standard format like JSON, or XML.
How well do they work with zero bars? Or must all offline logic be rewritten from scratch for each platform? That'd violate Don't Repeat Yourself.
If you are making an application that doesn't know about the rest of the world, you can either have your application cache it's static data--which is not that hard.
But if platforms don't share a language, all the logic to interact with the cached data has to be rewritten (which is an error prone process) for each platform.
If you want facebook to be an application that does status updates of your imaginary friends I'm sure that'd not be that hard to make, as long as you wanted them to have a limited set of things they were doing.
Wait a minute: are you talking about Animal Crossing?
That native vs web app debate was never about performance, it was always about politics. Of course native client side is a million times better but politicians don't like you running anything on your own computer and are trying to push the cloud. What they're effectively trying to do is put farms on top of clouds in some magical pixie fantasy where the farms float so elegantly like castles in the sky - politics I'm afraid.
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.
It doesn't happen as often, but back in the day id coded games cross-platform, and certainly beyond casual games.
"Native code" has two interpretations. One is native code from the CPU's perspective, as opposed to Java-like code which targets a virtual machine not the actual CPU(1). Such native code is a necessity for many non-casual games. This is the perspective I was mostly commenting on.
The other interpretation is from the Operating System / Platform API perspective. Here too native code has an advantage. When used appropriately in your user interface code you get the expected look and behavior for the platform. This makes users happy. This sort of native code is not used in the bulk of the game's code, at least when games are properly written(2), hence the ease of porting. BTW, I am quite familiar with the porting process. I have also seen reviews improved by relatively small and modest appearances of platform native things in the UI. It really does help when used judiciously.
(1) Yes there can be another conversion from the VM to the CPU's binary but this does not yield the full efficiency of compiling from source code directly to the CPU's binary as is done in the native code scenario.
(2) This gets complicated. Sometimes it is best to included code for multiple platforms. For example you might target both Direct3D and OpenGL. Today even the folks at id admit that modern Direct3D has its advantages.
$("#myid input").each(function(){$(this).doSomething();});
In bare javascript I'd have to write a loop, either recursively or iteratively
(Oh, no! Not a loop! The horror! Someone might be able to read and understand your code -- then they won't recognize your genius. It's always best to make sure your code looks as much like obfuscated perl as you can manage. jquery is great for that!)
So ... how is the jquery version superior in any way to the plain vanilla javascript version?
var myStuff = document.getElementById("myForm").getElementsByTagName("input");
for (var i=0;i<myStuff.length;i++) { myStuff[i].doSomething(); }
In vanilla version is much easier to read and understand, easier to write, and doesn't require a gigantic library.
What's REALLY funny, however, is that the vanilla version actually requires you to know less about JS than the jquery version!
Sorry, there is absolutely no reason to use that poorly-written pile of garbage.
. If you're really dedicated to luring programmers away from jQuery, I suggest you write (or recommend) a reference such as I suggested.
If you're really dedicated to promoting that useless abomination, I suggest you find some way to justify its use. As for a reference, you might start with JavaScript: The Good Parts. It won't take long before you find out how much time and effort you've wasted learning and using that bloated corpse.
Required reading for internet skeptics
What you, ren-n-stimpy, and AuMatar have recommended may work for Windows Phone, which has already been Osborned, but not for Xbox 360. Xbox Live Indie Games is still just as CLR-only as WP7, and Microsoft has announced nothing about the Xbox 360's successor. Xbox Live Arcade allows native code, but only a few specific publishers are allowed in. Should a video game developer just release a game for Windows, Mac, and X11/Linux, despite it obviously having been intended to run on an Xbox 360, and then later release the sequel for the PC and Xbox Live Arcade once the developer has built a reputation for itself?
You could stoke the native vs. portable debate all you want, but you can also conclude that Facebook's IOS app was just a piece of shit to begin with.
I really don't understand this "we must support every platform even though we can't afford it!" attitude.
Because for some genres, the harder-to-afford platforms are where the market is. Some genres, such as fighting games and party games, are strongly associated with consoles and rarely if ever ported to PCs. Though a few token fighting games such as Street Fighter IV are ported to PCs, most such as Mortal Kombat are not. The traditional PC mindset is solitary: one PC, monitor, mouse, and keyboard per player, as opposed to the console mindset of two to four players having fun together in one room. Despite that the PC can easily support an HDTV monitor and gamepads, nobody actually does that. Apart from Slashdot's geek demographic, almost nobody uses a television as a PC monitor. So instead of starting one's own company in one's own home town to make PC games, one is expected to move to another state, work for a household-name console game developer for several years, and then years later, finally produce the game that one wanted to make in the first place.
It's shorter, both in original code size and in the number of documentation pages required to understand it.
I disagree. So do most of the posters in the thread you referenced.
Thanks. I assume you mean this one. I'll check it out.
The Web is like Usenet, but
the elephants are untrained.
You might think Swing is the "stuff", but there are a lot of major apps in scientific computing and scientific data display that are using it -- the Figure windows and Command window in Matlab are JFrames.
Let's set aside domain-specific widgets that do fancy graphical stuff. Let's just talk about an app that has a bunch of configuration dialogs.
The dialog has OK-Cancel and maybe some other buttons, radio buttons to make some simple multiple-choice selections, drop lists to make some longer multiple-choice selections, edit boxes where the user enters decimal or integer numeric values over a wide range of possible values, clickers for making a selection from a small range of numeric values, maybe some combination of a clicker with text-entry override. So you are going to have a lot of code simply creating all of the widgets, configuring them, laying them out, and hooking them to event handlers. Yes Swing is verbose, but Windows isn't any better.
Then you have code for data validation and for on-the-fly reconfiguration of the dialog contingent on selections. For example, this drop list is only activated if a particular radio button selection is made. Yeah, yeah, the rules for the data validation and for what happens when you select Cancel are "business logic" and should go into some kind of Model or Controller object rather than being rolled up into the View. So then for every action on a widget, you have an event handler in a GUI portion of the code because event handlers are GUI-specific, a call out to the model to update, and a callback or some response from the model, where you have to do the actual housekeeping of updating widget configurations, again in the GUI-specific code.
So you separate the View and Model, having one module that does all of the GUI configuration and all of the event handling too as event handling is GUI specific and another module handling all of the logic of data validation and keeping track of the modal state of the dialog -- which buttons are pressed and which other widgets need to be grayed out. The Model and the View are tightly coupled in exposing long lists of methods to each other to make this work, which bulks up the code and also goes against modern object-oriented programming practice where objects should be self-contained and "know" how to perform the methods that are invoke on them.
By the time you are done, you have a baroque edifice making use of every Gang-of-Four Design Pattern that puts much of the Swing codebase to shame. And by the time you are done, you say, "Aw, heck, let's just use Java/Swing as the front end where he call into our native app using JNI." And that is what Matlab does -- are those dudes stoopid?
The problem, again, is that one can't share any of the client-side programming between a platform supporting only verifiably type-safe, Emit-free CIL and a platform that doesn't support the CLR.
Then you develop for XBox, Playstation OR Wii. Whatever you can afford and is the best market. If the game is a success, you port to the next best market. It's nice if your code is easy to port, but if that's not the reality of the platforms you've decided you want to support then suck it up.
Isn't it about time to admit that HTML (any version) is NOT a development platform? It's great for making web pages, but that's about it. It is limited in scope and performance. Always has been, always will be, and that's fine. Use it for what it's good for, and stop trying to use it to build applications.
It's shorter, both in original code size and in the number of documentation pages required to understand it.
Code size, yes and no. Yes in what you typed, no in what your page needs to function.
Absolutely No to "number of documentation pages required to understand it" As I pointed out, you need to know more about javascript to understand the jquery version than you do the plain js version. You also need to understand css selectors and jquery. I'm not buying it.
Further, the jquery version is harder to read and debug than the plain js version. Sure, it only takes a few extra seconds to parse out the jquery version, but multiply the number of cryptic lines of jquery (you know, by using it in practice) and start the inevitable chaining and you've got a maintenance nightmare!
To save a few seconds of typing you've traded efficiency, readability, maintainability, and bloated the page with a fat library.
Thanks. I assume you mean this one [amazon.com]. I'll check it out.
Yep, that's the one. A few pages you might also find of interest:
Slides from Estelle Weyl's presentation at OReilly's Fluent Conference
JQuery without JQuery
Required reading for internet skeptics
I think a lot of people talk about html5/CSS and JavaScript running in the context of their own pc, which is likely to be at least a dual core 2.4ghz x86 machine. Something of that spec is going to tear through any HTML based UI and make everything look lovely. The minute you go to a low power device (iPhone 4 is a single core ARM processor running at 933hz) whatever whizzy HTML/Js you have written will work way slower.
Apple get over there slow Processor issues by using things like CORE graphics that utilise the GPU to draw to the screen. They've spent a lot of time smoothing things over at OS level to make things look smooth. But most of that is not available to the web renderer in the UIView that apps have to use to draw HTML and execute JS in.
I just think FB thought they were flogging a dead horse either trying to wait for apple to improve HTML rendering speeds for UIView and felt they might as well go native. If HTML was really the best solution for apps companies like Path would be using that already. The fact that they don't and companies like FB and Google have tried in vain shows more about politics and the desire for them to be in control of their platforms rather than HTML/Js is best for GUI development.
I'm aware of multitier architecture. But when an application is running offline, all tiers still have to run on the local machine, and the logic and data tiers can't be shared between platforms that do not share a language.
And you want to run Facebook in offline mode because...?
Because I want something to do for an hour on public transit without having to pay $600 a year for mobile broadband. Back when e-mail and Usenet were still popular, a user would download all new messages from a POP3 or IMAP server and download new posts in the groups to which he subscribes. Then he would read the messages while offline, compose new messages while offline, and schedule them to be sent next time he connects to the Internet.
Then you develop for XBox, Playstation OR Wii.
All three of those platforms are hard to afford. As far as I can tell from how I interpret the developer qualifications of the three big console makers, a company's first game must be for either PC or mobile before the console maker will even talk to the company, and a lot of genres aren't practical on either PC or mobile.
It's shorter, both in original code size and in the number of documentation pages required to understand it.
Code size, yes and no. Yes in what you typed ...
Most of the time, that's all I really care about.
Absolutely No to "number of documentation pages required to understand it"
I disagree. I only had to reference two jQuery doc pages to write my version. I'd have a harder time finding the two doc pages needed for your version, plus I'd probably glance over the reference for Javascript looping constructs since I don't write in that language every day.
As I pointed out, you need to know more about javascript to understand the jquery version than you do the plain js version.
Again, we'll have to "agree to disagree". I may never know enough about Javascript to understand (and/or replicate) the entirety of jQuery, but I know how to use it. To the casual driver, an automatic transmission is simpler to use. Most mechanics prefer a clutch because more efficient and easier to repair. I'm a casual driver, not a mechanic.
A few pages you might also find of interest:
Slides from Estelle Weyl's presentation at OReilly's Fluent Conference
IE9 won't show the third and subsequent slides, and my Linux box is in the shop for repairs, so I'll have to check that one out later.
JQuery without JQuery
Precisely the reference I was requesting several comments earlier. Thanks.
...that it runs faster in the end.
I know absolutely nothing about coding in either HTML5 or Objective C but I do know as a user that the Facebook app for iPhone is terribly slow and laggy and from people I've asked, this is typical.
Please, tell me, will this mean Bette performance?
It's not ObjectiveC, nor Objective C. It is Objective-C. Congrats to the two of you who got that right. The rest of you, please don't code in any C-based languages, your lack of attention to details would be disasterous.
these days just about every kid with a mobile phone is always connected to the net, get with the times.
Some kids have rich parents. Other kids have working class parents who can't afford the monthly bill for a smartphone, so they buy dumbphones instead.