Has the Native Vs. HTML5 Mobile Debate Changed? 161
itwbennett writes: The tools available to developers who need to build an application once and deploy everywhere have exploded. Frameworks like famo.us, Ionic, PhoneGap, Sencha Touch, Appcelerator, Xamarin, and others are reducing the grunt work and improving the overall quality of web based mobile applications dramatically. The benefits of a build once, deploy everywhere platform are pretty obvious, but are they enough to make up for the hits to user experience?
Least common denominator (Score:5, Insightful)
Re:Least common denominator (Score:5, Informative)
Re:Least common denominator (Score:4, Informative)
That's assuming you don't care about giving your users a good UI experience, because if you don't, your competitors just might. You can always financially justify cutting corners if you're not considering longer-term ramifications.
I'm not saying building native apps is the right decision for all apps, but it certainly is the right decision for *some*.
Re: (Score:1)
I don't know about you, but I visit many more websites than I install apps. By a large margin.This trend is prevalent among even the most app crazy smartphone owners. Nobody is saying there's not a place for Apps and desktop applications. Just that, perhaps, those should not be the de facto standard.
Re:Least common denominator (Score:4, Insightful)
http://phonegap.com/app/ [phonegap.com]
Re: (Score:2)
Unless you are ok with that app not working at times.
Web based is 105% crap when connectivity is flakey.
If you are making "free" apps, go for it, but if you are charging a customer $29.95 for the app, it had damn well better be a native app that works even with all radios turned off.
And I have a couple of $29.95 apps. Hell I have one for room audio tuning that was $59.95
Re: (Score:2)
The article isn't talking about webapps, nor is it talking about apps that require a server. It's focused on hybrid native-app platforms that leverage the use of a WebView for UI. The pages that the WebView displays don't have to come from a server over a network.
Re: (Score:2)
Connectivity is huge, but it's only one of the ingredients in making this decision.
If you want the app to work for them outside of the corporate WiFi, you have to host it on the public internet, where all attackers are equally welcome without regard to skillz or skripts. Are you sure that server is secure? What about tomorrow? Are you patching it? Are your users securing their devices properly? Uh oh, it's the new version of Heartbleed, go back three spaces.
You also have to consider performance. Is th
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Except most app developers want to target as many users across as many devices as possible so it makes more sense to use tools that target the most "common denominator". It makes very little financial sense to spend months on a native app that runs on handful of devices rather than most device using a tool like PhoneGap.
Targeting two mobile OSes gets you almost all users. And only one of those OSes has users willing to pay for your apps. Users of that OS tend to expect apps which work well, and that means using the latest and greatest APIs the platform supports. A framework prevents you from using them. Name one app written using a cross-platform framework that normal people willingly choose over a native alternative.
This is not a new phenomenon. Java allowed developers to write programs with GUIs that ran on six diff
Re: (Score:2)
Yup. Mod parent up.
Re: (Score:2)
Re: (Score:2)
Java allowed developers to write programs with GUIs that ran on six different OSes. It has been almost two decades since this worked well, and I have yet to encounter a single Java program with a GUI that I want to use. In every case, a native application for the platform I am using is significantly better.
Many developers (including myself) would consider Jetbrains' IDEs to be some of the best development tools available today. They are written in java.
Just because you've encountered a lot of garbage, doesn't mean that it's all garbage.
Re: (Score:2)
I think you really have no idea which apps are actually written in a crossplatform framework and which are really 'native'.. Most crossplatform frameworks ARE native, and most mobile platforms do have the same kind of options..
To be honest, why would I need a native app if there is also a webbased version available, and in a lot of cases I think the mobile versions (of native apps of websites themselves) are crap compared to regular versions.. (Most apps are nothing more than a dataviewer)..
But I agree, I'd
Re: (Score:2)
Except the net result is a sea of shitty fucktacular 'apps' that do the bare minimum, with no flexibility, security, or dependability, as storage and availability depend on connectivity and continued vendor interest.
Re: (Score:3, Interesting)
If only it were that easy. The problems with cross-platform development are myriad. The LCD experience has already been outlined, so here are the others:
1) It's write once, TEST everywhere, and you can't debug the code you actually wrote -- only the specific translation of that code into native code. And that sucks beyond words. It can be incredibly time consuming to the point where it easily erases any time you saved in development. And the longer the lifecycle, the more of your budget this is going t
Re: (Score:2)
Common Goals (Score:2)
Except most app developers want to target as many users across as many devices as possible
Say, isn't that what Malware and Spyware authors want too?
It makes very little financial sense to spend months on a native app that runs on handful of devices
"Handful" = > 500 million... that's just for iOS. Android has more.
I'd say 500 million potential customers warrants SOME degree of effort.
Also if it's so easy for me to build out something mediocre in PhoneGap that works for everyone, doesn't that mean the ine
Re: (Score:2)
Unless your app is MUCH MUCH cheaper than the other one, I'll choose the one with the better UI, which almost always would mean the native UI one.
Re:Least common denominator (Score:5, Interesting)
Dunno... I've seen where a well-built common UI framework (Qt specifically) can make cross-platform not only easier, but improves the UI beyond the OS it rides on, and more importantly, provides a consistent user experience for those who do switch between platforms.
A perfect example of this is in desktop CG applications (...like this one, ferinstance. [daz3d.com]) In this case, there are no real OS-specific strengths that your UI would even need to care about. In the case of cross-platform CG apps, a professional artist can use the Mac version at work, the Windows version at home, and not have to care about interrupting his workflow because of UI inconsistency.
Now on the mobile side, this becomes even more important I suspect, with a not-insignificant number of folks swapping between platforms every year or two... your app remaining consistent between them is kind of important at that stage. For anything cute/unique that you want to add or remove for a specific platform, I suspect that case statements (or equivalent) would take care of that, no? It would at least allow you to keep it all in one codebase if nothing else. You just have to know what you're doing when you build it, and be sure that the underlying language is equally cross-platform (in the above example, C++ is the weapon of choice).
Besides, the only way you really would be able to commit to tight hardware integration would be the case of iPhones - it'd be the only platform where you could expect a consistent and relatively limited variety of hardware specs and features across all users - a condition you'd never see with Android, WP, or even (heh) Blackberries.
Re: (Score:2)
Disagree with your comments on CG UI.
I used Lightwave 3D for quite a while. It's built with one of these cross-platform Frankenstein UIs, and frankly, that part sucks.
I want an app to behave on a Mac like a Mac app, on a Windows PC like a Windows app, and on a Linux box with whatever feeble attempt at consistency it can muster.
Ditto goes for iOS and Android. Can't stand seeing the iOS "BACK" button on an Android screen. Dumb, dumb, dumb.
Re: (Score:2)
First, Lightwave is indeed the suck UI-wise, but the blame lies squarely with the dev team's choices and design. Remember that they're likely still using something from back in 2000 or so. Count your lucky stars though; at least you've never had to work with a Kai Krause production (e.g. Poser, Bryce, Carrara)... I still wake up with night sweats at the very thought of having to untangle the UI mess that Bryce was built with.
Secondly, the whole back-button-on-Android thing is standard UI housekeeping; conce
Re: (Score:2)
QT addresses write once, build for everywhere. But a big part of the issue here is write once, deploy everywhere - which is a whole other animal. App stores make deployment - and upgrades - pretty easy, but once your app has any kind of complex database behind it, you need the kind of synchronized update everywhere that's a logistical nightmare. Like it or not, web apps rule for deployment - and deployment rules.
I've long advocated for a 'smart terminal' approach, where the 'app' is just a GUI with a set
Re: (Score:2)
I've long advocated for a 'smart terminal' approach, where the 'app' is just a GUI with a set of capabilities, and all the smarts are up on the server.
As a user, what you're advocating is something I consider a dystopian nightmare.
As a developer, I totally see the appeal.
Re: (Score:3)
"I've long advocated for a 'smart terminal' approach, where the 'app' is just a GUI with a set of capabilities, and all the smarts are up on the server."
This is just for toys though. Uh-oh, I'm in a bridge. That app isn't real, fuck that app. Uh-oh, I don't have a good net connection. Oh, look, others are streaming at this hotel, so while I have bandwidth my latency is trash. Now this app is trash because it doesn't respond to clicks. Uh-oh, the devs decided to shit the app up with adds. Uh-oh, the s
Re: (Score:2)
Now on the mobile side, this becomes even more important I suspect, with a not-insignificant number of folks swapping between platforms every year or two...
who are all these platform switchers? People who want iphones get iphones, people who want androids get androids. Perhaps somebody makes a switch at some point, I seriously doubt they ever go back. I think you're overstating the churn. I used an android phone for a couple years, and since then I've been using the iphone. I have no plans on switching.
Re: (Score:2)
Dunno... I've seen where a well-built common UI framework (Qt specifically) can make cross-platform not only easier, but improves the UI beyond the OS it rides o
Than you don't really know much about UI development.
Qt is about as horrible as you can get in every aspect. Its not native, which sucks in every way. Its not UI native, its not UX native, its not native to devs of a particular platform, its pretty much different in everyway, none of which are particularly better other than being cross platform. If you think Qt has abstracted everything away from your for cross platform dev then you really aren't doing all that much with your apps. That doesn't mean you
Re: (Score:1)
Re: Least common denominator (Score:1)
That's just BS that only someone without any experience in anything HTML/js/css can claim. Would you say that most websites are crap (granted, this one is)? I let you in in a secret: they are allmost entirely built of HTML/css/js.
I let you in on another secret. Even so called native apps revert to webviews to display easily customizable UIs because the native toolboxes are just so limitted in what they offer out of the box, and it has become far easier to build new widgets in js/html, and less expensive to
It depends ... (Score:2)
If you're trying to take on an 'A' player like Google, Facebook, Twitter, etc, or trying to establish a new service, yes
Device's camera (Score:2)
If you're Home Depot, no ... while it's important, those few milliseconds of lag and somewhat less native UI isn't a primary business concern.
Low latency integration with the device's camera is a primary business concern when you're trying to let the user visualize how a particular home improvement product will look next to other things in the room.
Re: (Score:2)
Facebook's app went native years ago. Precisely because performance for the webview version was unbearable. Me? I'm not an FB user. I am just going by what the FB devs themselves say.
Just go native (Score:1)
We use Xamarin and our advice is don't use Xamarin. Too many bugs, garbage collection sucks. I love the idea of Xamarin but wish we'd gone native.
why not a web page? (Score:5, Insightful)
So if you need a framework so you can pretend to have a native version of the application ... why not just focus on having a webpage instead of a shitty application which is just a web page?
This sounds like lazy people who want to claim they have an app, when all they're doing is pointing to a web page.
I can view your damned web page on my own.
Honestly, this is why I've started getting away from apps ... because as often as not they're badly written, and contain a fraction of the information I can get from the website, but still insist on having access to my contact list and messages.
Most people writing apps care more about invading my privacy and selling ads than actually providing me anything useful.
Re: (Score:2)
...why not just focus on having a webpage instead of a shitty application which is just a web page?...
Because it is more difficult for a webpage to harvest a user's personal information. That harvesting is done much more easily within an app that has direct access to said data.
Re: (Score:2)
if you're a data vacuum, what great about a website is you can track where else your customers go. So you go to amazon.com, and it can tell from various cookie networks that you also like going to furrydice.org, so amazon.com will show you a wide selection of furry dice. in an app this isn't possible because apps are sandbox and have very limited visibility into happenings outside the app.
On the other hand, apps are great for attention span, to force the user to pay attention and finish the transaction rath
Re: (Score:2)
IMEI. Definitively identify a device, without even requiring an account sign-up. There's a bunch more.
Re: (Score:2)
Re:why not a web page? (Score:4, Interesting)
It's important to understand that the context of use for a mobile web page is different from that of a successful mobile app.
There are a bunch of dumb apps developed for online news sites - as though I'd ever want to go to just one news site, vs. have the mobile web spread out before me.
OTOH, good mobile apps do things that the mobile web doesn't or can't. Perform read/write operations on local data. Use local processing power - as much as is available. Access local sensors not available to mobile web. Aggregate data from multiple sources - perhaps blending web and local data.
Even apps that do nothing more than provide deep search - if the vertical market for the app is well defined (Movie geeks: IMDB, small investors: finance apps...), it's possible for a mobile app to excel over a web site by providing native gadgets and a platform native UI that doesn't have to leave room for the (admittedly minimal) mobile browser UI.
Finally, mobile apps can scrape a bunch more information from the user's device than can mobile web. Definitely a help in monetizing a popular vertical, if you roll that way.
Re: (Score:2)
No, you need a framework so you don't need to reinvent the wheel for every project you work on. With Sencha's frameworks, I can write a pretty slick-looking responsive site in a few hours (or days, for something larger) that would take literally months to roll on my own (and for the record, yes, I can and have rolled my own, back in the dark ages).
why not just focus on having a webpage instead of a shitty applica
Re: (Score:2)
Sure, I won't have access to Bluetooth or the device's sensors, but most LoB software doesn't need that
And if you did, Phonegap gives it to you basically for free. Even if there's some bleeding edge API you absolutely must have that they don't support, writing wrappers is fairly trivial (just a Java or ObjC file with no business logic that says, "Expose this API call as this JS call" a few times, basically).
Depends. (Score:3)
Some stuff still need to be an a native application. Camera, music player, email, chat, maps/GPS navigation, calendar. Most 3D games also benefit from being native.
Re: (Score:1)
Notifications are available in Chrome.
Re: (Score:2)
Re: (Score:2)
Facebook transitioned to a native app on iOS years ago due to performance limitations with their web-app.
Re: (Score:2)
Re: (Score:2)
Yes, Please!!! (Score:5, Interesting)
For 99% of the applications out there, there's no reason not to do it in the browser if you're starting from scratch today. Most (useful) mobile apps simply display remote content in a way that's contextually relevant to the moment (Yelp, shopping (ordering and product reviews), *Maps, news sites, social media, etc). There's no reason for any of those to be app based. Most apps that aggregate content are poorly designed and not updated frequently. Couple that with the fact that most do not have useful offline modes (the only reason to have an app for content, IMHO), it just makes sense to optimize for the mobile browser rather than spend all the time and effort on an app. Hell, even most games I play casually have no reason being written as apps any more - any word game or puzzler would work fine in the browser.
Instead, put the effort into good mobile design and development practices. Hire good developers to optimize for JavaScript. Hire good developers to optimize your backend operations to reduce latency. Find what features are missing in HTML/JavaScript (e.g., a good client side persistence layer) and encourage the browser vendors to improve there so everyone can benefit.
For context, I develop complex scientific software. We use the browser (desktop) as our client and push the limits of what you can do there. Mobile is not far behind and should be the first choice for new development.
-Chris
Re: (Score:2)
One major reason - if the browser fails, it takes out everything running under it. Failure can be as simple as a crash, to a javascript exploit that interferes with the browser, or the browser needing a few minutes just to crunch memory bloat.
Although browsers have since gotten better, I still don't trust the browser to resume where I last left off - the best I can do is force firefox t
Re: (Score:1)
I agree with you in principle, but in practice it's hard to argue against the values that are at least currently uniquely provided by apps:
1) The icon is sitting on the user's home screen (or, to a lesser extent on another screen or in folder) when she unlocks her device. Sure you can create a bookmark of a webpage and put it on the desktop, but I'll bet the frequency of that behavior is miniscule.
2) Notifications are becoming very powerful means of interaction and some believe they'll radically change the
Re: (Score:2)
You want it funky dirty native:
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
That's the problem with web development. People are always pushing the limits of browsers. Nobody used to talk about "pushing the limits of the Windows API" back when I used to write desktop apps in Delphi, because it hardly limited you.
At some point our industry has to get past this collective web fetish. The browser was never intended to run apps. Trying to use it a
Re: (Score:2)
I've been doing mobile development for the last fifteen years, and my experience with PhoneGap about three years ago was the most ridiculous and painful experience of my career.
Developing with HTML and JavaScript is a pointless chore. It is literally easier to learn both iOS and Android programming and write the same app twice than to put up with and hack around the stupid limitations of hosted web apps. You lose nothing but the ability to write once and debug everywhere shared code, and you gain native per
Re: (Score:2)
1) Mobile CPU/GPU is still 50X slower than desktop (i.e. your CSS transitions are 50X slower...hardware acceleration included).
2) Mobile RAM allowance is still 10X lower than desktop (i.e. less resources loaded, prefetching, more thrashing, less JITed code, less unboxing, etc...).
3) No native look and feel, so everything seems out of place.
4) Still takes 3 years to get anything through the JS committee, and god knows how long before browser adoption.
5) Users still can feel latency even if backen
Re: (Score:2)
Maybe they hope the app will work better offline ?
Source code availability? (Score:2)
When I last checked a few years ago, one of the cons of using any of the HTML based app development systems was that effectively you bundle the complete source code of your app inside your app.
Has this changed in recent years?
Re: (Score:1)
Re: (Score:2)
So? How is that a con? O yeah , people still think in terms of providing a product instead of a service,.
It's cute that you think that everything can be a service. Which must be predicated on a belief that you can always access the internet.
Re: (Score:2)
Not much of a debate... (Score:2)
Honestly, right now, native applications are by far the superior choice. Web apps sound like a great idea, but they're hindered by being incredibly slow (and phones are already not very powerful to begin with), they have far fewer features, and they often look hideous and out of context compared to the other applications on the system. Furthermore, web applications have no legacy - I can always guarantee that app version so-and-so will work on Android version such-and-such, but the same can't be said for a
Re: (Score:2)
It's not 2008 anymore. Get with the times.
Let's take FireFoxOS as an example. I have a ZTE Open, the lowest of the low-end, running FXOS 1.2 -- an older, slower, version of the OS. The only advantage is its excellent support for web standards.
There are some awful examples of HTML5 apps on the platform, notably the popular solitaire game offered through the marketplace. There are also exceptional apps, that you'd think were native if they were running on any other platform, such as fast-paced 3d games and
Re: (Score:2)
Re: (Score:2)
Learn a bit more about the topic and you'll understand.
Re: (Score:2)
Re: (Score:2)
Yes, I'm a terrible person. Of course, my apps don't have serious performance issues. Deal with the devil and all that.
We're closer (Score:2)
Conflict of Interest (Score:2)
Fairly Native on 1 platform, ported on the other (Score:2)
If you'd like to use your native language skills ( E.g. Java from Android ) on alternate platform ( e.g. IOS ), frameworks can be useful. I like open-sourced CodeNameOne [codenameone.com] and RoboVM [robovm.com] because I work on the Java side of things and my needs on alternate platforms are fairly basic. An IOS developer may easily go in the other direction.
Obligatory (Score:5, Funny)
If you are Target and I just want to see what you have available in your store, then no, you don't need an app. [xkcd.com]
If you farm out to lazy app developers that simply ask for every permission on the phone, then no, you don't need an app. [xkcd.com]
And if you make a phone-specific version of your site, it will almost always end up crippled. [xkcd.com]
Yes - Facebook quit too soon (Score:3)
Facebook gave up too early. On the other hand, Facebook can afford the development cost of native. For many other applications, native is unaffordable, especially for multiple platforms.
(Thank you, though, Facebook, for (before giving up on hybrid) figuring-out how to shut off the *&^%$#! iOS WebView "accessory view", and using your Facebook-powers to cow Apple into looking the other way when apps go digging into the virtual keyboard windows to shut that evil thing off...)
Embedded WebViews have gotten much better. Android has been the laggard, with awful animation/transition performance and glitchiness prior to 4.x, and user reluctance to upgrade OS (improved now) and inability to upgrade on many devices (alas, not much improved, so many Android devices cannot be upgraded to latest OS.)
Certainly, on iOS at least, I think most users would be hard-pressed to tell the difference between well-written hybrid apps and native.
I use (Zebra, was Motorola, and before that RhoMobile) Rhodes. I've also developed using PhoneGap/Cordova. I would not do a large project in PhoneGap/Cordova, because everything has to be done in Javascript. With Rhodes, I write models and controllers in Ruby, views in ERB (wish it had a better template language...) and code that touches the UI directly in Javascript. It's a very comfortable platform if you have been a Rails developer, because it's very similar - the server has been placed in the application.
I'd say at least half my development time is spent with JS and CSS (actually, I use SCSS). I see that as a good thing. I can tweak the UI interactively by twiddling CSS in Safari or Chrome desktop (developer tools for both can connect remotely to a device for inspection/debug/experiment.) I can easily teach a designer to do that themselves. Contrast that to the painful process of tweaking a native UI, being forced to use platform-unique tools and go through a slow and painful build process to see the smallest result.
I've been working with a small team implementing a number of similar energy-conservation apps (they are used by professional energy auditors - organizations are opinionated, that's why there are 6 apps...). I really think the effort would have been insurmountable had it been done with native code. This is not a typical consumer app with a few screens, but ones with dozens of pages of data-collection forms (per audited building). It's not your typical consumer app with some kind of silly one-page dashboard with text in circles...
If I had to do something with charts/graphs, I certainly would leverage the great JS libraries that are available, rather than struggling with native code! We did do a little sketch tool in JS (sketch over photos for annotation - just browser API) and nobody would ever know it is not native.
Ultimately, we abandoned Android (at least for now) due to poor performance and Balkanization, but I can see Android being supported in the future again.
I have not used Xamarin. It seems the worst of all worlds to me. You have to use the native API of each platform, but you write in a common language (C# yuck!). Where is the saving in development time here?
I strongly disagree with the bit about "different screen sizes" etc. being problematical. Using HTML helps solve that problem. It's easy to create flexible layouts using responsive CSS. Yes, native platforms have gotten better about this. But it's impossible to get designers directly involved, using the tools that they are familiar with. They still have to toss wire-frames "over the cubical wall" and the battle it out with programmers as to whether their fantasy UIs are even possible. With HTML5, they can work with what they are familiar with and provide complete solutions for UI bits. As well, there is an amazing volume of free and really quite high-quality resources for CSS3 effects, etc. that can be leveraged.
Yea, if you have a million-dollar budget for a small app, go for native. The rest o
Native is fine for forms/charts (Score:2)
There are a number of native libraries devoted to quickly defining and presenting working forms in iOS.
For charts, there are a number of really excellent solutions that cost money, but not much and they deliver really nice, dynamic graphs with many options.
If I were doing a heavy enterprise form app I'd still go native.
Re: Yes - Facebook quit too soon (Score:2)
C# has actually evolved into a wonderful language. The async stuff, lambdas and especially Linq are great.
Xamarin-wise, there is a lot of code sharing possible using portable class libraries, and Xamarin.Forms shows promise, if immature. The project in working on has probably 95% shared code and appears completely native.
What about RadStudio? (Score:2)
http://www.embarcadero.com/products/rad-studio
J-F
What's native? (Score:2)
I use Firefox OS, you insensitive clod. :)
I was never a huge app user on Android anyway. Games and fart apps, yeah nah. If the latest online service that syncs to the cloud and data-mines my personal details wants my business, let them write a mobile web page!
The lack of native apps like Skype is the main thing I might miss on my next trip, calling family via hostel wifi. But hopefully I can get my relatives to adopt firefox hello! :) I've been wondering about one of those smart fitness wristbands such as M
I have hopes with FirefoxOS (Score:2)
FirefoxOS is basically a web browser with JS APIs to access the hardware.
All apps use web-based technologies, which means that the only thing needed for any OS to use FirefoxOS apps is a web browser that support these APIs, no need for native code unless you really need performance. You can already run some apps on Android as using Firefox components.
I really hope that the guys at Mozilla focus on the compatibility aspect by making it easy for developers to use the FirefoxOS framework on other platforms (An
Re: No (Score:3, Insightful)
More specifically, HTML5/JS/CSS still give really shitty developer and user experiences compared to native apps. That has always been the case, and still remains true. That is why the debate has not changed.
Re: No (Score:2)
And most phones have all the horsepower and HTML engine quality to pull off a lot of the sorts of user experiences you'd like (there are still rough spots though).
The device APIs in HTML5 now cover almost all the native capabilities you would want, once ServiceWorker and push notifications are fully deployed. They actually do a -better-
Re: (Score:2)
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
Well, that's clearly a matter of opinion. I have done the same, and in my opinion, nothing beats going native (assuming you are trying to achieve the same end results, which is difficult-to-impossible, considering how limiting web apps are.)
Whenever this discussion comes up, I feel like Slashdot is just filled with old crufty C++ coders who don't understand the state of the modern web
Why would you think this? Couldn't it equally be that Slashdot is filled with experienced engineers who find it instinctively painful to write applications in a way that provides a substandard user experience compared to the other options available?
and has no vendor lock in or censorship issues like the mobile walled gardens have.
That's a separate issu
Re: No (Score:1)
Re: (Score:2)
Now, come on, there's no need to start getting nasty here.
The two main things that are limiting are that you can't take advantage of the unique strengths of the particular device you're running on, and the performance always (and inevitably) suffers.
Whether those limitations are important depends entirely on the type of app you're writing, although I maintain that maximizing performance is always important on mobile platforms in order to maximize battery life. That said, I am completely aware that the rest
Re: (Score:2)
Then I have no idea what you mean by "be specific". I was plenty specific enough for this discussion. I doubt that you actually want me to dive into the technical details.
I will add a clarification about my comment about performance. If by "performance" you mean "speed", then you are (as I already said) correct that what is good depends entirely on what the app does. However, performance means a lot more than speed. It also means things like CPU cycles: an app with good performance is an app that uses the l
Re: (Score:2)
I think part of the problem is that web app developers seem to fall into one of two camps: Do everything locally for the best chance of avai
Re: (Score:2)
So many comments here miss the mark so widely. There is NO implication that a hybrid (or, more broadly cross-platform) native app has to rely on a server. None, zero, zip, zilch, nada. None.
You DO NOT NEED a server for native hybrid app! Only if you happen to need a centralized database. Use a server if you need a server. Period. For example, you have an app that shows current news, current sales figures, that updates the company database in some way? You are going to have one or more servers involved.
If yo
Re: (Score:2)
Re: No (Score:1)
Wow, that's really fantastic! We can build late 1990s era games with this web technology. That's totally cutting edge and innovative. It will only be another 15 years before we can use web apps to create shitty demos of today's software. I can't wait!
Re: (Score:3)
Are web apps as amazing as native apps? No. And i doubt they ever will be. However, the time it takes to develop a native app vs a web-comparable app is immensely different. Web apps are infinitely easier to create and deploy. The question is if it's worth spending 2-5x the amount of money/effort to provide that level of immersion. To many it's not. Especially if your user base is small.
I work for a Fortune 500 company and we have internal web apps that serve anywhere from 10 - 10K people. There is little j
Re: (Score:3)
However, the time it takes to develop a native app vs a web-comparable app is immensely different. Web apps are infinitely easier to create and deploy.
Only if the "app" consists of a pull-down menu, a fill-in form and a database. Now try to do a 3D FPS game app, using OpenGL, with HTML5. Is it theoretically possible? Sure. But it will be incredibly difficult to manage polygons, scenes, frame buffers, etc. in a language where an integer is a float, and a float is sometimes a string, where the only data structures are arrays and hashes, and errors are almost never caught by the compiler.
I have written apps in both native code and Html5+Javascript. Html
Re: (Score:2)
You can at least quit worrying about your numeric types if you use asm.js
Re: (Score:2)
Try coffeescript.
Re: (Score:2)
Honestly I'm not sure I buy an order of magnitude.
That said if user experience is secondary (internal tools for instance) a quick and dirty web app might manage that order of magnitude but once you want some sparkle, maybe some animations, the advantages dry up quickly. It always seems like the web devs can get the basic feature implemented faster but getting it refined and polished seems to take them more time than app developers and the results are not necessarily as good.
Re: (Score:2)
Yeah good point that sounds trivial, like using a RumplestiltskinJS quadrilateral framework that all the cool kids are running.
Re: (Score:1)
That is not "catching" up that is merely putting a raw graphics adapter canvas in a web browser.
That is not providing API hooks for various system level resources.
Re: (Score:2)
Turns out that's a reasonable expectation. http://arstechnica.com/gaming/... [arstechnica.com]
Re: (Score:2)
I would have read the rest of your comment, but you're obviously playing a terrible game of telephone. Every language is parsed. Java is a compiled (not interpreted) language.
Re: (Score:2)
Only if they're written by morons.
Of course, that's true regardless of the technology.
Re: (Score:1)
Re: (Score:2)
Swift does not have garbage collection. GC has been deprecated for Objective-C for years now. Why the hell would Apple implement it for Swift?
Re: (Score:2)
Re: (Score:2)
Unless you compile it to asm.js then Javascript will use Ahead Of Time compilation.