Hybrid sweet spot: Native navigation, web content(signalvnoise.com)
signalvnoise.com
Hybrid sweet spot: Native navigation, web content
https://signalvnoise.com/posts/3743-hybrid-sweet-spot-native-navigation-web-content
13 comments
I'm glad to see an organization as prominent as 37 Signals coming out in favor of the hybrid mobile development approach. Everything DHH mentions in this post is spot on as far as my experiences developing hybrid apps goes. I was on a project that was resource constrained but needed good mobile presence as well called kona.com that's in the same problem space as Basecamp. We tried both the full native and full HTML5 routes but neither option worked for us. We didn't have enough developers for our native apps to keep up with the web app and the HTML5 app (powered by Sencha) simply didn't perform well enough on phones back in 2012.
After scrapping both those attempts I suggested we go with a hybrid app. We would lean heavily on javascript (angular.js in our case) and rely on native for access to native APIs and for UI elements that required better performance like the Facebook style drawer, slide up animations, the top and bottom nav bars, etc. It was the right mix between developer efficiency and app performance and allowed us to target not only Android and iOS with 90% of the same codebase, but also a native desktop app as well using Chrome packaged apps. We had written the main web app in JavascriptMVC but when I left the project we were just starting to port over the angular app to the main site, so eventually the same angular app would be powering the website, desktop app, iOS app, and Android app.
It only took one developer (myself) to manage the native code on Android and iOS and the logic was very similar in both places so it ended up being pretty simple to maintain. And as DHH mentions, setting up communication between your native code and your web code is easier than you'd think, although I am interested in hearing more about how they did it.
At any rate, DHH is totally right about the fact that most apps would be suited just fine by hybrid mobile apps as most apps are data heavy like Basecamp. Don't tell that to native developers though because you will catch an earful about poor user experiences and maintenance hell, which in my experience is a bunch of FUD. The proof is in the numbers, and the Basecamp apps are well received (as were ours). The FUD around mobile apps and user experience reminds me of this post that showed up on HN last week: https://medium.com/design-founders/f59c964513ef, which examines the failure of the assumption that meticulous, cutting edge design will guarantee success. In my experience, if you can get close to native but you solve the user's actual problems (which is very rarely related to a lack of unique swipe gestures and translucent backgrounds) you are usually good to go. Why continue to deal with the pain and cost of having dedicated teams working on the exact same app for Android, iOS, Windows Phone, the Web, native desktop apps and god knows what else?
After scrapping both those attempts I suggested we go with a hybrid app. We would lean heavily on javascript (angular.js in our case) and rely on native for access to native APIs and for UI elements that required better performance like the Facebook style drawer, slide up animations, the top and bottom nav bars, etc. It was the right mix between developer efficiency and app performance and allowed us to target not only Android and iOS with 90% of the same codebase, but also a native desktop app as well using Chrome packaged apps. We had written the main web app in JavascriptMVC but when I left the project we were just starting to port over the angular app to the main site, so eventually the same angular app would be powering the website, desktop app, iOS app, and Android app.
It only took one developer (myself) to manage the native code on Android and iOS and the logic was very similar in both places so it ended up being pretty simple to maintain. And as DHH mentions, setting up communication between your native code and your web code is easier than you'd think, although I am interested in hearing more about how they did it.
At any rate, DHH is totally right about the fact that most apps would be suited just fine by hybrid mobile apps as most apps are data heavy like Basecamp. Don't tell that to native developers though because you will catch an earful about poor user experiences and maintenance hell, which in my experience is a bunch of FUD. The proof is in the numbers, and the Basecamp apps are well received (as were ours). The FUD around mobile apps and user experience reminds me of this post that showed up on HN last week: https://medium.com/design-founders/f59c964513ef, which examines the failure of the assumption that meticulous, cutting edge design will guarantee success. In my experience, if you can get close to native but you solve the user's actual problems (which is very rarely related to a lack of unique swipe gestures and translucent backgrounds) you are usually good to go. Why continue to deal with the pain and cost of having dedicated teams working on the exact same app for Android, iOS, Windows Phone, the Web, native desktop apps and god knows what else?
The user experience problem is a real one. But it doesn't mean it makes business sense for a small company to hire 2 iOS developers and 2 Android developers for native apps when the user base doesn't make heavy use of their mobile app (hybrid or not). I honestly don't care if I'm doing native development, backend, frontend, etc. But throughout the last 4 years I've used, analysed and worked in many different mobile apps, and the hybrid ones stick out, from speed issues to expected user patterns that aren't respected.
I tried the basecamp app on android and I'm to say that the UX is good is a stretch (for consuming the data is fine, but for inputing data is not).
I tried the basecamp app on android and I'm to say that the UX is good is a stretch (for consuming the data is fine, but for inputing data is not).
> The user experience problem is a real one.
Not in my experience. Without fail the only people I've ever heard complain about UX of hybrid apps are other developers who know which signs to look for. Most people won't notice or won't care to notice so long as the app does what it's supposed to do.
After all, I've been hearing developers complain about Craiglist's poor UX for years and it hasn't seemed to affect them.
Not in my experience. Without fail the only people I've ever heard complain about UX of hybrid apps are other developers who know which signs to look for. Most people won't notice or won't care to notice so long as the app does what it's supposed to do.
After all, I've been hearing developers complain about Craiglist's poor UX for years and it hasn't seemed to affect them.
> Most people won't notice or won't
Well, the proof is in the pudding. If what you're saying is true Basecamp's ratings would be a lot lower, wouldn't they?
Hybrid apps allow you to ignore user patterns and speed, but that doesn't mean it's guaranteed. Case in point: Instagram uses webviews extensively, and most people are none the wiser.
I work on an app that has made a similar tradeoff. I won't restate the positives because the post describes many of them (after all, we chose a similar architecture) but I'll add that fetching app logic+assets (in the form of JS/HTML) from a server also lets us iterate on the app more quickly and without requiring the user to approve an update. (Edit: oops, he actually did mention this in the post!) And we get to use all our HTML-based testing tools (like automated screenshotting) to catch regressions.
Our app is also different in that we precache all the HTML in the background so we can always load it from disk rather than the network, which helps avoid any loading delays.
Here are some of the negatives I've encountered. (My experience is solely with Android but I believe the basics are also true on iPhone.)
- There's a long tail of details that are hard to get right. E.g., handling multiple device DPIs, or getting navigation right (Android has a confusing mess of back vs up and tasks vs activities). This is all solvable (after all, that's why you've gone hybrid), but it ends up pushing more of your code native than you'd originally expect.
- There's a delay on all click events on a webview. This is probably worthy of a longer blog post but to summarize, there are at least two causes of this.
One is that by default click events happen 300ms after the touch event (I think due to it waiting for a double-tap?). You can work around this by handling touch events specially (and there are JS libraries that claim to do it) but in practice it doesn't work in all cases (e.g. some form controls can't be worked around) and we ran into bugs on obscure devices (e.g. our users report they can't focus a form control on certain Samsung devices; we even got one of those devices but couldn't reproduce the problem). Alternatively, the newer Chrome-based webview turns off this delay if your content's meta tags indicate it's not zoomable, but you can't really rely on this because the Chrome-based webview isn't widely deployed.
The other source of lag is that the "active" DOM state is also delayed, but by some other number and unrelated subsystem. This means when you tap a button it'll light up a bit after you tap it. In my brief survey I think other mobile apps work around this by not having a prelight state.
Sorry to be full of bad news. (Like I wrote above, I still think this architecture is the right tradeoff for my application's purposes.)
Our app is also different in that we precache all the HTML in the background so we can always load it from disk rather than the network, which helps avoid any loading delays.
Here are some of the negatives I've encountered. (My experience is solely with Android but I believe the basics are also true on iPhone.)
- There's a long tail of details that are hard to get right. E.g., handling multiple device DPIs, or getting navigation right (Android has a confusing mess of back vs up and tasks vs activities). This is all solvable (after all, that's why you've gone hybrid), but it ends up pushing more of your code native than you'd originally expect.
- There's a delay on all click events on a webview. This is probably worthy of a longer blog post but to summarize, there are at least two causes of this.
One is that by default click events happen 300ms after the touch event (I think due to it waiting for a double-tap?). You can work around this by handling touch events specially (and there are JS libraries that claim to do it) but in practice it doesn't work in all cases (e.g. some form controls can't be worked around) and we ran into bugs on obscure devices (e.g. our users report they can't focus a form control on certain Samsung devices; we even got one of those devices but couldn't reproduce the problem). Alternatively, the newer Chrome-based webview turns off this delay if your content's meta tags indicate it's not zoomable, but you can't really rely on this because the Chrome-based webview isn't widely deployed.
The other source of lag is that the "active" DOM state is also delayed, but by some other number and unrelated subsystem. This means when you tap a button it'll light up a bit after you tap it. In my brief survey I think other mobile apps work around this by not having a prelight state.
Sorry to be full of bad news. (Like I wrote above, I still think this architecture is the right tradeoff for my application's purposes.)
I agree with the "long tail of details". The big wins are championed while seemingly infinite little gotchas are glossed over. Native development appears to be linear and straightforward because there is one language and one API - "one thing" to reason about. Contrast that to all the context switching involved in a hybrid app. Portions are written in Obj-C, portions are dynamically built using data, portions are written in JS, CSS, HTML, and Rails. What about additional tools like SASS, jQuery, JS MVC of choice, etc, etc? A lot of moving parts can be hard to juggle, and slow development as app complexity/entropy sets in.
> Native development appears to be linear and straightforward because there is one language and one API - "one thing" to reason about.
No. There are X languages and X API's to reason about when doing native development, X being the device OS's you want to target. If you're only targeting iOS and nothing else, then I would agree with you. This is a point that's also glossed over by native app proponents.
No. There are X languages and X API's to reason about when doing native development, X being the device OS's you want to target. If you're only targeting iOS and nothing else, then I would agree with you. This is a point that's also glossed over by native app proponents.
> If you're only targeting iOS and nothing else, then I would agree with you.
That's becoming outdated. We've got a native iOS app and we're doing the Android port with Apportable, which provides native iOS APIs and features on Android. The dev version (which we're using) implements its own Core Animation subsystem on top of OpenGL ES 2.
It's not perfect, but it's a hell of a lot better than maintaing two separate codebases and it's far easier to fix whatever platform issues there are than the equivalent "long tail of details" you encounter working with web views.
That's becoming outdated. We've got a native iOS app and we're doing the Android port with Apportable, which provides native iOS APIs and features on Android. The dev version (which we're using) implements its own Core Animation subsystem on top of OpenGL ES 2.
It's not perfect, but it's a hell of a lot better than maintaing two separate codebases and it's far easier to fix whatever platform issues there are than the equivalent "long tail of details" you encounter working with web views.
Cool, so that covers iOS and Android (with its own long tail I'm sure). You still have Web and Windows mobile to worry about assuming that platform continues to gain popularity.
Only Microsoft is worrying about Windows Phone.
Apportable could be ported to run on Windows Phone, there just hasn't been any interest (or so I'm told).
Much of it could also run via NaCl as a Chrome Packaged App, including the UI stuff. That's a much bigger change though, since you'd be supporting mouse events, not touch. But it's still doable.
Much of it could also run via NaCl as a Chrome Packaged App, including the UI stuff. That's a much bigger change though, since you'd be supporting mouse events, not touch. But it's still doable.
Still takes longer for non trivial apps to get the it right on a large array of devices of X in Html than native. Especially using something like Xamarin I would gladly take up the challenge. Hybrid has it's place ofcourse; for more complex text markup embedded in apps.
The point is.You cant get a native feel with web techs,you'd have to use the official device SDK. Web techs are for webapps.
Native feel is a false prophet. "Fitness for use" is what you should aim for. The web didn't have a native Windows 95 feel. ExtJS tried hard to achieve interfaces that aped the "native feel" of Windows. Only hardcore interface designers that actually know what "native feel" is care about native feel, and even then they will only care about it so long as the current fashion trend is achieving a native feel. Once non-native feeling apps achieve "fitness for use" en masses, the "native feel is canon" will no longer be part of the app zeitgeist.
Except that you can get a native feel, as Basecamp has clearly demonstrated, if you utilize native SDK's where needed. Did you even read the article or try out their apps?
The reality is that tap events won't work correctly until you actively fix them, and almost all of them can be fixed (including ghost clicks). Fastclick.js does help here a bit, but it's not perfect. We did a ton of work on our end to have a comprehensive tap solution (though some of it is specific to Ionic projects), but could be useful for inspiration for your own project: https://github.com/driftyco/ionic/blob/master/js/utils/tap.j...
Thanks for the link. We also have an in-house solution like fastclick.
The hard part about this is tracking down the long tail of failures, particularly when they affect devices you don't have access to like the Samsung phones I mentioned above. It means we cannot make any changes to the code we already have without risking breaking some users who currently work (and rely on our app; as separate from the users for whom the app has never worked).
The hard part about this is tracking down the long tail of failures, particularly when they affect devices you don't have access to like the Samsung phones I mentioned above. It means we cannot make any changes to the code we already have without risking breaking some users who currently work (and rely on our app; as separate from the users for whom the app has never worked).
Yea, I agree. The situation is annoying, but with Chrome on 4.4 around the bend, I think it's only time before this is a legacy issue.
Just made my first "app" using Cordova, and the Ionic framework/CLI, https://github.com/driftyco/ionic-cli.
Was super simple and straight forward. Simple 7 page site with a breadcrumb nav and PDF/Video integration. Highly suggest cordova/phonegapp and Ionic if you're doing something simple in a WebView.
Was super simple and straight forward. Simple 7 page site with a breadcrumb nav and PDF/Video integration. Highly suggest cordova/phonegapp and Ionic if you're doing something simple in a WebView.
Thanks, glad you like Ionic :)
I personally think you can do 100% of the nav in the web. The problem is there legitimately weren't native-style navigation tools in web until recently.
Unfortunately, the standard linear history doesn't work for apps that run in a native container. You'll often be managing three or more concurrent navigation stacks (for a 3 tabbed app, for example), and the concept of a browser back button just doesn't make sense in an app like that.
So we've built a lot of that with Ionic. Perhaps at the expense of the mobile web browser app experience.
I personally think you can do 100% of the nav in the web. The problem is there legitimately weren't native-style navigation tools in web until recently.
Unfortunately, the standard linear history doesn't work for apps that run in a native container. You'll often be managing three or more concurrent navigation stacks (for a 3 tabbed app, for example), and the concept of a browser back button just doesn't make sense in an app like that.
So we've built a lot of that with Ionic. Perhaps at the expense of the mobile web browser app experience.
Don't get me wrong, I'm loving the experience so far and my "simple" comment refers to my skill level.
I did have a couple issues finding answers. Since you've commented, I'll post a couple here but I'll try to add them to the forum.
* Setting webviewbounce, UIWebViewBounce to false in the config.xml doesn't get respected by the framework. You have to manually add the attribute has-bouncing="false" to the ion-content tags to stop the bouncing.
* The helper ionic.Platform.fullScreen(); to hide the status bar initially flickers on first load of a fresh build. I'm currently trying to figure out how to hide the status bar on initial build. http://stackoverflow.com/questions/23553220/how-to-completel...
* I was a little confused using ui-view vs. ion-view. (I think)
Thanks for taking the time to comment!
I did have a couple issues finding answers. Since you've commented, I'll post a couple here but I'll try to add them to the forum.
* Setting webviewbounce, UIWebViewBounce to false in the config.xml doesn't get respected by the framework. You have to manually add the attribute has-bouncing="false" to the ion-content tags to stop the bouncing.
* The helper ionic.Platform.fullScreen(); to hide the status bar initially flickers on first load of a fresh build. I'm currently trying to figure out how to hide the status bar on initial build. http://stackoverflow.com/questions/23553220/how-to-completel...
* I was a little confused using ui-view vs. ion-view. (I think)
Thanks for taking the time to comment!
Hey thoughtpalette,
WebView bouncing is a vague term and I'm not exactly sure which you are referring to. If you're talking about the entire frame, it's now "DisallowOverscroll" in the Cordova config. If you use the ionic utility you'll get the correct config for a new project.
To hide the status bar, use the status bar plugin (org.apache.cordova.statusbar) and call StatusBar.hide(): https://github.com/jonathannaguin/org.apache.cordova.statusb...
The ui-view vs ion-view discussion: use ion-view. We basically have a custom ui-router implementation with multi-stack routing.
Hope that helps, and I'll look into our docs to make this all more clear.
WebView bouncing is a vague term and I'm not exactly sure which you are referring to. If you're talking about the entire frame, it's now "DisallowOverscroll" in the Cordova config. If you use the ionic utility you'll get the correct config for a new project.
To hide the status bar, use the status bar plugin (org.apache.cordova.statusbar) and call StatusBar.hide(): https://github.com/jonathannaguin/org.apache.cordova.statusb...
The ui-view vs ion-view discussion: use ion-view. We basically have a custom ui-router implementation with multi-stack routing.
Hope that helps, and I'll look into our docs to make this all more clear.
Thanks for responding!
I did use the DisallowOverscroll in my config, I still had to manually add has-bouncing=true to every ion-content tag.
These are the values I tried:
Thanks again though for answering!
I did use the DisallowOverscroll in my config, I still had to manually add has-bouncing=true to every ion-content tag.
These are the values I tried:
<preference name="fullscreen" value="true" />
<preference name="webviewbounce" value="false" />
<preference name="UIWebViewBounce" value="false" />
<preference name="DisallowOverscroll" value="true" />
Thanks again though for answering!
Thank you for your work on Ionic! I have been using it the last few weeks and really like it. I think the navigation performs well. Honestly, outside of a few minor bugs that got fixed in the last release, the only real problem I have had with it has been learning Angular. But, that will come with work.
Good call, we are going to be more proactive about teaching Angular along with Ionic, so I'll throw your vote in for that :)
I have found the best resource to be egghead.io. It would be nice if he did a few videos for you guys.
Has anyone used AppGyver, which seems to be a framework that incorporates this combo of native navigation with WebViews and Cordova? I've been working solely on the HTML components of an app, nav included, but would love to hear anyone's experience.
Plugging my own work here, but I wrote a blogpost about how to do such a system from scratch on iOS.
http://luminescente.com/2014/03/how-to-build-your-own-phoneg...
I'm also writing a book on the subject, there's a link to it at the bottom.
Any feedback appreciated.
http://luminescente.com/2014/03/how-to-build-your-own-phoneg...
I'm also writing a book on the subject, there's a link to it at the bottom.
Any feedback appreciated.
Pretty cool, thanks!
Here is some feedback:
* Overall it's great.
* The instructions on where to input the code starts out very precise, but as the piece goes on it gets sloppier. For example, "Open WebViewController.m and after the viewDidLoad method, after the comment, add this new method" is not entirely accurate, because you're adding the new method AFTER the existing method, not after the comment inside the existing method (fortunately the screenshot is there to show what you mean). And the very last code sample (for the loading indicator) doesn't actually have a code sample, just the screenshot.
* I was not able to get forward/backwards swiping to work -- but perhaps this is just a limitation of the simulator?
Definitely looking forward to seeing a more fleshed-out version. Thanks!
Definitely looking forward to seeing a more fleshed-out version. Thanks!
Thanks! Points taken. I will review the text to make it more accurate and clear. Seems appropriate since I'm trying to do a "Clear Hybrid Apps" ebook. :)
To swipe forward/back you have to drag from the exact edge which on the simulator takes some practice.
To swipe forward/back you have to drag from the exact edge which on the simulator takes some practice.
This is exactly what I was looking for - Thanks for the article looking forward to reading it this weekend
I use AppGyver. I think its great of iOS apps but still weak on Android ones. To be fair to them, they seem to be making improvements on that side of things. But since a big argument for going non-native is immediate cross-platform support, the lack of fully functional android support could be a deal breaker.
Motorola Solutions employee here (MSI bought RhoMobile three years ago).
RhoMobile is a platform that deliver on building a native application using web technology. A lot of the idea are borrowed from Ruby on Rails in the Framework (MVC framework done in Ruby with a simple ORM on top of SQLite).
You can take a look on Launchpad, MSI developer website [5]
[1] http://docs.rhomobile.com/en/4.1.0/guide/app_upgrade
[2] http://docs.rhomobile.com/en/4.1.0/guide/apisummary
[3] http://docs.rhomobile.com/en/4.1.0/rhoconnect/introduction
[4] http://www.prnewswire.com/news-releases/rhomobile-rhodes-sma...
[5] https://developer.motorolasolutions.com/community/rhomobile-...
RhoMobile is a platform that deliver on building a native application using web technology. A lot of the idea are borrowed from Ruby on Rails in the Framework (MVC framework done in Ruby with a simple ORM on top of SQLite).
* Updating the app without user intervention?
covered[1]
* Common set of API available in JS and Ruby?
yes [2]
* Offline capability, local data and a synchronization server based on a NoSQL DB?
of course. How can you leave without a NoSQL DB? :-) [3]
You can take a look on Launchpad, MSI developer website [5]
[1] http://docs.rhomobile.com/en/4.1.0/guide/app_upgrade
[2] http://docs.rhomobile.com/en/4.1.0/guide/apisummary
[3] http://docs.rhomobile.com/en/4.1.0/rhoconnect/introduction
[4] http://www.prnewswire.com/news-releases/rhomobile-rhodes-sma...
[5] https://developer.motorolasolutions.com/community/rhomobile-...
Great article from 37signals. I built my app for Fitbit, Fitwatchr (https://itunes.apple.com/us/app/fitwatchr/id684005201?mt=8&u...), using web tech only. I leveraged PhoneGap for native access (OAuth via an InApp browser and Google Analytics) via plugins, PhoneGap Build for native iOS, Android and Windows Phone 8 builds, and KendoUI Mobile to achieve native looking UI for all (handled mostly automatically!). They are correct - in 2010 the technology, tools, or performance may not have been quite there yet, but in 2014 things are much more viable.
He goes through all of the pros and cons of this approach, but doesn't mention which framework they used for the html portion (unless they rolled their own in which case might as well go all native). There are so many different frameworks it seems (Phonega, Cordova, Trigger etc), does anyone out there have a rundown of all the different ones and the quality of each?
> unless they rolled their own in which case might as well go all native
There's a world of difference between rolling your own WebView wrapper and "going all native".
There's a world of difference between rolling your own WebView wrapper and "going all native".
We're not using a framework. The app itself is a standard Cocoa/Objective-C app, just using a mix of web views and native views for rendering the content of individual screens.
Surprised that Famo.us has not been mentioned in this thread. It looks like a very significant technology to solve this problem.
https://famo.us/about/ http://www.codepen.io/befamous/
https://famo.us/about/ http://www.codepen.io/befamous/
I'm not. To the degree famo.us is wonderful, its about page gives a misleadingly bad impression on my default mobile browser.
On my landscape iPad Air, the hamburger menu on the first link flapped state during scrolling and selection. I genuinely had no idea, when I tapped Docs, whether I'd got that or Demo. Scrolling the next page moved the content up, but also the header, while leaving the left side navigation in place.
On my landscape iPad Air, the hamburger menu on the first link flapped state during scrolling and selection. I genuinely had no idea, when I tapped Docs, whether I'd got that or Demo. Scrolling the next page moved the content up, but also the header, while leaving the left side navigation in place.
I totally understand how our mobile site gives a poor impression.
We're aware of this, but FWIW, we haven't really spent much time on the mobile site at all given other priorities and because there really isn't much if any content on there that provides utility in a mobile use context. Most of our work at the moment is focused on Famous University (desktop only). We'll fix the mobile experience as soon as we wrap up the more pressing parts.
If you want a real world example to try out and judge us one, install the chrome app Beepe.me. Plugg.me is another app, but I don't think it's been released yet.
https://beepe.me/getstarted http://www.plugg.me/
We're aware of this, but FWIW, we haven't really spent much time on the mobile site at all given other priorities and because there really isn't much if any content on there that provides utility in a mobile use context. Most of our work at the moment is focused on Famous University (desktop only). We'll fix the mobile experience as soon as we wrap up the more pressing parts.
If you want a real world example to try out and judge us one, install the chrome app Beepe.me. Plugg.me is another app, but I don't think it's been released yet.
https://beepe.me/getstarted http://www.plugg.me/
The only true advantage the hybrid approach offers is improved interface performance, but that comes at the great cost of (1) increased complexity (multiple technologies, possibly multiple teams), (2) poor distribution and conversion (install require), (3) dealing with draconian app store approval bureaucracy, and (4) speed of tech and design iteration much slower than the web.
The gap for this sweet spot is going to close very rapidly over the next year or so due to work being done by us at famo.us and engineers working on react/om.
DHH, like others love to point out Facebook's decision to pull out of HTML5, but that is going to become a tired meme. One of the FB engineering managers, Dave Fetterman, who was instrumental in making the call to go with HTML5 and then reversed course towards native, is now the VP of engineering here at Famo.us. That's a testament to what's possible soon, since typically someone doesn't go back an revisit what many people popularly consider to be be a mistake unless there is real value there on the horizon. The fact that Fetterman is back working on this problem and that Pete Hunt and team at Facebook is actively working on react is testament to the performance that's now achievable without having to be a javascript neckbeard.
If you were a web developer that left the web years ago for native land, or you have always been in native land and were waiting for the web to catch up, now is the time to start exploring what's possible. There will always be a use case for native technologies, but the web is going to gut a lot of the current use cases for native over the next 1-3 years. When that happens, there is going to be a glut of iOS and Android devs and a dearth of javascript developers who really know how to build great web apps.
(disclaimer: I work for famo.us)
The gap for this sweet spot is going to close very rapidly over the next year or so due to work being done by us at famo.us and engineers working on react/om.
DHH, like others love to point out Facebook's decision to pull out of HTML5, but that is going to become a tired meme. One of the FB engineering managers, Dave Fetterman, who was instrumental in making the call to go with HTML5 and then reversed course towards native, is now the VP of engineering here at Famo.us. That's a testament to what's possible soon, since typically someone doesn't go back an revisit what many people popularly consider to be be a mistake unless there is real value there on the horizon. The fact that Fetterman is back working on this problem and that Pete Hunt and team at Facebook is actively working on react is testament to the performance that's now achievable without having to be a javascript neckbeard.
If you were a web developer that left the web years ago for native land, or you have always been in native land and were waiting for the web to catch up, now is the time to start exploring what's possible. There will always be a use case for native technologies, but the web is going to gut a lot of the current use cases for native over the next 1-3 years. When that happens, there is going to be a glut of iOS and Android devs and a dearth of javascript developers who really know how to build great web apps.
(disclaimer: I work for famo.us)
You guys need a little love on your page :) I've not heard of it before so I google it and get to what appears to be the home page, and am presented with a login box with zero info about what it is, or why I would want to register or log in in the first place. Plus 3 of the links in the header aren't linked to anything. Not the best first impression!
Yeah, it does need some love. We're aware and plan on really fixing it up over the next month or so. For the most part almost all engineers on the team are working on some fundamental part of our medium to long-term vision and we're mainly trying to bring all those parts together in a coherent way first.
Another reason for its current state, is that the tech media and the community have been quite eager to take care of our positioning and messaging, so we haven't had to focus engineering effort on these areas too much in order to see adoption and growth. Improvements are coming. Look out for changes to the site over the next 1-2 months.
Another reason for its current state, is that the tech media and the community have been quite eager to take care of our positioning and messaging, so we haven't had to focus engineering effort on these areas too much in order to see adoption and growth. Improvements are coming. Look out for changes to the site over the next 1-2 months.
> but the web is going to gut a lot of the current use cases
> for native over the next 1-3 years
FWIW, I've been doing the web app tech schtick since about 2010 and since about 2011, I've been pretty consistent on the 2014-2017 time frame.
Everything is in a half-baked state because people start on a project, realize that other parts aren't good enough, so because they have work to get done, the move on to the tech that works for the job at hand. Things are finally getting to the point where web app tech has achieved "fitness for use" (the most accurate definition of quality I can think of), which means that library authors are no longer in a position where they have to maintain and grow a library in isolation while they wait for other libraries to catch up.
On top of all that, what has also caught up is the money. There is now real solid VC money backing up companies that either create webapp tech or are betting on webapp tech as part of their strategy. With money, you have people who no longer need to depend on the goodwill of others to push things forward.
Lastly, there's been a cambrian explosion in the general sophistication and knowledge level in the JavaScript community. NodeJS created a viable JavaScript environment free of all the bullshit that comes with myriad user agents. They made it possible for engineers coming from many other language communities (C/C++, Java, Python, Ruby, Perl, etc.) to really dig into the language and bring diversity of ideas and experience into the JavaScript community. That diversity is now jumping the network gap and becoming more common on the browser side of things.
Does web app tech meet the conditions of "fitness for use" for all use cases of native? Certainly not. There are several areas where, as you correctly pointed out, it's falling behind. But this likely won't be the case in about 2017, when the only remaining difference between native and web is going to be a performance gap of at most 2x for certain uses. There are not a ton of use cases where a 2x performance difference makes the difference between something being fit for use or not, especially when you consider other benefits native can't achieve like distribution via hyperlink and incremental loading of non-content parts with use.
One of the most important questions an engineer needs to ask is "Does it matter for my career whether I'm on the right side of technology when a fundamental shift happens?". For career engineers working in areas where native is likely to have an edge for years to come, it probably doesn't matter. But what happens if you're an engineer with an entrepreneurial bent like many on HN? Starting in 2008 and going into 2011, if you didn't have legit talent on your team for building iOS and Android apps, that was a problem for your business. Starting in 2015 and going through to 2017, the same will happen with web app tech. If you want to be in the right place at the right time, this is the year to actually start learning, so that you're well positioned for the next three years and opportunities shift.
Fundamental changes happen. It's valuable to be able to time things to account for those changes.
Everything is in a half-baked state because people start on a project, realize that other parts aren't good enough, so because they have work to get done, the move on to the tech that works for the job at hand. Things are finally getting to the point where web app tech has achieved "fitness for use" (the most accurate definition of quality I can think of), which means that library authors are no longer in a position where they have to maintain and grow a library in isolation while they wait for other libraries to catch up.
On top of all that, what has also caught up is the money. There is now real solid VC money backing up companies that either create webapp tech or are betting on webapp tech as part of their strategy. With money, you have people who no longer need to depend on the goodwill of others to push things forward.
Lastly, there's been a cambrian explosion in the general sophistication and knowledge level in the JavaScript community. NodeJS created a viable JavaScript environment free of all the bullshit that comes with myriad user agents. They made it possible for engineers coming from many other language communities (C/C++, Java, Python, Ruby, Perl, etc.) to really dig into the language and bring diversity of ideas and experience into the JavaScript community. That diversity is now jumping the network gap and becoming more common on the browser side of things.
Does web app tech meet the conditions of "fitness for use" for all use cases of native? Certainly not. There are several areas where, as you correctly pointed out, it's falling behind. But this likely won't be the case in about 2017, when the only remaining difference between native and web is going to be a performance gap of at most 2x for certain uses. There are not a ton of use cases where a 2x performance difference makes the difference between something being fit for use or not, especially when you consider other benefits native can't achieve like distribution via hyperlink and incremental loading of non-content parts with use.
One of the most important questions an engineer needs to ask is "Does it matter for my career whether I'm on the right side of technology when a fundamental shift happens?". For career engineers working in areas where native is likely to have an edge for years to come, it probably doesn't matter. But what happens if you're an engineer with an entrepreneurial bent like many on HN? Starting in 2008 and going into 2011, if you didn't have legit talent on your team for building iOS and Android apps, that was a problem for your business. Starting in 2015 and going through to 2017, the same will happen with web app tech. If you want to be in the right place at the right time, this is the year to actually start learning, so that you're well positioned for the next three years and opportunities shift.
Fundamental changes happen. It's valuable to be able to time things to account for those changes.
User's don't care if you use native or HTML5 as long as you get them what they need.
One of the major problem with HTML5 is not HTML5/JS but how you we are trying to use those. We want to use all the libraries and frameworks. Backbone, AngularJS, bootstrap are good but using those on mobile will slow down your app. Also there is this mentality that you can only have good interaction if you build 100% client side rendering.
Everyone thinks that rendering on client will be faster as we are only sending JSON and html templates are cached. They should do compare and see if JSON that they are sending is really lighter then rendered HTML. Most of the time I found that after gzip, HTML is smaller compare to JSON.
Browser wise, Android is lagging behind when it comes to transitions. Its getting better but still not good as Safari or IE on WP8. Also Samsung is always uses wrong version of android browser. Even on galaxy S4, they screwed up big time (Browser on S3 was better than S4).
I build hacker news mobile client using HTML5, and I do have 4.5 star ratings on the both app stores.
https://play.google.com/store/apps/details?id=com.premii.hn
https://itunes.apple.com/us/app/hacker-news-yc/id713733435
or Try it on your browser
http://hn.premii.com/
One of the major problem with HTML5 is not HTML5/JS but how you we are trying to use those. We want to use all the libraries and frameworks. Backbone, AngularJS, bootstrap are good but using those on mobile will slow down your app. Also there is this mentality that you can only have good interaction if you build 100% client side rendering.
Everyone thinks that rendering on client will be faster as we are only sending JSON and html templates are cached. They should do compare and see if JSON that they are sending is really lighter then rendered HTML. Most of the time I found that after gzip, HTML is smaller compare to JSON.
Browser wise, Android is lagging behind when it comes to transitions. Its getting better but still not good as Safari or IE on WP8. Also Samsung is always uses wrong version of android browser. Even on galaxy S4, they screwed up big time (Browser on S3 was better than S4).
I build hacker news mobile client using HTML5, and I do have 4.5 star ratings on the both app stores.
https://play.google.com/store/apps/details?id=com.premii.hn
https://itunes.apple.com/us/app/hacker-news-yc/id713733435
or Try it on your browser
http://hn.premii.com/
I started working on this but no time.
http://dn.premii.com/ - Designer News For mobile. Lot of animations and works on Android, Safari on iOS and IE10+ on WP8.
http://dn.premii.com/ - Designer News For mobile. Lot of animations and works on Android, Safari on iOS and IE10+ on WP8.
I'm very impressed by the performance on both your DN and HN clients. Usually everything web lags a lot using the stock browser on my Galaxy S3 but these are very smooth. What's your secret?
I'm curious how they get away with having basically 100% of their app as web-based. We used native controls for login screen and another screen to play it safe. Are we playing too safe?
If native development is slow compared to the HTML, you are doing something horribly wrong.
But there are an Ocean of cheap / slow and older phones out there, which i dont think they will have quite the same experience if it was in Web compared to Native.
The Gap will shrink, as technology moves forward. But for the best experience around, may be its best to stick to native for now.