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.
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.
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.
New here?
..don't panic
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.
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
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.
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.
Sounds like a problem with the iphone to me....
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.
They are not even talking about PHP or Ruby , this is app development using HTML 5 which can live on as a semi-native app on iOS which has nothing to do with server/network performance. BTW that moldy old C/C++ code is the reason why Ruby and PHP works in the first place.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Maybe they should have wrote the iTunes in flash.
Sure, many find it useful anyway, but theirs is not a technological problem.
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?
I don't use facebook and do not worry about it.
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
so would a Cordova-based approach (where the html 'server' is located locally) make a much better user experience? ie, write a 'thick client' app using HTML technologies rather than a traditional web page that is squeezed into iOS size.
Maybe they should have wrote the iTunes in flash.
In this case, I'd bet it would be faster, assuming you could emulate flash.
I don't know, but it works for me.
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?
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
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.
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?
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.
"Ah yes, submitting boxes of cards to the operator and waiting for output - those were the days." I knew turnaround time for jobs was long, but it took days?
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.
iOS seems to have HTML5 local storage available, Facebook just chooses not to use it.
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
Usually caching data is 1-2 lines of code in the programming languages I work with. Not sure about what you are referencing. If you had to manually program a cache in every programing language you would be right. But that is one of the problems that is typically solved for you. It's like serializing data to XML or JSON. I am not personally writing code to do that, but there is a library that does that.
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?
In reality, your logic and communication bits should be abstracted anyway - isn't that the hallmark of good programming practice? ..and even then there's performance tradeoffs.
Yes. That is called "Client side programing". Which if you look at the original post that was what we were talking about. Accessing data is effectively the same if it's cached or not.
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.
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'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 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.