Choosing platforms to optimize developer experience enables you to get more features out the door faster, which is usually the right decision when you don't know precisely which feature set the market is going to value. After a year or two of experience, it's a lot easier to go back and pick a different platform to optimize for something else.
Trade-offs to accommodate your resource or skill contraints are just that -- trade-offs. They're not optimal solutions for your users or your products. Singular dedication to user experience may have an intangible value, but Apple and others have consistently demonstrated that the value is high.
This isn't a trade-off Facebook needed to make. Whether it's a trade-off your organization needs to make depends on your resource availability, skills, and target market. However, there's no value in dressing up the trade-off as anything other than a trade-off.
The target market and product factors into the question of resource allocation. Nest would not have made such a splash if they decided to skip user experience and focus on fast feature roll-out, and Dropbox would not have succeeded to nearly the same degree (if at all) without first-rate native user experience.
I reject the idea that Nest and Dropbox were in similar positions as Facebook. The entire value proposition of Nest is simple (and simplicity). Same with Dropbox. It is harder to make a case for how Facebook could have had a "simple" value proposition 2 years ago.
You're making a case for why Dropbox didn't have to go through the time-to-market-driven experimentation Facebook did. That is indeed an advantage to being Dropbox. It isn't a very good indictment of Facebook's strategy.
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?
There's no value in dressing down trade-offs as being anything but ubiquitous, either. Supply chain and operational concerns constrained and changed how Apple products turn out, too.
"a year or two" - that's quite a long time to be testing something. Also I'm not sure how much of a time to market advantage they gained from using UIWebView, if any. There's simply no evidence to support it. Everything points to internal politics.
"Choosing platforms to optimize developer experience enables you to get more features out the door faster"
That is correct in theory, but falls on the face with facebook and others. Unless you literally just mean "more features", and not improving what they're making. E.g. paying for promoted updates so friends see them in their cluttered stream surely is Yet Another Feature, but is it good? I guess it depends on who the market is, here..
If the thing were written in spaghetti code, it would at least mean people would have some time to think in between, or even manage to get out of their 20s before their redefine how grandma keeps in touch.
Still, I'm happy that they improved how their crappy soulless product runs on another crappy soulless product, it keeps them off the street.
