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

http://blog.mobtest.com/2012/12/web-developers-dont-be-lazy-and-learn-a-native-mobile-language/

by dirkdk • 14 years ago

13 45 14 years ago

blog.mobtest.com

gruseom3• 14 years 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?

dirkdk3• 14 years 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.

Silhouette6• 14 years 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.

gruseom3• 14 years 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.

chrisringrose5• 14 years ago

I think we will see FPS gaming and high-performance apps as web apps. And very soon. Try this FPS demo: https://developer.mozilla.org/en-US/demos/detail/bananabread

(It's not made by a game development team, but tech nerds at Mozilla, showcasing what new HTML5 tech can do. A real game company could go nuts with this.)

Also... Desktop apps have died. Apart from high performance apps, the top 10 successful tech businesses in the last 10 years have been web apps. Imagine Facebook launching as a desktop app. You buy a CD at Target, and install it, connect, and type in the app to communicate. It's a laughable idea.

andybak3• 14 years ago

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

dirkdk3• 14 years 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.

timburks3• 14 years ago

No, it doesn't. C++ sucks.

jspthrowaway25• 14 years 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• 14 years 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.

eropple2• 14 years ago

It's not just the brackets, though they're ugly and provide stops for the eyes where none should be; you have NSReallyReallyLongNames all over the place (encouraged by XCode, to the point of automatically doing it for your own classes, because namespaces are apparently too modern), required parameter names, and other silliness that makes Java look restrained. And while we're at it, its interop with an actual, fairly standardized modern (note: this means "not C") language that people use (so C++, for those keeping track at home) is not very good, and while you might find Objective-C superior nobody else uses it so C++ is probably going to be involved somewhere, be it Windows or Android.

Objective-C is tolerable, sure, but I'd rather write C++ - and that is no compliment to C++. (But, as a side note, I give Apple all the credit in the world for having a fantastic C++ environment on its own. XCode has its stupid spots, but it doesn't get in clang's way.)

Turing_Machine• 14 years ago

"I'm having a hard time imagining a plane of reality in which either is not "half decent""

Garlic is good. Ice cream is good. That doesn't mean that garlic ice cream is necessarily good. It exists as a promotional gimmick, sure enough, but it won't be in Baskin Robbins any time soon.

plinkplonk• 14 years ago

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

One can always mix first rate components badly to create abominations. Not saying Objective C is an abomination, but pointing to the coherence of the underlying languages is not much of a defence of the clarity of Objective C.

timburks3• 14 years ago

Vishal Gurbuxani gave us the marketing perspective on this last month in Napa: 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

eddieroger• 14 years 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• 14 years 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• 14 years 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• 14 years 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.

Silhouette6• 14 years 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• 14 years 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.

dirkdk3• 14 years 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• 14 years 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• 14 years 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• 14 years 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• 14 years ago

> as you only have to learn the cocoa framework

This is the hard part. The objective C part isn't.

dmotz• 14 years 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

[2] - specifically HTML5 device APIs as well as http://phonegap.com

[3] http://famo.us

chrisringrose5• 14 years 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• 14 years ago

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

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

Related Stories