HTML5/JavaScript! The future of cross-platform development!



  • One of our intended projects for the first half of this year is a "Lite" version of our existing Silverlight-based product that can run on mobile devices. It would be a viewer-only and won't have the full functionality of our more mature product but would allow users to quickly look something up on their cell phones if they aren't near a computer. And as a bonus it should run on Android tablets and iPads. (Silverlight websites currently only run on Windows PCs and Mac computers.) And as another bonus it'll work for the six people in the world who want to use our software but run Linux, and it'll also work for that one tin-foil hat guy who called in once because our Silverlight site didn't work since he refused to install Silverlight and allow corporations and the government to spy on him through the plugin.

    We decided to code the project using HTML5 (and, unfortunately, JavaScript), since everybody in the known universe is touting that platform as the BEST solution for web applications. So I've been messing around and prototyping to see what our capabilities are. Of course, I find out that the JavaScript library from our vendor which we'll need to connect to our servers doesn't take advantage of any of the new stuff in HTML5 so it won't truly be an HTML5 app. (Actually, the work I've done so far I haven't really found any difference between HTML4 and HTML5. But I'm also not an HTML wizard or a designer.)

    I hate to give away too much about our business, so I'll just say this application is very graphical and absolutely requires touch gestures in order to pan or zoom. Actually, maybe "gestures" is too specific of a word. How about click down, drag, and then release to pan? That's exactly how our full-blown Silverlight app works. Surely a touchscreen just emulates a mouse and you can get the mousedown, mouseup, and mousemove events.

    I threw something quick-and-dirty together just using Mozilla Firefox on my desktop for testing and it worked exactly as expected. I had a coworker test it on his iPhone 4S. Worked exactly as expected there as well. Well, Android is a major platform we're targeting, but guess what we don't have any modern Android devices to test on (a couple coworkers have cheap Android phones but they're at least three years old and can't even seem to load the website). I've mentioned several times this month that if we're going to target Android, then I need an Android device for testing. But I think the way everyone says HTML5 runs everywhere has convinced some higher-ups that I'll be fine without an Android device.

    In lieu of that I loaded the site on my Windows Phone 7. And the site loads, you can see the interface, but you can't interact with anything. Touching the screen allows you to scroll the page but it doesn't trigger the app's pan functionality. I found a quote from the MSDN forums stating "the Web Browser interprets movement of the touch point as a gesture to scroll the page contents and so, in this case, the mouse events do not fire." So, apparently you don't have click events at all, except for links and buttons. Bummer. There's a chance that the upcoming ARM version of Windows 8 for tablet devices would be so similar to WP7 that if it works on WP7 it may work on future W8 tablets with no extra work. Plus I own a WP7 so I had a personal interest in seeing it work on this platform. WP7's market share is so small now anyway that it's not worth the effort.

    Fast forward several days. I started a custom config parser so the Lite version of our app will use the same config files as the full Silverlight version which should greatly simplify deployment. The two versions are meant to co-exist anyway. Along the way, everything worked fine in Firefox and on iPhone, and someone tested on an iPad and it worked fine there too.

    Finally, our remote coworker with a more modern Android device tested for me. It took a while because he doesn't work out of our office, he's always busy, and he's usually on the phone taking tech support calls. And to my surprise the site doesn't really work, it functions exactly as it does on my WP7. Or so I surmised based on our MSN chat since I couldn't actually be there in person to test my app. I did some web searching and found that the Android web browser has a known bug preventing the touch screen from properly interacting with many elements in a web page. And the bug dates to October 2010 and apparently hasn't been fixed yet.

    So, here's the summary. HTML5/JavaScript is great for cross-platform web sites, if all you need to do is view some content and click links, which by the way works just as well in HTML4 and JavaScript in my experience. But as soon as you require the user to interact with stuff other than links and buttons, it quits working on two of the three mobile platforms we tested. So it's cross-platform as long as the device starts with a lower-case"i". And that's worthless since we're planning on doing a full-functionality (plus some new goodies) native Objective-C version of our app for iOS anyway. Apparently a lot of our clients have iPads.

    My conclusion is everyone talking about HTML5 as the cure to cancer and AIDS and the future of humanity are just dumb marketing people with their thumbs stuck up their anuses, foaming at the mouth and incoherently screaming buzzwords they heard some semi-techie guy say one time.



  •  What you're attempting would be more accurately described as DHTML, not HTML5.

     



  • HTML5 introduces some new tags with some standard behaviours and some divergent behaviours.

    That's about it.

    CSS3 has some awesome new features, though the best thing is basically that IE9 supports much of it so you can finally do all that shit you've been wanting to do for 4 years.



  • @mott555 said:

    Of course, I find out that the JavaScript library from our vendor which we'll need to connect to our servers doesn't take advantage of any of the new stuff in HTML5 so it won't truly be an HTML5 app.

    Like... what did you expect to find?

    @mott555 said:

    (Actually, the work I've done so far I haven't really found any difference between HTML4 and HTML5. But I'm also not an HTML wizard or a designer.)

    It's basically Web Sockets and the Canvas tag, and associated DOM functions. And local storage DB DOM functions, but I don't think much uses or supports that yet. There's a bunch of new tags, also, but you can ignore those.

    And they stopped pretending that being able to read a HTML file with a XML parser was a good idea, or, rather, they finally accepted that only maybe 6 people on Earth actually care about that and all 6 work at the W3C and they should stop forcing their views down everybody else's throat.

    They also stopped pretending that browsers would ever be able to stop rendering HTML4 or lower, and so they simplified the preamble with that in mind.

    Basically, HTML5 is getting the insane delusional people at the W3C actually thinking about practical issues for once-- needless to say, it did not originate from the W3C.

    @mott555 said:

    So, here's the summary. HTML5/JavaScript is great for cross-platform web sites, if all you need to do is view some content and click links, which by the way works just as well in HTML4 and JavaScript in my experience. But as soon as you require the user to interact with stuff other than links and buttons, it quits working on two of the three mobile platforms we tested. So it's cross-platform as long as the device starts with a lower-case"i".

    It sounds like the conclusion you should be drawing is, "the way browsers handle touch-screen interfaces, specifically how they bubble mouse events, is inconsistent," and then you should maybe be digging into why it's inconsistent. And none of your conclusion has anything to do with HTML5 or JavaScript. Unless by HTML5 you mean "DOM".

    Edit: BTW it's inconsistent on desktop browsers, too. Firefox doesn't bubble mouse events on disabled controls-- it's been in their bug tracker for 7+ years, but I don't think FF developers consider that a bug. (And DOM is, natch, extraordinarily vague on the matter...)

    @mott555 said:

    My conclusion is everyone talking about HTML5 as the cure to cancer and AIDS and the future of humanity are just dumb marketing people with their thumbs stuck up their anuses, foaming at the mouth and incoherently screaming buzzwords they heard some semi-techie guy say one time.

    Sounds likely.



  • @blakeyrat said:

    And they stopped pretending that being able to read a HTML file with a XML parser was a good idea, or, rather, they finally accepted that only maybe 6 people on Earth actually care about that and all 6 work at the W3C and they should stop forcing their views down everybody else's throat.


    I don't work at the W3C, and I like file formats which can be parsed easily.



  • Our employer wanted an iPad app (but we didn't have a Mac, I didn't know Objective C, and I hate Apple in general), and we tried to convince them to let us do either a mobile-friendly web app or an android app, because of the app store requirements more than everything. But they were pretty insistent, and bought me a Mac Mini and a developer account to make it happen. I prototyped the app in html and javascript with jquery for animations, and after some study ported it to Objective C. Animating UI elements in UIKit is apparently very easy, and the app came out better than expected, sooner than expected. It was denied on our first submission though, not for any quality issues, but for being too marketing related. It was a catalog app for outside sales reps, and Apple makes no accommodations for iOS apps that are business related, but for distribution to non-employees. To distribute anything to non-employees, even to business partners, you need app store approval, which is difficult for niche business apps that lack broad appeal. We did convince them to rereview it though, and they finally approved it.

    Apart from the submission/review ordeal, native was the right way to go. After our initial denial, I tested my html prototype on the iPad to see how hard it'd be to make that work, and it was painfully sluggish. Any time an image was being loaded (very often being a catalog app), it would freeze up until it was done, and jquery animations would often jump to the end without any smooth animation in between.

    Next they want an Android version, which they initially refused, and they want to keep the html prototype for the web, so in the end I'll be maintaining at least 3 versions of this thing in different languages.



  • I've noticed this behavior on my Android. It looks like some companies are aware of these HTML5 bugs and avoid it altogether. For example, going to maps.google.com on my Android brings up a Java applet, not the webpage.



  • HTML5 developers consider Chrome, Safari, and Firefox to mean "works on every browser ever".



  • @dhromed said:

    CSS3 has some awesome new features, though the best thing is basically that IE9 supports much of it so you can finally do all that shit you've been wanting to do for 4 years.

    Although until Webkit and Gecko do nobody will be using the standard versions.



  • @blakeyrat said:

    @mott555 said:
    So, here's the summary. HTML5/JavaScript is great for cross-platform web sites, if all you need to do is view some content and click links, which by the way works just as well in HTML4 and JavaScript in my experience. But as soon as you require the user to interact with stuff other than links and buttons, it quits working on two of the three mobile platforms we tested. So it's cross-platform as long as the device starts with a lower-case"i".

    It sounds like the conclusion you should be drawing is, "the way browsers handle touch-screen interfaces, specifically how they bubble mouse events, is inconsistent," and then you should maybe be digging into why it's inconsistent. And none of your conclusion has anything to do with HTML5 or JavaScript. Unless by HTML5 you mean "DOM".

    Bubbling is not a factor since the browser is intercepting the events before they even reach the DOM. The panning gestures are considered part of the browser user interface, not the web page.



  • @lettucemode said:

    I've noticed this behavior on my Android. It looks like some companies are aware of these HTML5 bugs and avoid it altogether. For example, going to maps.google.com on my Android brings up a Java applet, not the webpage.

    I certainly does not seem to be the case here. When I open maps.google.com on Android, it asks me whether I want to open it with the native application or web browser, but the sluggish thing that comes up in web browser seems to be HTML+JavaScript, not Java (I don't see a way to look at the source to be certain unfortunately).



  •  You can blame apple for your problems. The comittees want to get touch features into DHTML, but apple is holding it up whereever they can with... you guessed it, Patent issues.



  • Why do people write replies that are nothing but rephrasing exactly what I just said?



  • @blakeyrat said:

    Why do people write replies that are nothing but rephrasing exactly what I just said?



    what is the purpose of replying, if the reply only contains another version of blakeys post ?




  • @blakeyrat said:

    Why do people write replies that are nothing but rephrasing exactly what I just said?
     

    Because they love you. Imitation is the sincerest form of flattery.


  • Discourse touched me in a no-no place

    @Nelle said:

    @blakeyrat said:
    Why do people write replies that are nothing but rephrasing exactly what I just said?

    what is the purpose of replying, if the reply only contains another version of blakeys post ?
    So those of us who've sent him to Coventry, can see what he's up to?



  • @blakeyrat said:

    Why do people write replies that are nothing but rephrasing exactly what I just said?

    Because you write in such an obnoxious manner that many people learn to ignore your posts.

     



  •  @lettucemode said:

    For example, going to maps.google.com on my Android brings up a Java applet, not the webpage.

    Not on my phone it doesn't. Going to maps.google.com pops up a dialog asking if I want to complete the action using the web browser or the Maps app. The mobile Maps site appears to be straight HTML.


Log in to reply