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.
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.
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.
"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.
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).
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.
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
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.
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.
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.
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.
I think you underestimate how much is going on in an app like Gmail, and also the extent to which people have figured out how to do things like "real-time assistance as you navigate the information, context-sensitive UI, [and] task-specific controls" in the browser. Those problems are mostly solved. Some things, like rich text editing, still suck.
I'm not sure how often one hears about start-ups doing something is a very useful metric, really.
Startups aren't what drives tech innovation in markets? That seems at odds with history. Millions of programmers may be doing as you say, but that's mostly legacy. Are they creating fundamentally new things? What is the most recent desktop app that you could call innovative, apart from pushing the envelope on graphics?
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.
I guess Apple have integrated desktop deployment into their App Store (rather to my annoyance actually) and MS are about to do the same, or try to. Perhaps the habits people have acquired around downloading and installing mobile apps will end by triggering a renaissance in desktop applications. But I won't believe that I until I see major new applications being built this way.
I think you underestimate how much is going on in an app like Gmail
I've no doubt they do all kinds of clever things behind the scenes, from detecting things like malware and spam to all the analysis Google do for their own purposes.
Still, relatively speaking, I don't think the front end for an e-mail client is very complicated. And there's nothing wrong with that, because it doesn't need to be: its job is to manipulate a small amount of data (from the user's point of view, with a simple structure, which doesn't change very much and doesn't have a lot of dependencies.
This is all true of most major web apps, as far as I can see.
..."real-time assistance as you navigate the information, context-sensitive UI, [and] task-specific controls" in the browser. Those problems are mostly solved.
Don't you think "mostly solved" is overstating the case a little? Even web apps whose UIs we might call mature or advanced today rarely offer more than what desktop WIMP UIs were doing 10 or even 20 years ago. As you mentioned, even common operations like editing formatted text are often still below par. Truly task-specific UIs, the equivalent of say a three-way diff/merge tool or a space flight simulator game on the desktop, seem to be extremely rare in web apps.
Startups aren't what drives tech innovation in markets?
Start-ups can certainly drive innovation, though obviously this particular forum has a built-in bias and I think a lot of posters here tend to overrate the importance of any one start-up or of start-ups generally.
However, I don't think whether or not we've heard of start-ups means very much. It's a big world, and most of us will only ever see a tiny fraction of it. Lots of the innovation happens in small businesses that help larger businesses or other non-consumer fields like academic research or government departments behind the scenes. These things don't tend to be very visible to the general public, and probably won't get you on the front page of HN or written up on TechCrunch. Plenty of these projects involve developing desktop apps.
What is the most recent desktop app that you could call innovative, apart from pushing the envelope on graphics?
I can't give personal examples from my own work unfortunately, so instead let me ask you this: have you been to a movie lately? Did you notice all the CGI special effects? Not the robots and zombies and futuristic home automation, the other ones. The answer is probably "not even close", because the programs the SFX wizards use to create those effects are now so powerful that the results really do go unnoticed a lot of the time, as they should. These things are done with a vast array of bespoke software that is evolving all the time, some of it off-the-shelf but a significant chunk built in-house for major projects. And they're not building web apps. (Most of the time. ;-))
Perhaps the habits people have acquired around downloading and installing mobile apps will end by triggering a renaissance in desktop applications. But I won't believe that I until I see major new applications being built this way.
I tend to agree. I fear that ship has now sailed, but it would be nice to think that the groups behind the significant desktop platforms could still come up with a sane way to install and update applications.
It's crazy that in 2012 (just...) we still rely on each application's installer/uninstaller/package manager/update process to copy files into basically arbitrary locations, some of which may be shared with other software, set up hidden details like registry entries, even hack around global system configuration or perform dark magic for product activation/DRM purposes. And then we expect to install more than two things and have them play nicely together, and then uninstall in some arbitrary order and still have them play nice together.
(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.
It's an interesting demo, but all it really proves as far as viability goes is that today's web apps could keep up with what id and co were producing on the desktop more than a decade ago. There is a long way from that to running a AAA quality FPS in-browser.
Apart from high performance apps, the top 10 successful tech businesses in the last 10 years have been web apps.
I'm curious about what measure you're using there.
Looking at the data from the Fortune Global 500 for 2012[1]:
The most profitable tech companies are mostly in hardware and/or consultancy: Apple, IBM, Samsung...
The only primarily software company that keeps up with Apple is Microsoft, coming in at numbers 3 and 4 respectively (both at 20-something billion USD in profits).
The top primarily web company is Google, coming in at number 18 with under $10B, still nothing to be sneezed at of course but in no danger of walking away with the prize any time soon.
The web company you mentioned, Facebook, isn't in the same division in financial terms. Nor are the likes of Salesforce.com or the assorted darlings of the web app world.
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.
Why can't I just do what I do with most other desktop software today: buy it on-line, download the installer, and run it?
The FPS demo is just that: a demo. It's not made by a game company. It's not made by iD. It's a demo made to run on as many desktops as possible, unlike anything by iD, which pushes graphics to the limit. Graphics are your issue with this demo? A game company can make an HTML5 FPS with amazing graphics. There is no reason why they can't.
To clarify: the top 10 successful new tech businesses. And not necessarily financially, but that have the most impact. Also, this is a discussion about software. Sure, IBM has made a ton of money compared to Facebook. They have long-term contracts with governments and businesses worldwide; making money for IBM means waking up tomorrow. But they're boring. They're the successful company that makes all the screws; vital to the world, hugely profitable, but boring. I'm talking about new tech software companies you've actually heard of, and use their service every single day. When anyone talks about new startups, they inevitably mean a web-based company.
Okay, so Facebook launches as a downloadable EXE? What about Amazon, or Twitter? Everyone has to install it to use it. There has to be a Mac version, and a Linux version. Then the iOS and Android versions. Everything is native apps. This is a terrible ideal world you live in.
The FPS demo is just that: a demo. It's not made by a game company.
Sure, I realise that. I'm just saying, maybe it won't be quite as soon as you're thinking that we see high performance web apps.
When anyone talks about new startups, they inevitably mean a web-based company.
Not around here (Cambridge, UK) they don't. There are plenty of tech start-ups just down the road from me, many spun off from connections to the university and research done there. Some of them make web apps, of course, but most of them don't.
I suspect, with no offence intended, that you're probably seeing through the kind of HN-vision I mentioned in another post.
Everything is native apps. This is a terrible ideal world you live in.
I'm certainly not arguing that everything should be done with native apps. In fact, in my first post to this discussion[1], I argued rather strongly against making native apps for things where a web app works fine.
There are pros and cons to each approach, and I'm just saying that I don't think arguing that desktop apps are dead makes any more sense than arguing for building native apps on every platform so you could use a simple on-line database when a single web app would do just as well or (by my original argument) perhaps better. There is plenty of room for both approaches, and as always, we should choose whichever tool best does any given job.
Well at least I knocked you down from saying we'll never see FPS in the browser to okay-maybe-but-not-all-that-soon. Perhaps I can take you one step further, and inform you that a browser-based FPS on Facebook has over a million active players. https://www.facebook.com/appcenter/uberstrike?fb_source=sear...
I saw your previous comment earlier, and even gave it an up-vote. I'm new to Hacker News, but perhaps some day I'll have the right to down-vote; and when I do, I won't use it simply because I disagree with someone.
In other words, the number one selling laptop today can't run any desktop applications - just web apps. I'm a developer, and I simply can't ignore this.
It's time to focus our efforts on fixing the obstacles web apps face, instead of doubling-down on desktop/native apps because they're easier to make, or run slightly faster.
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.
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.
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.
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.
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.
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.
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):
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.)
I actually vastly prefer a language without namespaces, and the naming conventions are not due to the absence of namespaces. You're talking about the NextStep API (the "NS") and the conventions that were born from that -- there is no mandate nor impetus (and, I don't recall Xcode automatically doing it for me) that you use that convention yourself. They just carried it through for the other APIs, like UIKit being "UI" (UIViewController, etc).
My User object was called, unsurprisingly, "User". [[User alloc] init].
As for interop with C++, Objective-C++ exists and is used for apps in the store. (Hint: 3D games that are ports.)
XCode has a setting in a new project to prepend to all class names. The necessity of that sort of feature indicates a failure of linguistic design (by which I mean the necessity of clearing up symbol pollution--there is also an argument for their use for explicitness, which I reject because the world has shown us its obvious failure).
Even just aesthetically--vomiting out half-line identifiers every time I have to refer to a class is, for me, painful and stupid and makes me hate reading what I've written. One of the worst feelings in the world is looking at code you've written and hating even looking at it, and for me there are only three languages I've spent time with where that's the case for reasons beyond me fucking up: Java, Scala--for reasons entirely unrelated to its Java heritage, it makes its own mistakes--and Objective-C.
As for Objective-C++, it's useful in a limited capacity but often requires unscrewing your object model in pretty stupid ways just to provide inputs that the Objective-C side won't barf on. It's an "ehh" hack with painful edge cases.
I shouldn't have bitten. This is like arguing over why a Phillips screwdriver is better than a flathead with someone who particularly and angrily hates Phillips screwdrivers because he doesn't like their appearance. They're tools, bud.
I'm pulling my rip cord on this discussion based on your tone, the nearly guaranteed futility, and the complete lack of any realizable benefit in my own life of carrying on. Good evening.
Your screwdriver analogy doesn't really apply. Language choice has ramifications beyond 'appearance' and you know it. I'm afraid I don't believe that you really don't care about your choice of tools.
With every passing moment I regret replying to this thread more and more. You completely missed how my analogy works, actually, since you think I'm limiting the problem domain to appearance (I'm not; I'm characterizing someone ELSE'S displeasure).
I wish the privilege to delete didn't disappear after a time, so I could wash my hands of this thread and forget that I ever spent more than ten minutes on it.
> I actually vastly prefer a language without namespaces,
All languages have namespaces. It's clear you don't understand the concept. A namespace is an abstract container to provide context and ensure uniqueness between items with the same name. User is a namespace. Since you have a global namespace, you have to prefix the name to make another type of User. So yes, naming conventions (which are namespaces that are not enforced by the compiler) are due to the absence of namespaces as a construct. Sheesh.
Sigh. I understand that perfectly, and I thought it would be implied that I meant "multiple user-defined namespaces" where I, and the commenter I replied to, typed the shorter "namespaces". Sheesh. Bring the pedantry, eh?
Your vitriol is uncalled for, and since it's only your second comment ever, you should pause a moment to consider whether Hacker News is the community for you (judging by the two comments you've left so far, it isn't; I recommend Reddit for dick jokes and personal attacks on comprehension).
"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.
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.
I dislike it because the code samples I see look really ugly and hard to follow.
Now maybe that melts away when you learn the language but I've heard enough complaints from people who have to get the feeling that's not entirely the case.
Readability is probably the most important language feature.
"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.
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.
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.