Maybe ElReg could hire these guys to make the videos work on The Register's site
Instead of having to pop out to Vimeo to watch them.
Even as Facebook dumps HTML5 to embrace native app development, calling its early enthusiasm for HTML5 its "biggest mistake," Sencha, a leading provider of open-source web application frameworks and tools, has not only demonstrated real-world readiness of HTML5, but has actually built a Facebook app that performs better than …
Instead of having to pop out to Vimeo to watch them.
I'm using Chrome on Android (Jelly Bean) and I saw the review pic ok and it played well within the web page. Sometimes (on El Reg) it shows a grey box with 'plugin not available', and sometimes it opens up the You Tube app (with mobile web presentation). It's certainly confusing.
Don't get me started on the way the BBC iPlayer keeps changing and fouling up.
My experience is that you always have to open the Vimeo site to play the video, i.e. not limited to El Reg.
Apart from the new wave of web hipsters, who uses Vimeo anyway?
I found that my flash blocker stops it. so i have to 'always allow flash from this site' from the toolbar to get it to work - not just enable the video control.
The Vimeo videos work fine in Opera too. (Sadly, one of the few things which does still work fine in Opera these days.)
I wrongly (lazily?) assumed it was El Reg - but a bit of research and practical experimentation reveals it to be a Firefox bug with Vimeo.
My apologies to the Vulture.
"we are in a "golden age" of application development"
I consider it more of a brown age, personally.
The whole thing looks like a lot of smoke and mirrors to me. Setting faster animation speeds at the cost of smoothness, caching more data sacrificing memory for speed and that pull-down to update test didn't look like it updated on the Sencha version, it just scrolled down to the next item.
I wouldn't say it's all smoke and mirrors. Their rather complicated use of iframe elements to partition the DOM tree looks like a significant performance enhancement - basically they've reinvented framesets to reduce the scope of various subtrees, so compositing "knows" it can ignore various subsets of elements (except when actually rendering those elements).
Putting pending requests in a priority queue is a pretty obvious move, but it's not completely trivial, and it's a real performance improvement if you either have bursty workloads (say, roughly in a Poisson distribution) so you can eventually catch up, or you can discard low-priority requests when the queue grows too long, without adversely affecting user experience.
What I took from the blog post was "HTML 5 can offer good performance and UX for complicated UIs, but only if you understand it and do a bunch of work". Or, more generally, "writing HTML 5 apps is like writing pretty much any other software".
Though I admit I did laugh at the bit at the beginning where they wrote "modern application development didn't need anything except the browser, a great set of frameworks and a great set of tools". Um, and maybe something on the back end to do some actual damn work? Here, lemme just rewrite your banking systems as a bunch of HTML 5 apps...
If you have an HTML5 app that serves ads, then they can be blocked. But a lot harder if it's built into the app.
Maybe this is where Facebook is going with this.
How would you block ads on an iPhone?
Disable your data connection when using your aps. A bit pointless if it's a cloud-based app, but it works a charm when playing ad-sponsored games.
But wouldn't that also block ads that would be displayed in a native app? I fail to see how ads are an argument for or against native apps.
"How would you block ads on an iPhone?"
Use one of the fine browsers that blocks ads.
Are we starting another off-topic infantile chimpanzee shit throwing contest?
Always with the cloud-biased Kool-Aid.
The reality of HTML5 as it stands is a bit of a mess, if we're being honest.
Annoyingly, I can't see the graph used because we're stuck with IE8 at work, but touting such "relative" figures always rings alarm bells for me.
I don't know the figures, but if no one wanted HTML5 devs three years ago but they do today, those relative figures are going to be massive. Whereas Android jobs could have been in demand three years ago, so an equivalent (or even larger) rise in today's number will appear as a smaller relative rise.
Show me absolute month-on-month changes in *new* ads (since not being able to hire someone isn't the sign of increased demand), and I'll start to listen.
And the whole point of the article seems to contradict its conclusion :
It is NOT a good time for web "developer" (read HTML, that were never a language to begin with anyway).
What Sensha demonstrated and what their framework is bringing to the Javacript world is that you need more "traditional" developer skills to do it right (modularity, delegation, separation of concerns, a **proper** object model, documentation, etc ...) than just 'php +html thrown on a page" skills.
Not to say that Facebook is only that, but obviously the html5 team was ...
Does that graph make any sense? The "relative percentage growth" in HTML5 jobs in the last year is over 550,000%? Really?
Compared to the "Absolute percentage of matched jobs", which shows the same shaped graph as being a bit over 0.4%?
Can someone explain how that makes any sense? Maybe I've not had enough coffee, but that doesn't seem to add up
Does that graph make any sense?
No, assuming that the graph is about jobs it is saying that if there was 1,000 people working with HTML5 in Jan 2010 that there is now 550 Million people working with HTML5. That's the same as the entire population of north america (USA, Canada, Mexico, Barbados, Costa Rica etc.)
All working hard to replace Cobol, PL/1 and Fortran no doubt.
But if I've told them once, I've told them 1,000,000,000,000,000,000,000 times, don't exaggerate.
I tried their Sencha Touch 'Kitchen Sink' demo and I found it extremely slow and unresponsive.
They should have but some of their programming wizardry in their own demos.
or maybe to spend time on documentation and tutorials... there's a reason the world and his dog use jQuery instead of extJs
The point of the "kitchen sink" was to showcase all of the built in components that are available within our product. It was originally thrown together quite a while back as a quick necessity that people were asking for, but was never built properly. We are currently rewriting the examples to take advantage of the huge improvements in our architecture over the past year, especially now that our engineering staff headcount is growing so that we have time to fix these things. =)
The blog says;
"To demonstrate what could be done to optimize network transfers, we put a proxy server in place to clean up and parse the raw data returned from the Facebook FQL API. As a result, Fastbook transfers far less data than the native app to render the same views: as little as 10% to render the same items on the News Feed. The proxy also allows us to offload some of the more mundane tasks such as content formatting and filtering to the server-side."
So this isn't an HTML5 app at all. It's a proxy server filtering data returned from Facebook's servers, doing the heavy lifting, and passing the static result to an HTML5 app. That's completely and utterly cheating.
Sorry, but this is bollocks.
Good research! Thanks for that.
I think you've missed the point here - I've seen other articles where the front-end guys were butting heads with the server side guys as to what APIs were available/workable/efficient. Ok, so their html is great and handles it just as fine as the native - the proxy is CLEANING UP the returned data to allow for quicker access/rendering - that is ALSO something Facebook should've done but possibly didn't (server guys vs client guys).
What I see is a responsive HTML5 app that is just as quick as the native app, with some back end tweaks (that Facebook didn't do obviously) thrown into the mix to allow the HTML5 to compete with a native app - no smoke and mirrors?
You see that because you don't know what you're talking about. You have no idea why Facebook passes the additional data to their app. You don't even know what the additional data provided is. You're just guessing.
I suspect they're filtering everything that isn't absolutely necessary to render the page. I also suspect Facebook have reasons they DON'T want to do that, which are most likely in their own best interests. You don't seriously think Facebook don't performance test network traffic to within an inch of it's life? You don't really think they send 90% more data than they need to FOR NO REASON, and haven't noticed they're doing it? Because you've worked with "server guys" in the past?
Please. Just don't.
It's never mentioned in the video that the apps are using a different back-end. The talk is focussed on the app, the iOS team, et cetera, and how Sencha have built something that performs as good as the Facebook native app.
It would've been nice if they mentioned something like 'oh, hey, and our app uses different input data to account for its loading speed.'
That was for an experiment, not the live Fastbook application. The live application uses Facebook's API directly, without any proxy.
Where does it say that?
No, that's not true. Inspect the code for yourself by loading the site in a desktop browser and viewing source.
Interesting that if you post on their own site criticising the proxy server, those comments don't appear on the blog. Tried twice now.
Not sure why I'm being downvoted for saying "using a filtering proxy server that reduces network traffic by 90%, and potentially cached network traffic locally when they filmed videos" is cheating. It is cheating. Show us the performance if you don't use that server. You can't implement a proxy server on a phone that reduces network traffic by 90%, and caches content in the same way, either in a native app, or html5 or anything else. You just can't.
So if I'm filming the videos on that blog, and I'm in, say, France, to get content for the native Facebook app, my phone has to go to Facebook's servers in (say) California, whereas their app goes to the server hanging off the gigabit switch their wifi router's plugged into in the same office, that has previously cached the content they want.
Fair test? Not really ...
The app's available publicly - just try it for yourself. And there is no "proxy server" filter on our comment system - we just have an occasionally over-active spam filter on our comment system. If you want to post your comment here, I'll personally cut and paste it into our comment system on the back end
Sorry, not writing it again, done so twice now. Neither had any content a spam filter would pick up. Can you confirm whether your "html5 app" uses the proxy server the blog describes, that filters 90% of the network traffic from Facebook's servers, or do you not use that as a backend on your "app" (website).
Just tried it out, and I can't open messages or chat. It also doesn't let you comment or like. So they've built something that works not quite as well as the FB native app which makes their claims a bit suspect.
It's a proof of concept, not a complete app. They haven't attempted to implement the whole of Facebook.
Whilst I don't buy into their central claim that HTML5 is currently in a fit state to supplant native apps (just check out the recommended Android version), it's nice that they've gone to all this trouble to crawl along the bleeding edge and document (albeit subjectively) their findings. The code is open to inspection, at least on the client side.
The login screen hung (infinite spinner) on the HTC One X we have here in the office, but worked fine on the older Moto Defy+. YMMV.
"Whilst I don't buy into their central claim that HTML5 is currently in a fit state to supplant native apps (just check out the recommended Android version), it's nice that they've gone to all this trouble to crawl along the bleeding edge and document (albeit subjectively) their findings. The code is open to inspection, at least on the client side."
My own personal takeaway from this experiment is twofold:
1. HTML5 really isn't quite ready for prime time, at least not without a lot of back-end massaging of the data you send to an HTML5 app; and
2. Notwithstanding point (1) above, Facebook's HTML5 developers are a bit rubbish.
While I agree with the article (HTML5 is good, Sencha are smart, Facebook are dolts), that has to be one of the most useless infographics I've ever seen. Relative growth, huh? From where? Considering your graph starts in 2006 when HTML5 didn't exist, it's hardly going to show a downturn. With that kind of statistics abuse perhaps you should moonlight writing science articles for the Daily Mail...
"Considering your graph starts in 2006 when HTML5 didn't exist"
Depends on what you mean by 'didn't exist'. Work on HTML5 started in 2004.
and will finish in 2032....
and will finish in 2032....
I wish. Thanks to WHATWG's "living standard" nonsense, it currently looks like work on HTML 5 will never finish in any useful sense. There will just be flavor-of-the-day HTML forever. That's why they took the version info out of the DOCTYPE, after all.
The W3C may someday publish a final HTML 5 spec, but implementers will just point to WHATWG when they want to add some new half-assed feature.
The hostility to finishing anything among the WHATWG members on, say, the W3C's URI discussion mailing list is palpable. These are folks who want to be able to change things on a whim, forever.
I have worked with webby tools such as Phone Gap, and Appcelerator but in the end I had to learn Objective-C and go native. I don't regret that. I have total control over the interface, how and when I load resources, and what thread I do processing on. I get errors when I make a typo, and Core Data makes working with massive datasets very easy. If I want scrolling, I don't need to write my own physics or get a framework, if the client asks me to generate a PDF and upload it to a web service, I can. If I suddenly need to play a video on a spinning 3D cube, I can.
In short there are no limits when you go native (except app store restrictions but they affect all apps). HTML5 might be fine for small apps (which arguably should be web sites anyway) but when you are approaching a long-term large project, it's just not there yet, and to be honest I don't see why the two need to compete. The web is a totally different paradigm to native software, any dev who thinks he/she can 'reuse their skills' will be in for a nasty surprise.
Agreed. We used Cordova (née PhoneGap) for a proof of concept app, but we're recoding native for production. Why? All the usual things. The HTML stuff just "isn't very native", without decent looking buttons, incorrectly styled scroll bars, incorrect scrolling physics and so-on (you can see all this very clearly on the Sencha demo video in the article).
More importantly, you were stuffed when you hit low quality implementation issues on the native side of the barrier - e.g. a lack of decent error handling for unexpected events. Camera photos would sometimes just fail to save for no reason; error callbacks wouldn't go off but the "camera wouldn't start" (IYSWIM) or a photo would not save. And often when an error handling path *was* provided in the JS API and *did* get called, the error information would be sparse or entirely lacking (and at its best, bespoke error paths or exceptions in JS are a pathetic shadow of the facilities offered by e.g. the NSError class). All of this makes for a terrible user experience.
Worse still, the memory footprint was far larger than necessary, which ruled out smaller RAM devices on Android (the app would just randomly quit - this is HTML + JS, remember, so that kind of crash ought to be impossible unless you're encountering bugs in the underlying framework over which you have little or no control). This was a pretty small app, too. I'd wager that all the caching shown by Sencha when switching feed views or refreshing will, in fact, be a huge problem in a real app - it'd potentially lead to unbounded RAM use and random app crashes. In short we'd be back where the Facebook app started before it went (partly) native and started to solve some of those very issues.
You *could* try writing caching frameworks in JS to try and mitigate this but how utterly ridiculous that would be; an OS with an HTML+CSS formatter and JS execution engine with an app balanced on top of all of that trying to ignore and replicate all the stuff that's already implemented beneath it. If you want write-once-run-anywhere you'd be better off trying to go back to Java (which leads us straight to Android, ironically).
HTML 5 + JS + CSS 3 are quite simply very badly designed if they're meant to be used for applications rather than dynamic additions to web sites. Very large hard to implement specifications, and highly over-complicated due to legacy and a one-size-fits-all requirement of providing maximum presentation flexibility for arbitrary web sites, just when you want platform consistency for an app.
One ends up either devoting huge amounts of resource to creating your own bespoke application toolkit, right down to the scrolling physics, or you end up using a framework, in which case you've a huge API to learn. In *that* case I'd rather learn then native API and benefit from all the compilation support, IDE support and far more professionally designed-and-fit-for-purpose frameworks that come with it.
We don't need another stinkin' IE6.
"We don't need another stinkin' IE6."
Or IE8, 9 and 10
LOL and I forgot IE7, can't miss that beauty!
they just have no taste. and are very low on the skills department
Biting the hand that feeds IT © 1998–2017