Facebook started with a native client. They switched to HTML due to internal organizational politics. I'm not sure what you're arguing -- that somehow Facebook lacked the resources to invest in user experience and rapid mobile development from the beginning?
It's not as if mobile was unproven at the time they decided to switch away from their native mobile client.
If it's so easy for Facebook to get a good mobile client out, why didn't they update the (much loathed) iOS client months and months ago? My suggested answer: it isn't in fact easy for them to do that. So time to market is an issue for them.
User experience is the not the only governing factor in software development. As the John Carmack post on HN front page says, software engineering is a social activity, which as you can imagine has more than one goal factor influencing it. I don't know what politics went on in this decision, but choosing a HTML/JS platform on mobile phones on definitely has its technical advantages. Though it doesn't apply to Facebook, a financial advantage would be to save money on hiring iOS experts/programmers.
As you noted, the financial advantage does not apply to Facebook. Contrarily, there's a financial advantage to shipping a better product, if you can afford to do so.
I'm interested in your supporting argument for other governing factors or software as a social activity, and how that relates to making engineering choices that sacrifice product quality for some notion of engineering perfectionism.
No, he isn't. Another way that a UIWebView can provide a super experience to custom NSViews is if the UIWebViews implement more of Facebook's functionality than the custom views, or if the features the UIWebView expose match the ones users want better.
- Facebook fails to deliver features through the superior approach ...
- ... but does deliver them through a lesser approach ...
.. then the mechanism they use to deliver the features provides a better user experience, because it has the features, thus justifying the choice to deliver them in the through a subpar mechanism?
That's ... circular. Painfully so.
It would be better for the user experience if they delivered features with the highest level of quality they're capable of providing, and that's demonstrably not inside of a UIWebView.
> They switched to HTML due to internal organizational politics.
Sorry, but how do you know this? Also, politics in of itself is rarely the real reason why decisions are made. Someone who seeks to gain benefit by making decision (which is deemed therefore political) can certainly be a reason. So, I'd be curious as to what benefit some individual or individuals sought to gain by making this decision.
It's not difficult to determine who in a web-centric engineering organization would benefit from promoting web-centric ideas in favor of alternatives, thus spurning engineering choices that would fall outside their area of responsibility or skill.
I'm not sure if you're being obtuse; this is basic organizational politics.
Pretend that Facebook's hitherto web-centric engineering team is external to Facebook -- they're a consultancy. Now imagine Facebook comes to them and says: We want a mobile application. Who benefits if they manage to convince Facebook to pay for them to produce a web application?
Let's reel it back to reality. How do people inside an organization benefit if they expand their area of purview, responsibility, and increase their value to the organization? Likewise, what power dynamics come into play when a new, potentially distinct engineering team garners additional purview, responsibility, outside of your domain, skills, or control?
It's not as if mobile was unproven at the time they decided to switch away from their native mobile client.