4 ms·

But that more or less just leads to the question: If HTML5 requires extra work to get right, isn't that what Zuckerberg was saying?

nostrademons 14y ago
It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work that you have to put in anyways with native mobile apps, and then the lack of that work ends up biting you in the end. One of the big promises of mobile HTML5 was that you could just take your desktop web apps, scale them down, give them new CSS, and they'd "just work". It doesn't work that way. You need to test on actual mobile devices from the start, you need to account for the lower CPU performance of them, you need to figure in higher latency over 3G connections vs. wired LANs. You have to do all of this on native apps anyway, but you know you have to do it from the start, otherwise you can't even get your app to display, and the frameworks are built with this in mind. There're still some areas where HTML5 wins - it's easier to update the app, for one, and it's more familiar to web developers. But the developer-convenience scales were not shifted as far to the HTML5 side as people hoped they were. I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y". We aren't going to get that in a TechCrunch soundbite; there're a lot of specifics that depend upon exactly what your market is.
- DeepDuh 14y ago
  So why bothering at this point? If I have to optimize for a given platform, I'd rather use the programming environment that gives me the best tooling.
  - nl 14y ago
    It depends on exactly how much you end up having to optimize for each platform, and how much reuse you get between platforms. If your app is a simple broacherware+notifications app, then HTML5 is probably the way to go. If you can afford expert developers for every platform and mobile is critical to your success then 100% native makes sense. There just isn't a simple answer here. To quote nostrademons: I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y"
  - eli 14y ago
    Define "best". The best tools aren't necessarily the ones that give you maximum control or best performance. If that we're true we wouldn't have so many Ruby on Rails or Django web apps.
    - DeepDuh 14y ago
      Good point. By 'best tooling' I'm mainly thinking about two things: - How easily can I debug things if something breaks? - In case I'm not happy with a certain behavior is it a dead end or can I simply swap out a parameter / function / module (in that order)? These two aspects are IMO essential for choosing any development environment if I have the choice. This goes for web development too, which is why I'd prefer something like Django over something like Joomla for example. I don't even care so much about performance at that point. Do you agree with me that at least in case of iOS, native beats html+js+webviews in those two points?
      - svachalek 14y ago
        I wouldn't. Debugging js is quite easy, overall probably more straightforward than dealing with Xcode. And there are tons more choices in the js world, having both more developers and a more free-as-in-speech mindset. The big downside is the one Facebook found, js in a webview is just... slow.
        jim_kaiser 14y ago
        Correction. Debugging JS in not easy. I have been working on a native application which has some HTML5 components in webviews. There is no easy way in XCode to debug JS in this kind of mixed application. In fact, it is a royal pain in the ass. You can run the JS in Chrome debugger or a web development IDE, but that can only work if all your functionality is in HTML5/JS and not a mix of Native and HTML5.
        DeepDuh 14y ago
        Thanks. I was gonna ask parent how he does it because if it's easy for him he might know some magic I'm not aware of.
  - nathan_long 14y ago
    You're comparing apples and oranges. If you optimize for a mobile browser, you can target every modern mobile platform simultaneously, and most of your work overlaps with making your app work nicely for people on laptops and desktops. If you go for a native app, you'll have to practically start over for every operating system.
- its_so_on 14y ago
  Wow, I am going to save this one: "It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work and then the lack of that work ends up biting you in the end." I have never experienced such hard-torque spin in my life. It's not that you would need to put in overtime if you worked here. It's just that we really let you get away with never putting in overtime, if you don't want to. And then that lack of overtime ends up biting you in the end.
  - qu4z-2 14y ago
    The point he's making is this: If you put in <x> effort into HTML5 you'll have a slow, shitty version. If you put in <x+y> you'll have a nice fast version. If you put in <x> effort with a native app, you have nothing. If you put in <x+y> you have a working, fast app. You get a working prototype faster with HTML5, but that's not a fair comparison with a native app which took more work to get working at all.
    - comex 14y ago
      But it's not really true, at least if you want a truly fluid UI... although I think it's possible to make UI written in HTML5 feel native, I have yet to use a single complex webapp that truly accomplishes it, unless it's hidden in a UIWebView in some app I use. (Gmail might come close if it didn't apparently use onclick instead of ontouchstart, and custom scrolling instead of -webkit-overflow-scrolling: touch, for no discernible reason.) It's not just that JavaScript is slow, although that doesn't help - having to worry about the performance implications of using libraries rather than directly using browser APIs, or being forced to use native scrolling because JavaScript scrolling just can't avoid lag, is a waste of time. It's also that where native UI frameworks are designed for performance from the start - every single UITableView is drawn lazily (implementing "immediate-mode" infinite scrolling on top of the deferred mode DOM is awful), you can fluidly move between low-level and high-level drawing APIs (Canvas is a very sharp boundary), animation feels built in rather than a recent hack (and I hope you're not targeting anything other than WebKit) - in HTML you have to fight against an absurd layout system to do anything and, in some sense, work around it to do anything fast; there are usually many ways to do it but most of them are slow. And it doesn't help that where native frameworks have built-in controls to do a lot of things - and those controls look and feel native simply because they have the home field advantage of being what everything else has to mimic - HTML5 is left with a bunch of shitty webapp frameworks and the option of reimplementing everything yourself. The creators of those frameworks seem to assume things like if the animation looks vaguely like the original, there's no need to actually get the details right to avoid uncanny valley, or make it performant at all, so you probably want to make it yourself. I hope you know what you're doing. As much as I love HTML5, you have to fight every step of the way to make something that works right. Getting a prototype out is easier with HTML5 than native, but for a moderately complex app, making it actually work right is vastly harder.
- lukifer 14y ago
  > One of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y". This should be the actual soundbite, and it bears repeating.

nostrademons 14y ago

It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work that you have to put in anyways with native mobile apps, and then the lack of that work ends up biting you in the end. One of the big promises of mobile HTML5 was that you could just take your desktop web apps, scale them down, give them new CSS, and they'd "just work". It doesn't work that way. You need to test on actual mobile devices from the start, you need to account for the lower CPU performance of them, you need to figure in higher latency over 3G connections vs. wired LANs. You have to do all of this on native apps anyway, but you know you have to do it from the start, otherwise you can't even get your app to display, and the frameworks are built with this in mind. There're still some areas where HTML5 wins - it's easier to update the app, for one, and it's more familiar to web developers. But the developer-convenience scales were not shifted as far to the HTML5 side as people hoped they were. I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y". We aren't going to get that in a TechCrunch soundbite; there're a lot of specifics that depend upon exactly what your market is.

DeepDuh 14y ago
So why bothering at this point? If I have to optimize for a given platform, I'd rather use the programming environment that gives me the best tooling.
- nl 14y ago
  It depends on exactly how much you end up having to optimize for each platform, and how much reuse you get between platforms. If your app is a simple broacherware+notifications app, then HTML5 is probably the way to go. If you can afford expert developers for every platform and mobile is critical to your success then 100% native makes sense. There just isn't a simple answer here. To quote nostrademons: I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y"
- eli 14y ago
  Define "best". The best tools aren't necessarily the ones that give you maximum control or best performance. If that we're true we wouldn't have so many Ruby on Rails or Django web apps.
  - DeepDuh 14y ago
    Good point. By 'best tooling' I'm mainly thinking about two things: - How easily can I debug things if something breaks? - In case I'm not happy with a certain behavior is it a dead end or can I simply swap out a parameter / function / module (in that order)? These two aspects are IMO essential for choosing any development environment if I have the choice. This goes for web development too, which is why I'd prefer something like Django over something like Joomla for example. I don't even care so much about performance at that point. Do you agree with me that at least in case of iOS, native beats html+js+webviews in those two points?
    - svachalek 14y ago
      I wouldn't. Debugging js is quite easy, overall probably more straightforward than dealing with Xcode. And there are tons more choices in the js world, having both more developers and a more free-as-in-speech mindset. The big downside is the one Facebook found, js in a webview is just... slow.
      - jim_kaiser 14y ago
        Correction. Debugging JS in not easy. I have been working on a native application which has some HTML5 components in webviews. There is no easy way in XCode to debug JS in this kind of mixed application. In fact, it is a royal pain in the ass. You can run the JS in Chrome debugger or a web development IDE, but that can only work if all your functionality is in HTML5/JS and not a mix of Native and HTML5.
        DeepDuh 14y ago
        Thanks. I was gonna ask parent how he does it because if it's easy for him he might know some magic I'm not aware of.
- nathan_long 14y ago
  You're comparing apples and oranges. If you optimize for a mobile browser, you can target every modern mobile platform simultaneously, and most of your work overlaps with making your app work nicely for people on laptops and desktops. If you go for a native app, you'll have to practically start over for every operating system.
its_so_on 14y ago
Wow, I am going to save this one: "It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work and then the lack of that work ends up biting you in the end." I have never experienced such hard-torque spin in my life. It's not that you would need to put in overtime if you worked here. It's just that we really let you get away with never putting in overtime, if you don't want to. And then that lack of overtime ends up biting you in the end.
- qu4z-2 14y ago
  The point he's making is this: If you put in <x> effort into HTML5 you'll have a slow, shitty version. If you put in <x+y> you'll have a nice fast version. If you put in <x> effort with a native app, you have nothing. If you put in <x+y> you have a working, fast app. You get a working prototype faster with HTML5, but that's not a fair comparison with a native app which took more work to get working at all.
  - comex 14y ago
    But it's not really true, at least if you want a truly fluid UI... although I think it's possible to make UI written in HTML5 feel native, I have yet to use a single complex webapp that truly accomplishes it, unless it's hidden in a UIWebView in some app I use. (Gmail might come close if it didn't apparently use onclick instead of ontouchstart, and custom scrolling instead of -webkit-overflow-scrolling: touch, for no discernible reason.) It's not just that JavaScript is slow, although that doesn't help - having to worry about the performance implications of using libraries rather than directly using browser APIs, or being forced to use native scrolling because JavaScript scrolling just can't avoid lag, is a waste of time. It's also that where native UI frameworks are designed for performance from the start - every single UITableView is drawn lazily (implementing "immediate-mode" infinite scrolling on top of the deferred mode DOM is awful), you can fluidly move between low-level and high-level drawing APIs (Canvas is a very sharp boundary), animation feels built in rather than a recent hack (and I hope you're not targeting anything other than WebKit) - in HTML you have to fight against an absurd layout system to do anything and, in some sense, work around it to do anything fast; there are usually many ways to do it but most of them are slow. And it doesn't help that where native frameworks have built-in controls to do a lot of things - and those controls look and feel native simply because they have the home field advantage of being what everything else has to mimic - HTML5 is left with a bunch of shitty webapp frameworks and the option of reimplementing everything yourself. The creators of those frameworks seem to assume things like if the animation looks vaguely like the original, there's no need to actually get the details right to avoid uncanny valley, or make it performant at all, so you probably want to make it yourself. I hope you know what you're doing. As much as I love HTML5, you have to fight every step of the way to make something that works right. Getting a prototype out is easier with HTML5 than native, but for a moderately complex app, making it actually work right is vastly harder.
lukifer 14y ago
> One of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y". This should be the actual soundbite, and it bears repeating.