The pendulum of Web vs. native technology continues to swing, and this is a good thing
My favorite topic, “Web vs. Apps”. Why do we keep coming back to it? Because it is important, because there is an itch, because there are trade offs, because you can choose either to do the job, and whenever you do something new you have to revisit your assumptions and how they will affect your choices this time.
There is a scale of native to Web (or other non-native platforms). It is rare to find any application that is purely on one side or the other. Again, to set the context, we are talking about how you build your apps that will be delivered through an app store here, ignoring benefits of having a Web presence (although pros and cons will tie into how much you need that presence AND how different it should be from the native apps).
Web technology can deliver more and more
DHH talked about the sweet spot of native navigation with web content within. The Web stack has gotten better, both due to software upgrades (e.g. ChromeWebView) as well as the fact that phones keep getting faster on the hardware side.
It is important to acknowledge where DHH is coming from too. His heart comes from a server rendered web application place. A lover of Ruby. Interestingly, a year ago, we were hearing someone else talk about how they could use their beloved Ruby and still be native, when Nick Quaranto posted about the RubyMotion built Basecamp application. The new Basecamp hybrid app doesn’t even have the shell with RubyMotion:
“our next gen is pure ObjC. We decided to dig in and learn the platform as a team.”
What about the UX?
On the one hand the Basecamp UX is relatively simple. If the team isn’t looking to add some crazy components that can only be done in a native manner, then it can be a good choice to take the approach they have.
At the same time, iOS applications have broken free from the “wow they all look the same” of early years. Over time teams have worked out how to make the applications fit the platform while still having appropriate custom feel to them too.
This opens the door for “well if we need to build a custom UI and controls we can choose which stack to do that in”. There is the flip side too though. Some of the best applications make dramatic use of the native device capabilities, and you can build dramatic effects on native that you can still not even get CLOSE too using Web Technology.
This will always be the case, and that is why if you build something that is just wrapping one WebView, you are closing the door to that world.
The original Facebook app was somewhat reproduced with web technology by Sencha, but how about Paper? Maybe you can get there (Famous does a solid job), but there are some things that you need all of the performance available to you to pull off well.
DHH talks about the paradox of choice, and how people like choices more than they like to choose. That is true and very real, and is something that the Web has made frustrating. There are so many choices and the lack of a component model meant that you were backed into corners for so long. We are seeing some progress there with W3C Components and the like.
There are some pieces of “good” that come with choice though. The Web, even with its constraints, have allowed a massive diversity. With that diversity comes evolution. This can be a match made in heaven if the platform is watching and the diversity spurs the platform to also evolve and raise the bar. The host assumes, speeds up, and grants new abilities and potential allowing the parasites to use the host for things that they were doing, and take their effort to build more.
This is why good architecture lets you put off decisions for as long as possible. The minute you are backed into a corner, your fate may be sealed and you can die in a small box.
Your app is also a platform
The great ability of the native application is that it has code preinstalled (since the user had to install it) and it has hooks and permissions to a lower level than a general purpose environment (the browser).
Your application, or a set of applications, can together make a great host for other native and Web based code. You can build a native customer scanner, and setup a simple way for a web view within the application to call it, get data from it, and come back.
On a case by case basis you can choice for parts and pieces to be Web or native. You can A/B test between them…. try some new things via Web because it can update without going through the store. Your configuration service and various APIs can send down events that can be rendered in different ways.
The Facebook news feed is a great example of this. Imagine an array of JSON that comes down with different message types. The controller can say:
“Hey, do I have a native view that can display this type?”
If not, you can render it via the Web.
The pendulum is always swinging, and it is at a different point based on what you are trying to build, and the people you have to build it.
One of the huge challenges that I am seeing in larger companies is the switch to thinking about a holistic customer.
I have seen variations on this time and time again:
- “Crap, we need a mobile team to build a mobile app!”
- “We have built feature X for desktop, mobile team can you implement it now?”
- “Our mobile and Web experiences are too disjointed”
- “Let’s try to ship mobile and Web experiences at the same time!”
- “Let’s build vertical teams that can deliver mobile and Web”
- “Let’s plan products for people, and not think of one platform ‘first’”.
Huge organizational changes are happening to align this thinking. Teams are working out how to work. We had a bit of a golden era of simplicity when you just had to build a web experience (very simplified… many companies have had to build customer centric experiences to various form factors… TV, kiosks, etc) and we are growing our chops around how to make us deliver better solutions for our customers.
So, the pendulum keeps swinging, and this is in fact a good thing. It means that there is choice. It means that you can choose what fits for you. It means that you can make changes over time.