Hybrid or native?

Recently Facebook decided to relaunch their iPhone app built natively with Objective-C. This is a departure from the so-called “hybrid” app they had before. It was partially native, but by and far a lot of the interface and data views were done in HTML5. But as most people said, it was slow and jittery.
They haven’t updated their Android version yet, but one can only assume that is around the corner as well.
There are pros and cons to either method. Native apps are always going to perform better. That’s the age-old story on computers. When I was coming up in programming, it was “Java runs everywhere! But applets are slow as hell.” You can change “Java” to any other system competing with native apps and the mantra is the same.
However, building completely natively is a pain in another regard. To have to code natively on every target device you want to be on significantly increases development time. More devices, more code, more testing, more UI development. Facebook obviously has resources to spare, but smaller companies do not. Smaller companies often choose hybrid apps, or even native wrappers, to speed up development and keep costs reasonable for their clients.
HTML5 and webkit browsers will get better. But so will the hardware and native code. Maybe the only chance a true great hybrid app development cycle would be if Apple/Google created said path. Right now we rely on third-parties to create these paths (Phonegap for instance). But they have limitations that Apple/Google might not have in talking more directly to the hardware.
It’ll be interesting to see how this evolves over time. Till then, I’ll just keep coding however I need to.