The primary advantage of a web platform for webby, desktop and mobile applications is to be able to write one set of code that works on all devices.
It seems strange to me that so many young developers don't seem to comprehend why that is a big advantage.
I want to code in CoffeeScript and use nice simple APIs.
I'm sorry but Objective-C is outdated and overly complex. The only reason people accept and even learn to love it is because if you are an Apple person you have to. You have no choice in the matter. Its like people in North Korea have to love their Dear Father Leader or something.
I'm sure the Android Java libraries are much better than before, but they are still based on what I consider to be a dated type of development. The framework APIs are inferior and constantly specifying types is unnecessary.
To me CoffeeScript with Node.js modules are the state of the art in terms of language design, dependency management, and API design.
Maybe they are old enough to remember the last time someone promised write once run everywhere.
It's a bit ironic that Java finally caught on as an interactive programming language once it was put into a runtime environment that is intimately joined to the design of the Android OS?
Operating systems have substantial differences, and they compete based on those differences. Apps that ignore the unique features of each OS they run on are impoverished and uncompetitive.
I've been programming for 20+ years and have coded in nearly everything from ASM, old school PASCAL, and FoxPro to Java, Lisp, VHDL, Erlang, OCaml. I can say without a doubt that coding in CS (with LESS, Bootstrap, Backbone/Underscore) is one of the best experiences I've had. While there are still numerous things to complain about in this environment, the best thing is that it makes me extremely productive in designing UI-driven apps.
Currently I'm working on a project that is extremely heavy on the client-side and despite being the solo front-end coder, the four back-end folks can't keep up with my (RESET API) demands. Not that I am some rockstar 10x programmer - it's just that the current environment makes me the most productive I can be. With a few scripts and editor shortcuts, my workflow from code change to browser-refresh is near instantaneous.
Actually, I think the case for web gets even more compelling with Meteor, where you can really share components across both sides of the wire.
As I alluded to at the end, the web case makes a lot of sense for companies with unique services who want to roll out across platforms. e.g. If you're a corporate insurance broker, you have a few hundred users who just want some conveniences from native apps, that's a good case for HTML5.
Another example I saw recently is an agency making "viral" apps. Just one-time apps for short contests and so on, and they can do a great job with HTML5.
Deep-level integration though needs native, whether you like Obj-C or not.
Yes Meteor is very amazing. Of course they have another HTML5 thing in WebRTC that when it becomes well supported (actually fairly soon in Firefox and Chrome) has peer-to-peer data capabilities that for many applications supersede server-based models. Of course, I know that for some applications, that won't be workable, and there are problems to solve, but I believe that most of the problems with synchronization and data ownership have reasonable solutions in peer environments.
I am still hoping that PhoneGap/Cordova will work out ok for my next 'native' app. Have you found that it isn't adequate?
I'm the OP, so yes, I found it inadequate :). For a podcast app, even using PhoneGap (rather than browser-based web app) would lead to several issues:
* Hard or impossible to do rich, interactive widgets, notifications, and lock-screen in HTML5
* Unclear path for downloading and saving large files. (Might be possible, but again would need native bridges or native code; forget about Ajax and offline HTML5 storage.)
* Mediocre UI. If you work hard at it, you can build a reasonable UI, but one of the feedbacks we got from reviews and reporters is how they like the way we implemented Android's Holo look-and-feel. A lot of people feel an emotional attachment to their OS and appreciate apps that fit within the guidelines.
Over the years I've learned in the region of 40 programming languages and am fluent in about a dozen. I spent 9 years as a web developer and switched to iOS using ObjC a couple of years ago.
Objective-C is by far my favorite language. I can code up an ObjC solution to a problem far faster than I could with JavaScript, C, C++, C#, Java, Python or anything else I've used. I adore ObjC's meta programming capabilities, its simplicity, its fixes for issues I encountered in C++, the way it gives high-level abstractions if I want them but allows me to drop to low-level C if I need to, and its encouragement of self-documenting code.
More importantly than any of that, I have more fun with Objective-C than any other language.
Discoverability and system integration are huge problems, sure, but Cordova mostly addresses these concerns.
The reason everyone always cites for going native is "performance", but, tbh, it seems like most web projects don't pay attention to the same level of detail as native apps because the web is so much faster to prototype. I bet if devs spent the same amount of time working on perf and loading states on the web as they did on native, the performance argument would have much less impact.
We tried testing that theory, having one team prototype the same app using web technologies and the other prototyping it using iOS native technologies. iOS appeared to be the faster of the two.
The vast majority of the work was prototypeable in Storyboards directly, and only required, if I recall correctly, around 20 lines of code for supporting requirements to build out the prototype. I haven't found many tools for the web that can compete with that.
Of course it depends on what you are trying to develop. If your application is document-centric, then it will be difficult to beat HTML. That is, after all, what it is designed for. But for an application-centric design, I'm not sure it is really all that fast as a prototyping platform – unless, I suppose, that is all you know. It does take time to ramp up familiarity with new platforms.
Objective-C is so beautiful in those regards. So many things are abstracted and optimized for you already, especially compared to Android and their libraries. Rapid prototyping is insanely fast if you can handle yourself in Xcode and around Obj-C.
You make me curious. Could you provide some examples of the benefits of Objective-C in this context? (and how it compares to Android and its libraries).
I think I see where he is coming from. They are not exactly separable.
Interface Builder is more than just an interface builder, it is a serialized data builder. That distinction means that you can instantiate virtually any class in your project without having to write a line of code. It is not limited to just UI elements. That turns out to be pretty powerful.
Below that level, the deserializer exploits a number of properties of the Objective-C's dynamic runtime in order to provide that instantiation of random objects and properties. There are certainly other languages that can be exploited in the same way, but it is not something that can be done directly in just any language.
Without Objective-C, or at least something like it, there would be no Interface Builder as we know it today.
There are entire types of things not possible in web apps, such as true threading with a dedicated processor, accessing OpenGL accelerator support with custom shaders, getting at purposeful hardware support in general, whose reason for existence was cumulative need over more apps for more years than JavaScript and doms have existed.
The great big bullet point features (like OpenGL) are getting added. It's the small, subtle features that are being neglected.
The test case that I'd like to see is someone replacing notepad.exe with a webapp in such a way that an end user cannot tell that a change has been done. It's the Turing test of usability. Web Apps can do an excellent editor, but the finer details like (associate *.txt, save, save-as etc.) are still a problem.
There are things native can do that webapps can't, but the two examples you gave aren't among them. You write custom shaders with webgl, and make use of multiple processors with web workers (though they are more analogous to processes than threads, as they don't share state).
I understand that attempting to write once, run everywhere doesn't make for a good user experience. For the best experience, it will probably always be necessary to develop a different front-end for each platform.
However, what does one do for logic that belongs on the user's 'device (i.e. client-side) and will be the same on all platforms? Especially considering that one of the targeted platforms may well be the Web.
One solution is to use the Xamarin suite for native targets, and something like Script# or JSIL for the Web. Of course, Script# and JSIL can only support a subset of .NET functionality, e.g. no shared-memory threads and therefore no blocking APIs (unless one of these compilers can transform code into continuation-passing style). Another possible solution is Haxe, which can compile to JS, Java, and C++ among others. The trouble with both of these solution is that when working on the Web version of the app, one has to know both the Web stack and the other language.
It seems to me that the best solution is to write all platform-independent client code in JavaScript, minimizing the use of browser APIs for that code (e.g. only XHR and setTimeout). Then, for the native mobile versions of the app, integrate a JS engine (note: not a web view), find or write stand-alone implementations of XHR and whatever other APIs one needs, then write the front-end in the native language for that platform.
Any thoughts on this? For native mobile apps, are we stuck rewriting everything in ObjC and Java, and maybe also writing a JS version for the web?
The idea that you have to be a "native person" or a "web person" is ridiculous. Let's just use the tools that make the most sense for the project at hand.
The idea that you have to be a "law person" or a "medicine person" is ridiculous. Let's just use the tools that make the most sense for the project at hand.
Uhm what? If you are law person you deal with law, if you are medicine person you deal with diseases.
How does this apply to the situation where you deal with apps, only done using different tools?
It's all specialisation and one human mind can only do so many things. The web side alone is vast now. It's a common conversation in the web community about how a new developer is supposed to pick everything up.
I agree if you're a company, you can't afford to turn your nose at one or the other. But there's few unicorns who can build excellent apps in all of web, Android, and iOS. And despite a lot of software mythology, I don't believe most programmers can just learn a platform in a few days, not to be seriously capable at it.
In my experience, people who claim to do both iOS and Android development well vastly overestimate their abilities. At the highest levels, writing an iOS or Android app is like being a game developer and pushing the platform to its limits (in a non-hacky way). To attack the problem of smooth scrolling, ~60fps on a list (especially one doing async fetches and/or database and/or complex cell layouts) requires different experience and knowledge on each platform. To build a beautiful app (not an average app) on either platform, requires almost a craftsman-level touch and level of care. To attack the problem of data synchronization... don't go there (just use Parse)
That sounds good, but it glosses over the differences in languages, idioms, toolchain, development methodology, testing methodology, etc.
While you need your designers to understand both well enough to create a common design, you are going to find very few coders who are true experts at both Web and native architecture and implementation. While you can cross train people, you need experts in both.
It really depends. A big company can afford to have specialised Android devs etc, while a startup might want to shift "the mobile developer" between OSs and maybe the web too.
Another way to look at this question is to ask under what circumstances would you expect a developer on X platform to shift to Y platform.
IMO it takes 2-3 months at least for a good developer to become professional-level in another language. And in an app context, it's not just a language, but a large set of libraries and frameworks.
So you can assume a 4-6-month ramp-up in skills, with relatively low productivity, and then work backwards to decide if the investment is worthwhile. If the developer has sufficient domain and institutional knowledge, and is likely to stick around, it might be.
We're currently making a HTML5 web app that works in Chrome and iOS Safari.
It's an audio app (SpeakerBlast) where you sync the same audio across devices; used to amplify audio amongst friends or throughout your IP devices for gatherings, flash mobs & playing audio throughout your home!
We feel it's easier for to tell your friends to go to this link to join in then, "Hey download this app so we can all play audio in sync."
No doubt that the current market says native apps, but this will change within two to three years. Web technologies are catching up in regards to what can be achieved via Android (specifically Chrome) and Apple mobile web browsers.
Yes, you can do some pretty cool cross-browser stuff even today.
"Web technologies are catching up in regards to what can be achieved via Android (specifically Chrome) and Apple mobile web browsers."
This is assuming native platforms stand still, and they aren't; the web's caught in their cross-fire.
Whenever you think something is "done", it's rarely the case. (I know you didn't say that, but it's a related argument people sometimes use in favour of the web.) iOS and Android in a few years could be dealing with home automation, cars, wearables, etc., and while some developers today might say "oh but we just do mobile", in the future that might be like saying "oh we just do 7" tablets".
The "catching up argument also assumes web standards are converging, and in the past two years, the increased pace of innovation has made some web technologies diverge. Such as the offline technologies I mentioned in the linked article.
It's not entirely true that native apps can't deal with URLs. On Android, they can handle them well with intents and on iOS, they can at least open URLs of a certain protocol.
The main issue is that the receiving user probably doesn't have the actually app. That's the benefit of web presence from a sharing/virality perspective.
I wrote this HN mobile client in less than 3 weekends. it works on Android, iOS and wp8. Also works on all desktop browsers. It took less than 2 weekends, but new chrome on android is a big pain in the ass. Had to rewrite part of it to make it work on latest android chrome.
I used it in my desktop (mac chrome) browser, and it's a better UI than the HN website itself - much less pain from context switching. The biggest issue for me is that it's really hard to read text - mainly because there's too much on the page, and the formatting makes it all unremarkable. Even the comment indentation is unremarkable, and easy to miss.
Improve readability and make comments easier to access (perhaps inline them after the article text), and you've created something amazing.
It all depends on what kind of app you're building.
Lots of people are telling me most apps are crap and they say they use no more than 5 - 10 apps : Mail, Maps, Messages, Camera, Twitter, Music and the browser.
If you're building a podcast app, then you should absolutely build a native app.
For me, the big gap between native and web is in UI. Performance is a solvable issue with either Javascript-native bridges or just devices getting faster. Even ignoring the Android/iOS "look", I've yet to come across an HTML5-based framework that can be used to build a complicated user interface with the same usability as native development. Cordova's great for what it is, but it's still a tool designed to wrap web app in a thin native shell, not a framework designed from the ground up to create a strong mobile UI/UX
The web is very good for some things - its primary role is that of a giant online encyplopedia that is constantly updated and transformed. It enables digital collaboration.
This is in fact very close to Vannevar Bush's idea of the memex.
But we are trying too hard to make it good at something that we already have a good solution for. People forget how much software runs natively, from medical devices, to airplane and missile control, to celestial navigation and radio astronomy.
Theres no good reason to webify many of these areas. Ultimately its not the web vs native. The web is a way for me to write better native software, through the practice of digital collaboration. It makes possible a new way of thinking.
However the web is a great way to start/test user response to a product. For start-ups with minimal resources and wanting to build the way they know how (using web technologies), there are now great integrations with 'native' mobile features, like the camera and music controls.
For a great example, check out the web version of the article's featured app http://player.FM
Yes, absolutely. The article's main purpose is to make the native argument, but there are still many benefits of the web approach, and fast iteration is one of them.
And not just because of the store submission process (which only takes a few hours in Android's case anyway). HTML5 has such a rich set of resources, as well as great desktop browser environments, that it can be a super-fast way to get projects going. Thanks to Backbone, Angular, etc, and in the future Web Components, it's easier to scale the architecture too.
Notice all of these benefits are centered around developer experience. User experience is the biggest gap right now.
You know, I am also a "web developer turned into native" and what you say is very very strange.
By using native components provided by SDK you can run circles around any webtech based approach. Yes deployment can be significantly delayed in some cases, but for prototyping id does not matter.
Alas, "if the only tool you have is a hammer" folks keep searching for the reasons why web tech is better for apps. Sorry guys, it is not. It was created for the different purpose, how hard is that to get?
Yes you can make a point if cross platform is concerned, but in reality doing cross platform is neither simple nor easy.
And if you think that HTML5 has a rich set of resources, check out that SDK offer.
>You know, I am also a "web developer turned into native" and what you say is very very strange. By using native components provided by SDK you can run circles around any webtech based approach.
That's my experience too. Things are faster to prototype in a web application only if the UI isn't very rich.
> Notice all of these benefits are centered around developer experience. User experience is the biggest gap right now.
From all the benefits of web technologies, "developer experience" is the worst one.
Developing (good) UIs using web technologies is an exercise in masochism. It's forever piling hacks and finding new frameworks to bend a browser to do what you need (a broken model). Then, worry about cross-compatibility.
Someone proficient in XCode is likely ten times more efficient and produces a more polished result with much less pain.
Exactly. Most likely those pushing for "web tech everywhere" did not bother to check out that native platforms offer.
On the other hand those doing native apps what do little more than display html in embedded webviews are not helping either.
So embrace and extends tactics of closed platforms attracts people not willing to wait for the standard process to work its way to the same results, slowing it down in the process and jeopardizing the future of the open web?
The web has been around for over two decades. In less than two decades since the Altair 8800, we were programming on NeXTSTEP / OpenStep, Mac OS, and Window 95. There is no current IDE for the web or web standard that can do what we did in 1995 much less 2013. That's why developers are using iOS / Android native apps. Open doesn't matter if I cannot ship what I want and get the user experience I want. It is actually easier to hit all the mobile platforms than do a web app of equivalent functionality. Add to that all the capabilities native apps have over web apps (hey look, sensors) and you get the desire. This doesn't even count the assurances graphic designers have going native.
Perhaps, it really is time to look at something past the web for app development and let the [edit] web [edit] go back to displaying documents.
One should be able to compile a web app into a downloadable package, with capabilities to run the app completely offline. Until that web will always be second best to fully native. Performance is getting close enough though.
Cordova works excellently for adding offline use to web apps, until the day that such features are successfully baked into web standards and operating systems.
"The ultimate purpose of PhoneGap is to cease to exist."
I'm a fan of the statement made at the end of this article .. which to me boils down to that
A mobile web presence is very important and shouldn't be ignored but if you're going to distribute something as a native app it's silly to build it entirely in a WebView
also it's wise to never forget that technology changes so fast neither of these current platforms will be the same in 2-3 years .. so really just pick something and go
It seems strange to me that so many young developers don't seem to comprehend why that is a big advantage.
I want to code in CoffeeScript and use nice simple APIs.
I'm sorry but Objective-C is outdated and overly complex. The only reason people accept and even learn to love it is because if you are an Apple person you have to. You have no choice in the matter. Its like people in North Korea have to love their Dear Father Leader or something.
I'm sure the Android Java libraries are much better than before, but they are still based on what I consider to be a dated type of development. The framework APIs are inferior and constantly specifying types is unnecessary.
To me CoffeeScript with Node.js modules are the state of the art in terms of language design, dependency management, and API design.