6 ms·

Web Developers, Don’t Be Lazy And Learn A Native Mobile Language

13 points by dirkdk 14y ago

gruseom 14y ago
Is there a good reason not to believe that mobile will eventually swing to HTML, for the same reasons that desktop apps yielded to web apps?
- deleted 14y ago
  [deleted]
- dirkdk 14y ago
  in due time, not really. However, as mobile is a very much evolving platform, for the next few years native code will have earlier access to new features before html through additional api's has.
- Silhouette 14y ago
  In general, I don't think desktop apps have yielded to web apps. Web apps have worked well for projects that are essentially simple front-ends to a database or simple content distribution systems, which admittedly represents a very significant part of the software industry. These tools inherently require some sort of client-server system, so there's no architectural overhead there that you weren't going to have anyway. Also, with web apps you get cross-platform portability very cheaply, and you get zero-effort deployment instead of trying to deal with installation/upgrades of software on say Windows where the plot was lost long ago and no-one has ever restored sanity. However, when you come to doing anything that requires non-trivial interactions or non-trivial processing, web apps are often still decades behind the state of the art for mature desktop applications. No-one does serious graphics work, or mathematical modelling/simulation, or FPS gaming in web apps today. I suspect we never will, because we'll develop (rediscover?) how to build such applications with a specialised thin client and/or how to push out and maintain software with a native thick client more effectively long before we bastardise a text mark-up language and its friends well enough to write serious software as web apps in general.
  - gruseom 14y ago
    Of course you're right that some domains (e.g. graphics) are harder than others, but you might be overstating your case. Surely Gmail requires "non-trivial interactions". And why not mathematical modelling/simulation? — you can access a lot more computational power on servers. And how often does one hear of a startup making new desktop software? I like your point that we might figure out how to get desktop deployment right sooner than how to adapt the web to do all these things. But nearly all the innovation has been pointing in the other direction. Also, such a deployment technology would face formidable institutional barriers.
    - timburks 14y ago
      The Gmail native iOS app is really nice, so the flow of innovation isn't consistently pointing towards the web. But part of the answer to getting "desktop deployment right" is sandboxing. In essence, the native app platforms are making operating systems more like web browsers, while projects like Mozilla and Chrome are trying to turn web browsers into operating systems.
    - Silhouette 14y ago
      Surely Gmail requires "non-trivial interactions". Yes and no. GMail is arguably one of the most successful and mature web apps out there, but at the end of the day you're still just reading mail, clicking a few places to change how information is presented, and typing a bunch of text. None of this requires a lot of real-time assistance as you navigate the information, context-sensitive UI, or task-specific controls beyond regular menu/toolbar/icon kinds of things, for example. And why not mathematical modelling/simulation? — you can access a lot more computational power on servers. Well, I think that point is debatable if you're doing serious modelling more than occasionally. The kind of processing power required makes it cheaper to buy your own high-end systems than to use commodity cloud-provided facilities very quickly, and for the same reason I suspect it would be difficult to offer such services economically in SaaS form. Also, real time graphic visualisations in web apps are still far slower and less sophisticated than what you can achieve natively with modern graphics cards, at least for now. If you're watching a couple of pretty graphics in an analytics tool, that doesn't matter. Even some basic 3D work is starting to get interesting with technologies like WebGL arriving. But for real-time rendering and navigation of global weather patterns or the design of a cruise ship? I don't see that being done remotely any time soon. And how often does one hear of a startup making new desktop software? I'm not sure how often one hears about start-ups doing something is a very useful metric, really. The culture on HN is particularly biased towards that field, but in reality there are millions of programmers out there working on desktop software. New bespoke desktop applications are being written for businesses all the time, and likewise tools, toys, games and more are written by small software shops for individuals all the time. But nearly all the innovation has been pointing in the other direction. Really? I'd say the mobile "app store" model and the Linux "distribution" model have both been very successful at getting native software deployed onto users' systems, too. It's just a shame that we still have horrible deployment practices and dependency management on most desktop platforms, much of it due to the stagnation of desktop OS architectures and the continued use of strategies that were originally designed to cope with limited resources but that have been obsolete for years now.
andybak 14y ago
Mobile OS developers, don’t be lazy, give me a half decent language that doesn't make my eyes bleed.
- dirkdk 14y ago
  yep, Objective-C sucks. But Javascript, is that such a straightforward language? You might think that because you are familiair with it, but I remember learning it after Java and that was not a good experience.
  - timburks 14y ago
    No, it doesn't. C++ sucks.
- jspthrowaway2 14y ago
  Fine, I'll bite. Assuming you're belittling Objective-C, let's not forget that Objective-C is simply C with Smalltalk bolted on. I'm having a hard time imagining a plane of reality in which either is not "half decent". Objective-C is, in my opinion, much better than C++ to accomplish the same task (they have semi-equivalent aims, though implemented very, very differently). I learned Objective-C and iOS (then called iPhone OS) from scratch to write a quite-complex app once. The app has been in the store for two years now. Like you, initially, I balked at the brackets; everybody does. Eventually, I was actually pleased that my C experience carried over so well, and it was a pleasant experience in the end. As you do, I wrote two to throw away until I mastered the platform, and I didn't mind it at all. Assuming your object user has an update method which takes a name argument and you want to store the result of calling update somewhere, here's Python vs. Objective-C (the Smalltalk-influenced terminology is different, but the concepts are the same): save_result(user.update(name="Larry")) saveResult([user updateWithName:"Larry"]); I don't find one much more horrible than the other.
  - krichman 14y ago
    Objective C is brilliant, it's one of the few things I actually enjoy about Apple's ecosystem. This is because it stole ideas from Smalltalk, which is also brilliant. I doubt there are many people who hate it rationally, but I'd love to have a discussion with them instead of the people that have some knee-jerk reaction to the message-passing syntax.
timburks 14y ago
Vishal Gurbuxani gave us the marketing perspective on this last month in Napa: http://www.slideshare.net/vgurbuxani/app-retreat-2012 http://www.slideshare.net/vgurbuxani/app-retreat-2012 One major problem: HTML5 is fragmented across platforms and is missing important ingredients needed by app businesses. In the end, it's just another platform, and not a very good one if a good user experience is something that you hope to deliver. Read Vishal's slides for more, or come ask him about them at his session at Renaissance: http://renaissance.io/speakers/vishal_gurbuxani http://renaissance.io/speakers/vishal_gurbuxani
eddieroger 14y ago
I tend to agree. Even a properly optimized, Simonized and Vulcanized app needs to be run through a browser layer, which inherently slows things down. Javascript bridges to native functionality are messy and can fail. And for what? Writing one code base? How much client-side logic are you really doing that you don't want to replicate? Any mobile app I write that requires server logic is basically just a view, so it needs to accept and manipulate JSON. Interface Builder gets you an interface in minutes (of course, you can spend time tweaking it), and there are dozens of networking libraries that consume a service and spit out native objects (if that's your thing). At the risk of speaking in absolutes, you will never get a better experience than a native, first-class one. Ask Facebook - it didn't work out so well for them.
darrencauthon 14y ago
"Native technology allows for excellent apps, whereas HTML5 apps will be at best just OK" Sometimes "just OK" is what people want, and what meets the needs of the business. The truth is -- building a mobile web app can be fast and can fill an iPhone/Android/Blackberry/Windows phone with the content and interactivity the business and users need and want. It can also be much cheaper. Different businesses have different values, and whatever works best to achieve those values is best. Calling devs lazy for not learning native mobile languages seems like a cheap way to get clicks. New Year's Resolution: Stop clicking on them.
jefflinwood 14y ago
Some of the impetus towards cross platform HTML5 development was probably because the state of Android app design in the 2.x era was so bad. You could basically get away with using an iOS-look-alike web toolkit on Android in a WebView, and it was "good enough". With Ice Cream Sandwich, the new Holo look and feel actually has a real design language that is markedly different from an iOS app. As to Windows Phone - there is such a strong design for Windows Phone apps that those jQuery Mobile apps in their app store look really out of place. Microsoft's working on some CSS that will make jQuery Mobile apps look more native, but it's still missing some of the key Windows Phone UI like panorama. From developing HTML5 and native mobile apps for iOS and Android, and from follow ups on some mobile application strategy consults, HTML5 mobile apps just don't deliver a good user experience, especially if the app does anything other than content consumption.
mistercow 14y ago
Not doing native development isn't about laziness. It's about freedom and flexibility. As much as is possible, you should strive to minimize your dependence on any single company (at least until you have some clout), and having a code base that is locked to a closed platform breaks that principle. And look, what I'm saying here isn't ideologically motivated. It comes from hard experience. If I had a dollar for every time I sat on a blanket with two corners held by a single company, and then got that blanket yanked out from under me, well... I'd have three dollars.
Silhouette 14y ago
There's an old Chinese proverb: "A man who says it cannot be done should not interrupt the man who is doing it." That's the feeling I get from opinion pieces like this. I've developed web-based user interfaces for several projects in recent years, some of them with a strong mobile focus. I'm still waiting for all these demons to come and bite us, where our paying customers don't find the experience satisfactory and run away to the competitors who are going to beat us by having a highly polished native app instead. Sure, there are occasional irritations with mobile browsers. Many of them, perhaps even the majority I've come across, are actually by design because Apple actively chose not to make their browser work like everyone else's... again. But do we spend as much effort getting our web apps to run effectively across all the major platforms (including Windows) as we'd have to spend writing a native UI on every platform we want to support? Not even close. And native apps still have the same horrible downsides as ever: the app store approval lottery, Apple wanting a huge cut of any money you make, yada yada. If I were running Facebook, where for practical purposes the budget and developer time required to develop a mobile app on every platform were negligible, sure, maybe it's worth it for a more polished experience. (Maybe.) But for more modest projects, where resources are finite and we don't magically have developers on tap who speak a different "native" language for each platform, I can spend the time and money once to build the web app and then the same again refining it or I can spend the time and money twice just to get the basics done without any polish. I don't understand how anyone who has actually done this can be in any doubt about which gets better results.
javis 14y ago
Mobile OS developers, don't be lazy and give me a way of embedding HTML5 into an app that doesn't completely ruin the whole experience. Seriously, a web app will be running beautifully in Mobile Safari, but when I put the same code into a WebView, it all goes to shit.
- dirkdk 14y ago
  Yep, running a web site in an hybrid iOS app will slow down your app, as the Nitro Javascript engine is not available. That has been the case for a while, because of security reasons, and won't go away any time soon
hunvreus 14y ago
One of the obvious reasons some teams may not go for native is that they don't have the resources to commit to maintaining two applications. Having 2 teams, contracting an external agency or finding a developer versed in both platforms are all pricey options. If your product is not the mobile apps themselves (obviously), HTML5 or Titanium can get you there without stretching your resources.
greenyoda 14y ago
It's not laziness, it's an economic decision. Learning a development environment like iOS or Android takes quite a bit of time and effort (especially if it's not your day job). If you believe that by the time you become proficient, HTML-5 will have improved enough to significantly decrease the demand for native apps, then you should spend your time learning something more valuable. Also, lots of people have already learned native app development, and it's increasingly becoming a commodity skill that, at least for simple apps, can be outsourced to the lowest bidder. Developers might believe that learning skills that are not as easily outsourced, such as data analysis, might be a better investment. Finally, learning a fast-changing environment like mobile apps is a much bigger investment than just learning a mobile language. It's a large, ongoing effort to stay current with the new features in every new release of the platform. So please let's not call people lazy just because they're not jumping on our favorite bandwagon.
mos2 14y ago
What about Ruby Motion for iOS? Its commercial ($200 a license) but offers native objective-c compiled from ruby and is based on the open source mac ruby project. This seems smart as you only have to learn the cocoa framework and you learn a little bit of objective-c. Whats nice if you want to go native and or optimize by writing straight objective-c you are halfway there. Everything else I have looked at is basically a web browser attempting to be a full app. I would love to hear if anyone has written an iOS app that is on the app store with it and what there experience has been.
- gte910h 14y ago
  > as you only have to learn the cocoa framework This is the hard part. The objective C part isn't.
dmotz 14y ago
I think this argument, ad hominem aside, loses a bit of validity with every subsequent smartphone/tablet generation. Every advance in CPUs and JavaScript interpreters blurs the line more if we're looking at a hybrid app developed by a competent team. As to where I'm coming from in this argument, yes, I currently develop mobile apps using web technologies. [1] And yes, I completely agree that the majority of web view/hybrid apps I've encountered have had poor user experiences. But the field of hybrid apps is new and everyone can recall the poor user experiences of desktop web apps in their nascent era. As with the age of MapQuest, the sample size of hybrid apps is still small and thus well-designed and well-coded apps are scarce. Aesthetics give probably the biggest impression of mobile software quality, and you can either choose to stick to stock SDK UI, or implement your own visual language. The former is safe and is the default for native development. Hybrid apps almost always fail when trying to mimic it completely and users are (at least subconsciously) repelled by the uncanny valley these apps may land in. The latter option of introducing a unique UI is exceedingly difficult to pull off, hybrid or native, but is a route of convenience for hybrid developers, but again, they usually fail to create something a user can feel comfortable with. In short, if you're serious about your app's reception, it is more difficult to pull off the user experience using web technologies, contrary to the article's assertion. Hybrid app developers cannot rely on native UI elements and this is why they tend to be received so poorly. So why have I chosen the hybrid approach? Mainly because I'm a futurist and I see the immense value in having an open lingua franca for app development over fractured proprietary environments. The cross platform benefits appeal to me less, and at the time of this writing, I consider iOS to be ahead of the other platforms in fidelity of rendering web content (Android 4 is catching up). I fully admit this benefit is half-baked at the moment, but I don't need any pundit predictions to know it will improve by bounds in the next few years. JS isn't a silver bullet, but it's undeniably exploding at the moment, especially in terms of flexibility (browser, server, mobile). You could invest your time in mastering a proprietary platform's SDK, but besides only focusing on non-portable knowledge, you could also find yourself with a dying marketshare for your chosen platform. I definitely don't mean to discredit native languages by any means, I just want to convey how I came to conclude that hybrid is a safe investment in mastering. Many apps, whether simple CRUD apps, or thin front ends for REST APIs, have no specific need for native code. Even Microsoft --seen among the symbols of proprietary control -- are embracing the HTML5 stack for apps. The benefit of being able to reuse the libraries and APIs [2] when bringing an app to another platform shouldn't be underestimated, nor the potential growth of mobile-oriented common knowledge in a common language. Is it really difficult to believe that in a few years phones will be running WebGL-powered 3D games with advanced shader effects, on par with native games? Not really, considering how rapidly we're approaching that point on the desktop. It's even easier when you consider the hybrid app bottleneck is usually DOM painting, not JS execution, and WebGL would potentially use the mobile device's GPU. This problem is almost solved already with intelligent DOM manipulation and CSS3 transforms, (or potentially other approaches [3]). Writing a quality hybrid app at the moment is very hard. Web views have less memory available, execution is slower, and simple DOM rendering is expensive and slow unless all optimized properly. Furthermore, aesthetics are harder to pull off when working outside SDK UI sets. But hybrid apps are a relatively new field and have enormous potential. I don't it's very mature yet, but neither was the web itself for a very long time. I think having a common, open set of tools is worth defending from accusations like this one or the red herrings thrown around regarding HTML5's role in the Facebook app. This is definitely the more forward-thinking bet. [1] - http://chaincalapp.com http://chaincalapp.com [2] - specifically HTML5 device APIs as well as http://phonegap.com http://phonegap.com [3] - http://famo.us http://famo.us
chrisringrose 14y ago
It's lazy to give up and devote all your energies on yet another company's proprietary platform. Instead of constantly writing articles like this, how about we focus on the obstacles web apps face, and fix them. Sure, if both a web app and native app are programmed optimally, the native app will run slightly faster. But a program written in machine code will always be faster still. There will come a point when the speed disadvantage is outweighed by all the benefits of web apps - and that time is near. The biggest issues with web apps are: - Development. Creating web apps requires writing code in at least 3 different languages, including server code, client code, and markup code. Try making an iOS paint app that saves your drawing to the cloud. Then try doing it as a web app. If you think this is easy, believe me, Objective C is a drrreeeam. - Discovery. The App Store/Google Play are the best ways to discover new apps. There exists no such popular and lively platform for web app discovery, review, and sales. - Browser and OS Dependency. Mobile browsers don't all allow access to the camera, easy installation to the home screen, and all the access to APIs a full-featured app should have. So let us be constructive from now on, and focus on fixing these issues, instead of giving up and locking ourselves into reliance on yet another company (Flash, iOS, Android, etc).
idont 14y ago
This reminds me when (Adobe) Flash evangelists were requesting us to join their "better experience" ecosystem... (10 years ago?)

13 points by dirkdk 14y ago

Is there a good reason not to believe that mobile will eventually swing to HTML, for the same reasons that desktop apps yielded to web apps?

deleted 14y ago
[deleted]
dirkdk 14y ago
in due time, not really. However, as mobile is a very much evolving platform, for the next few years native code will have earlier access to new features before html through additional api's has.
Silhouette 14y ago
In general, I don't think desktop apps have yielded to web apps. Web apps have worked well for projects that are essentially simple front-ends to a database or simple content distribution systems, which admittedly represents a very significant part of the software industry. These tools inherently require some sort of client-server system, so there's no architectural overhead there that you weren't going to have anyway. Also, with web apps you get cross-platform portability very cheaply, and you get zero-effort deployment instead of trying to deal with installation/upgrades of software on say Windows where the plot was lost long ago and no-one has ever restored sanity. However, when you come to doing anything that requires non-trivial interactions or non-trivial processing, web apps are often still decades behind the state of the art for mature desktop applications. No-one does serious graphics work, or mathematical modelling/simulation, or FPS gaming in web apps today. I suspect we never will, because we'll develop (rediscover?) how to build such applications with a specialised thin client and/or how to push out and maintain software with a native thick client more effectively long before we bastardise a text mark-up language and its friends well enough to write serious software as web apps in general.
- gruseom 14y ago
  Of course you're right that some domains (e.g. graphics) are harder than others, but you might be overstating your case. Surely Gmail requires "non-trivial interactions". And why not mathematical modelling/simulation? — you can access a lot more computational power on servers. And how often does one hear of a startup making new desktop software? I like your point that we might figure out how to get desktop deployment right sooner than how to adapt the web to do all these things. But nearly all the innovation has been pointing in the other direction. Also, such a deployment technology would face formidable institutional barriers.
  - timburks 14y ago
    The Gmail native iOS app is really nice, so the flow of innovation isn't consistently pointing towards the web. But part of the answer to getting "desktop deployment right" is sandboxing. In essence, the native app platforms are making operating systems more like web browsers, while projects like Mozilla and Chrome are trying to turn web browsers into operating systems.
  - Silhouette 14y ago
    Surely Gmail requires "non-trivial interactions". Yes and no. GMail is arguably one of the most successful and mature web apps out there, but at the end of the day you're still just reading mail, clicking a few places to change how information is presented, and typing a bunch of text. None of this requires a lot of real-time assistance as you navigate the information, context-sensitive UI, or task-specific controls beyond regular menu/toolbar/icon kinds of things, for example. And why not mathematical modelling/simulation? — you can access a lot more computational power on servers. Well, I think that point is debatable if you're doing serious modelling more than occasionally. The kind of processing power required makes it cheaper to buy your own high-end systems than to use commodity cloud-provided facilities very quickly, and for the same reason I suspect it would be difficult to offer such services economically in SaaS form. Also, real time graphic visualisations in web apps are still far slower and less sophisticated than what you can achieve natively with modern graphics cards, at least for now. If you're watching a couple of pretty graphics in an analytics tool, that doesn't matter. Even some basic 3D work is starting to get interesting with technologies like WebGL arriving. But for real-time rendering and navigation of global weather patterns or the design of a cruise ship? I don't see that being done remotely any time soon. And how often does one hear of a startup making new desktop software? I'm not sure how often one hears about start-ups doing something is a very useful metric, really. The culture on HN is particularly biased towards that field, but in reality there are millions of programmers out there working on desktop software. New bespoke desktop applications are being written for businesses all the time, and likewise tools, toys, games and more are written by small software shops for individuals all the time. But nearly all the innovation has been pointing in the other direction. Really? I'd say the mobile "app store" model and the Linux "distribution" model have both been very successful at getting native software deployed onto users' systems, too. It's just a shame that we still have horrible deployment practices and dependency management on most desktop platforms, much of it due to the stagnation of desktop OS architectures and the continued use of strategies that were originally designed to cope with limited resources but that have been obsolete for years now.

andybak 14y ago

Mobile OS developers, don’t be lazy, give me a half decent language that doesn't make my eyes bleed.

dirkdk 14y ago
yep, Objective-C sucks. But Javascript, is that such a straightforward language? You might think that because you are familiair with it, but I remember learning it after Java and that was not a good experience.
- timburks 14y ago
  No, it doesn't. C++ sucks.
jspthrowaway2 14y ago
Fine, I'll bite. Assuming you're belittling Objective-C, let's not forget that Objective-C is simply C with Smalltalk bolted on. I'm having a hard time imagining a plane of reality in which either is not "half decent". Objective-C is, in my opinion, much better than C++ to accomplish the same task (they have semi-equivalent aims, though implemented very, very differently). I learned Objective-C and iOS (then called iPhone OS) from scratch to write a quite-complex app once. The app has been in the store for two years now. Like you, initially, I balked at the brackets; everybody does. Eventually, I was actually pleased that my C experience carried over so well, and it was a pleasant experience in the end. As you do, I wrote two to throw away until I mastered the platform, and I didn't mind it at all. Assuming your object user has an update method which takes a name argument and you want to store the result of calling update somewhere, here's Python vs. Objective-C (the Smalltalk-influenced terminology is different, but the concepts are the same): save_result(user.update(name="Larry")) saveResult([user updateWithName:"Larry"]); I don't find one much more horrible than the other.
- krichman 14y ago
  Objective C is brilliant, it's one of the few things I actually enjoy about Apple's ecosystem. This is because it stole ideas from Smalltalk, which is also brilliant. I doubt there are many people who hate it rationally, but I'd love to have a discussion with them instead of the people that have some knee-jerk reaction to the message-passing syntax.

timburks 14y ago

Vishal Gurbuxani gave us the marketing perspective on this last month in Napa: http://www.slideshare.net/vgurbuxani/app-retreat-2012 http://www.slideshare.net/vgurbuxani/app-retreat-2012 One major problem: HTML5 is fragmented across platforms and is missing important ingredients needed by app businesses. In the end, it's just another platform, and not a very good one if a good user experience is something that you hope to deliver. Read Vishal's slides for more, or come ask him about them at his session at Renaissance: http://renaissance.io/speakers/vishal_gurbuxani http://renaissance.io/speakers/vishal_gurbuxani

eddieroger 14y ago

I tend to agree. Even a properly optimized, Simonized and Vulcanized app needs to be run through a browser layer, which inherently slows things down. Javascript bridges to native functionality are messy and can fail. And for what? Writing one code base? How much client-side logic are you really doing that you don't want to replicate? Any mobile app I write that requires server logic is basically just a view, so it needs to accept and manipulate JSON. Interface Builder gets you an interface in minutes (of course, you can spend time tweaking it), and there are dozens of networking libraries that consume a service and spit out native objects (if that's your thing). At the risk of speaking in absolutes, you will never get a better experience than a native, first-class one. Ask Facebook - it didn't work out so well for them.

darrencauthon 14y ago

"Native technology allows for excellent apps, whereas HTML5 apps will be at best just OK" Sometimes "just OK" is what people want, and what meets the needs of the business. The truth is -- building a mobile web app can be fast and can fill an iPhone/Android/Blackberry/Windows phone with the content and interactivity the business and users need and want. It can also be much cheaper. Different businesses have different values, and whatever works best to achieve those values is best. Calling devs lazy for not learning native mobile languages seems like a cheap way to get clicks. New Year's Resolution: Stop clicking on them.

jefflinwood 14y ago

Some of the impetus towards cross platform HTML5 development was probably because the state of Android app design in the 2.x era was so bad. You could basically get away with using an iOS-look-alike web toolkit on Android in a WebView, and it was "good enough". With Ice Cream Sandwich, the new Holo look and feel actually has a real design language that is markedly different from an iOS app. As to Windows Phone - there is such a strong design for Windows Phone apps that those jQuery Mobile apps in their app store look really out of place. Microsoft's working on some CSS that will make jQuery Mobile apps look more native, but it's still missing some of the key Windows Phone UI like panorama. From developing HTML5 and native mobile apps for iOS and Android, and from follow ups on some mobile application strategy consults, HTML5 mobile apps just don't deliver a good user experience, especially if the app does anything other than content consumption.

mistercow 14y ago

Not doing native development isn't about laziness. It's about freedom and flexibility. As much as is possible, you should strive to minimize your dependence on any single company (at least until you have some clout), and having a code base that is locked to a closed platform breaks that principle. And look, what I'm saying here isn't ideologically motivated. It comes from hard experience. If I had a dollar for every time I sat on a blanket with two corners held by a single company, and then got that blanket yanked out from under me, well... I'd have three dollars.

Silhouette 14y ago

There's an old Chinese proverb: "A man who says it cannot be done should not interrupt the man who is doing it." That's the feeling I get from opinion pieces like this. I've developed web-based user interfaces for several projects in recent years, some of them with a strong mobile focus. I'm still waiting for all these demons to come and bite us, where our paying customers don't find the experience satisfactory and run away to the competitors who are going to beat us by having a highly polished native app instead. Sure, there are occasional irritations with mobile browsers. Many of them, perhaps even the majority I've come across, are actually by design because Apple actively chose not to make their browser work like everyone else's... again. But do we spend as much effort getting our web apps to run effectively across all the major platforms (including Windows) as we'd have to spend writing a native UI on every platform we want to support? Not even close. And native apps still have the same horrible downsides as ever: the app store approval lottery, Apple wanting a huge cut of any money you make, yada yada. If I were running Facebook, where for practical purposes the budget and developer time required to develop a mobile app on every platform were negligible, sure, maybe it's worth it for a more polished experience. (Maybe.) But for more modest projects, where resources are finite and we don't magically have developers on tap who speak a different "native" language for each platform, I can spend the time and money once to build the web app and then the same again refining it or I can spend the time and money twice just to get the basics done without any polish. I don't understand how anyone who has actually done this can be in any doubt about which gets better results.

javis 14y ago

Mobile OS developers, don't be lazy and give me a way of embedding HTML5 into an app that doesn't completely ruin the whole experience. Seriously, a web app will be running beautifully in Mobile Safari, but when I put the same code into a WebView, it all goes to shit.

dirkdk 14y ago
Yep, running a web site in an hybrid iOS app will slow down your app, as the Nitro Javascript engine is not available. That has been the case for a while, because of security reasons, and won't go away any time soon

hunvreus 14y ago

One of the obvious reasons some teams may not go for native is that they don't have the resources to commit to maintaining two applications. Having 2 teams, contracting an external agency or finding a developer versed in both platforms are all pricey options. If your product is not the mobile apps themselves (obviously), HTML5 or Titanium can get you there without stretching your resources.

greenyoda 14y ago

It's not laziness, it's an economic decision. Learning a development environment like iOS or Android takes quite a bit of time and effort (especially if it's not your day job). If you believe that by the time you become proficient, HTML-5 will have improved enough to significantly decrease the demand for native apps, then you should spend your time learning something more valuable. Also, lots of people have already learned native app development, and it's increasingly becoming a commodity skill that, at least for simple apps, can be outsourced to the lowest bidder. Developers might believe that learning skills that are not as easily outsourced, such as data analysis, might be a better investment. Finally, learning a fast-changing environment like mobile apps is a much bigger investment than just learning a mobile language. It's a large, ongoing effort to stay current with the new features in every new release of the platform. So please let's not call people lazy just because they're not jumping on our favorite bandwagon.

mos2 14y ago

What about Ruby Motion for iOS? Its commercial ($200 a license) but offers native objective-c compiled from ruby and is based on the open source mac ruby project. This seems smart as you only have to learn the cocoa framework and you learn a little bit of objective-c. Whats nice if you want to go native and or optimize by writing straight objective-c you are halfway there. Everything else I have looked at is basically a web browser attempting to be a full app. I would love to hear if anyone has written an iOS app that is on the app store with it and what there experience has been.

gte910h 14y ago
> as you only have to learn the cocoa framework This is the hard part. The objective C part isn't.

dmotz 14y ago

I think this argument, ad hominem aside, loses a bit of validity with every subsequent smartphone/tablet generation. Every advance in CPUs and JavaScript interpreters blurs the line more if we're looking at a hybrid app developed by a competent team. As to where I'm coming from in this argument, yes, I currently develop mobile apps using web technologies. [1] And yes, I completely agree that the majority of web view/hybrid apps I've encountered have had poor user experiences. But the field of hybrid apps is new and everyone can recall the poor user experiences of desktop web apps in their nascent era. As with the age of MapQuest, the sample size of hybrid apps is still small and thus well-designed and well-coded apps are scarce. Aesthetics give probably the biggest impression of mobile software quality, and you can either choose to stick to stock SDK UI, or implement your own visual language. The former is safe and is the default for native development. Hybrid apps almost always fail when trying to mimic it completely and users are (at least subconsciously) repelled by the uncanny valley these apps may land in. The latter option of introducing a unique UI is exceedingly difficult to pull off, hybrid or native, but is a route of convenience for hybrid developers, but again, they usually fail to create something a user can feel comfortable with. In short, if you're serious about your app's reception, it is more difficult to pull off the user experience using web technologies, contrary to the article's assertion. Hybrid app developers cannot rely on native UI elements and this is why they tend to be received so poorly. So why have I chosen the hybrid approach? Mainly because I'm a futurist and I see the immense value in having an open lingua franca for app development over fractured proprietary environments. The cross platform benefits appeal to me less, and at the time of this writing, I consider iOS to be ahead of the other platforms in fidelity of rendering web content (Android 4 is catching up). I fully admit this benefit is half-baked at the moment, but I don't need any pundit predictions to know it will improve by bounds in the next few years. JS isn't a silver bullet, but it's undeniably exploding at the moment, especially in terms of flexibility (browser, server, mobile). You could invest your time in mastering a proprietary platform's SDK, but besides only focusing on non-portable knowledge, you could also find yourself with a dying marketshare for your chosen platform. I definitely don't mean to discredit native languages by any means, I just want to convey how I came to conclude that hybrid is a safe investment in mastering. Many apps, whether simple CRUD apps, or thin front ends for REST APIs, have no specific need for native code. Even Microsoft --seen among the symbols of proprietary control -- are embracing the HTML5 stack for apps. The benefit of being able to reuse the libraries and APIs [2] when bringing an app to another platform shouldn't be underestimated, nor the potential growth of mobile-oriented common knowledge in a common language. Is it really difficult to believe that in a few years phones will be running WebGL-powered 3D games with advanced shader effects, on par with native games? Not really, considering how rapidly we're approaching that point on the desktop. It's even easier when you consider the hybrid app bottleneck is usually DOM painting, not JS execution, and WebGL would potentially use the mobile device's GPU. This problem is almost solved already with intelligent DOM manipulation and CSS3 transforms, (or potentially other approaches [3]). Writing a quality hybrid app at the moment is very hard. Web views have less memory available, execution is slower, and simple DOM rendering is expensive and slow unless all optimized properly. Furthermore, aesthetics are harder to pull off when working outside SDK UI sets. But hybrid apps are a relatively new field and have enormous potential. I don't it's very mature yet, but neither was the web itself for a very long time. I think having a common, open set of tools is worth defending from accusations like this one or the red herrings thrown around regarding HTML5's role in the Facebook app. This is definitely the more forward-thinking bet. [1] - http://chaincalapp.com http://chaincalapp.com [2] - specifically HTML5 device APIs as well as http://phonegap.com http://phonegap.com [3] - http://famo.us http://famo.us

chrisringrose 14y ago

It's lazy to give up and devote all your energies on yet another company's proprietary platform. Instead of constantly writing articles like this, how about we focus on the obstacles web apps face, and fix them. Sure, if both a web app and native app are programmed optimally, the native app will run slightly faster. But a program written in machine code will always be faster still. There will come a point when the speed disadvantage is outweighed by all the benefits of web apps - and that time is near. The biggest issues with web apps are: - Development. Creating web apps requires writing code in at least 3 different languages, including server code, client code, and markup code. Try making an iOS paint app that saves your drawing to the cloud. Then try doing it as a web app. If you think this is easy, believe me, Objective C is a drrreeeam. - Discovery. The App Store/Google Play are the best ways to discover new apps. There exists no such popular and lively platform for web app discovery, review, and sales. - Browser and OS Dependency. Mobile browsers don't all allow access to the camera, easy installation to the home screen, and all the access to APIs a full-featured app should have. So let us be constructive from now on, and focus on fixing these issues, instead of giving up and locking ourselves into reliance on yet another company (Flash, iOS, Android, etc).

idont 14y ago

This reminds me when (Adobe) Flash evangelists were requesting us to join their "better experience" ecosystem... (10 years ago?)