(The use of the phrase "native goop" to describe the non-web parts seems telling. They don't seem focused on the end-user experience, but rather developer ease and (that old chimerical developer holy-grail) code reuse.)
(The use of the phrase "native goop" to describe the non-web parts seems telling. They don't seem focused on the end-user experience, but rather developer ease and (that old chimerical developer holy-grail) code reuse.)
There's a reason why this is important - it allows the 'native' app to stay up to date with the desktop web app. Yes, the Facebook native app is less usable and more clunky than it was before - on the other hand, it's feature-by-feature more up to date with the main site.
Is that a trade-off worth making? Perhaps, perhaps not - but in the very least, there's an argument to be made, right?
I think code reuse is often a chimerical holy-grail because in and of itself it is not a good thing; what matters is user experience, the amount of development work, how easy it is to fix bugs, &c. But developers still often obsess over code reuse, even at the expense of things that matter.
Except that, I don't disagree with anything else you said.
Fogbugz has their own custom compiler that generates code for the platform of their choice. Facebook has already written their own PHP->C++ compiler. I wouldn't be surprised if they have some team there working on some high-level infrastructure that lets them write UIs and code that gets compiled down to custom Objective-C/html+javascript/AndroidJava/etc...
Alright, it's time to explain the whole situation one more time (sigh).
GWT is a platform people. It has tons of goodies from doing the CSS sprites without having to write a home-grown CSS sprites merge scripts up until optimizing JS code.
Any developers that don't know their stack is limited to write high quality code, regardless you use GWT or pure JS (don't give me crap that front-end developers worth their salt without pulling the "yeah, only the best ones").
I used to code in GWT and we all need to know DOM API, we all need to know CSS. But we don't need to know the various "Object Pattern" in JS. We don't need to re-invent the module system in JS (we use Java package).
The difference is that we can write testable code via unit-tests that we can run automatically using JUnit, integrated to our build systems, without having to jump through hoops and prepare a full-blown infrastructure like those that required by Selenium or WebDriver.
But for Facebook, at this point perhaps their users are so entrenched that the app just has to work, however lackluster it may be. On the other hand, between this and the Python thing, I just can't understand why FB seems so stingy with its dev resources. I realize there is a lot of ground to cover but this is one of the biggest companies in tech we're talking about.