back to article Mark Zuckerberg doesn't know how to use HTML5

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 …

COMMENTS

This topic is closed for new posts.
  1. Headley_Grange Silver badge

    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.

    1. frank ly

      Re: Maybe ElReg could hire these guys to make the videos work on The Register's site

      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.

    2. Pinjata
      Boffin

      Re: Maybe ElReg could hire these guys to make the videos work on The Register's site

      My experience is that you always have to open the Vimeo site to play the video, i.e. not limited to El Reg.

      1. AceRimmer

        Re: Maybe ElReg could hire these guys to make the videos work on The Register's site

        Apart from the new wave of web hipsters, who uses Vimeo anyway?

      2. Twm Davies

        Re: Maybe ElReg could hire these guys to make the videos work on The Register's site

        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.

    3. This post has been deleted by its author

    4. This post has been deleted by its author

    5. Headley_Grange Silver badge

      Re: Maybe ElReg could hire these guys to make the videos work on The Register's site

      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.

  2. Anonymous Coward
    Anonymous Coward

    Golden age?

    "we are in a "golden age" of application development"

    I consider it more of a brown age, personally.

  3. This post has been deleted by its author

  4. Gerard Krupa

    Sleight of Hand

    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.

    1. Michael Wojcik Silver badge

      Re: Sleight of Hand

      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...

  5. Darren Bell
    Devil

    Ads, Ads, Ads !!!!

    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.

    1. Anonymous Coward
      Anonymous Coward

      Re: Ads, Ads, Ads !!!!

      How would you block ads on an iPhone?

      1. VaalDonkie

        Re: 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.

        1. Anonymous Coward
          Anonymous Coward

          Re: How would you block ads on an iPhone.

          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.

      2. Hyper72
        Thumb Down

        Re: Ads, Ads, Ads !!!!

        "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?

  6. Alan Bourke

    Ah, Mr Asay

    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.

    1. Ian Yates
      Headmaster

      Re: Ah, Mr Asay

      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.

  7. Annakan
    Pint

    Besides the fact that html5 is a mess of adhoc solutions to mostlly proprietary problems, what we are talking here is much more about JavaScript "done the right way".

    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 ...

  8. Anonymous Coward
    Anonymous Coward

    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

    1. Field Marshal Von Krakenfart
      WTF?

      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.

  9. Yves Kurisaki
    Thumb Down

    Back to reality

    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.

    1. RISC OS

      Re: Back to reality

      or maybe to spend time on documentation and tutorials... there's a reason the world and his dog use jQuery instead of extJs

    2. ryanjcollier
      Angel

      Re: Back to reality

      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. =)

  10. Anonymous Coward
    Anonymous Coward

    Hang on a minute...

    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.

    1. This post has been deleted by its author

    2. QdK

      Re: Hang on a minute...

      Good research! Thanks for that.

    3. GrumpyJoe
      WTF?

      Re: Hang on a minute...

      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?

      1. Anonymous Coward
        Anonymous Coward

        Re: Hang on a minute...

        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.

      2. QdK

        Re: Hang on a minute...

        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.'

    4. rdougan

      Re: Hang on a minute...

      That was for an experiment, not the live Fastbook application. The live application uses Facebook's API directly, without any proxy.

      1. QdK

        Re: Hang on a minute...

        Where does it say that?

    5. regmullany

      Re: Hang on a minute...

      No, that's not true. Inspect the code for yourself by loading the site in a desktop browser and viewing source.

  11. Anonymous Coward
    Anonymous Coward

    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 ...

    1. regmullany

      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

      Michael Mullany

      CEO, Sencha

      1. Anonymous Coward
        Anonymous Coward

        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).

        Thanks.

  12. BigAndos
    FAIL

    Shame it doesn't work

    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.

    1. John Latham

      Re: Shame it doesn't work

      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.

      1. Franklin

        Re: Shame it doesn't work

        "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.

  13. Androgynous Cupboard Silver badge

    Spectacular Graph

    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...

    1. Anonymous Coward
      Anonymous Coward

      Re: Spectacular Graph

      "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.

      1. Frank 2
        Joke

        Re: Spectacular Graph

        and will finish in 2032....

        1. Michael Wojcik Silver badge

          Re: Spectacular Graph

          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.

  14. marc 9

    Why try and make HTML do everything?

    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.

    1. Andrew Hodgkinson
      Thumb Up

      Re: Why try and make HTML do everything?

      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.

  15. ScissorHands
    Mushroom

    HTML5 <> WebKit

    We don't need another stinkin' IE6.

    1. southpacificpom
      Devil

      Re: HTML5 <> WebKit

      "We don't need another stinkin' IE6."

      Or IE8, 9 and 10

      1. southpacificpom

        Re: HTML5 <> WebKit

        LOL and I forgot IE7, can't miss that beauty!

  16. The Alpha Klutz

    facebook has no taste

    they just have no taste. and are very low on the skills department

  17. RISC OS

    I'd like to see....

    ...how responsive and snappy their html 5 site would be if they actually had to get their data from the same source as the app and take into account all the things the app does. The people at facebook have about a billion users, I'm sure there no how to make html 5 apps,and there are reasons why they couldn't get there html 5 app to work the way the fasterbook does.

    People here who think that facebook doesn't know how to write an html5 app should first try and make one under the constraints, restrictions and requirements that sencha didn't need to work under.

    ExtJs sucks balls compared to jquery and the documentation is shite. Instead of claiming to know more about app development than facebook they should concentrate on improving their own stuff... banning that self righteous anal arse user that goes by the name of "Animal" from their offical foruns might be a good start to actually getting people to bother learning extjs

    1. badmonkey
      Devil

      Re: I'd like to see....

      Judging from the bugs and moving targets I encounter developing simple interactions with Facebook's services from web dev point of view, I wouldn't be so sure that they know much of anything - or care, frankly.

This topic is closed for new posts.

Other stories you might like