Let’s start out with a little experiment here. If you have a mobile phone sitting next to you, pick it up and take a look at it. Look at the plastic or glass, the screen, the buttons and everything else. Now I bet you’re thinking the same thing I am— “I wonder if they used injection molding or thermoforming to make that button,” am I right? Okay, maybe I’m wrong— unless you’re a plastics engineer, my guess you are probably like the rest of the 99.99999% of the population who doesn’t care. Now let’s take this a little further and examine your absolute favorite app on your phone. Do you think a lot of people ask the question, “Hmmm, I wonder if they used HTML5 or native code to build this?”
Before we move on, can we just agree on one thing? By and large, people only care about their experience with a product, and not what technology was used to build it.
Now to frame this discussion, let me pose a couple of questions that I wish I had a nickel for every time someone asked:
- Are HTML5 based mobile applications going to eventually take over the market?
- Why in the hell did Red Foundry choose to base their system on yet another proprietary markup language?
By and large, people only care about their experience with a product, and not what technology was used to build it.
The best short answer to both of these questions is probably a question itself: If you were building an F1 race car, would you only use mass manufactured off-the-shelf parts, or would you use the best parts specifically tailored for the job? To win in F1 you have to have a fast car, and to win in mobile apps you have to have an app that people love to use.
When we first started Red Foundry we had to make the same decision that many people and organizations face today when building an app:
- Use open standards like HTML5 to help us touch a large number of devices.
- Use proprietary tools and native code to help us create the absolute best user experience.
The most important thing to remember is that there is no right answer here. You simply have to decide what is most important to you and choose the best tool for the job. For us the most important thing was the end-user experience, and we felt (and still do) that HTML5 was not capable of delivering on this front. So in the end, we chose to build a proprietary system that provided the most efficient path to creating a killer user experience— the less time you spend coding is more time you can spend on UX/UI.
There are plenty of people in the HTML world who would argue that using HTML5 gives you so many benefits that it’s not worth looking at anything else. I’m not here to try to convince them otherwise, because the debate has become religious in nature and not worth the energy. What I can do is point out some of the reasons we disagree, in order to help others who are on the fence to make an informed decision.
To win in F1 you have to have a fast car, and to win in mobile apps you have to have an app that people love to use.
Now before we do that, let me be clear on something— I am a huge fan of HTML! I’ve been building websites and web applications professionally since the age of 16, and without HTML I wouldn’t be where I am today. It is an amazing and mature technology that can be used in a number of ways, but it is not a universal tool that magically fixes everything you put in front of it.
User Experience
When was the last time you used an HTML based app on your phone or tablet (notice I didn’t say desktop or laptop) and said, “Holy crap, this is the coolest thing I’ve ever seen!” When HTML5 is coupled with a fast desktop machine and browser extensions it can do amazing things, but on the relatively lower power of portable devices it becomes difficult to squeeze snappy performance out of a mobile browser. Now you could argue that devices and web browsers are getting faster, but why would Apple or Google spend more time performance tuning the web browser? If all apps run in web browsers, then all apps are built to the lowest common denominator and the differentiation between devices becomes minimal. Apps that take advantage of unique hardware features will sell more devices, not universally accessible web apps.
Red Foundry chose to build its platform completely 100% native (including UI rendering) in order to take complete advantage of all the power on the hardware.
Complexity
You simply have to decide what is most important to you and choose the best tool for the job.
HTML was first designed in the 1980′s to solve much different problems than we have today. This was a time when things like App Stores, automatic updates, and easy-to-use TCP/IP stacks didn’t exist. And do you think any of the original creators of HTML were thinking of how to optimize it for that Motorola brick phone? The fact that modern developers have to essentially master 3 very different languages (HTML, CSS, Javascript) to do much of anything on the web, just shows how much HTML has had to buddy up with other technologies to address its shortcomings. Just ask yourself the question, “has it ever really been easy to build a custom HTML website?”
Red Foundry chose to build its own markup language called RFML, which is similar in form to HTML, but purposefully built from the ground up to:
- Address and take advantage of the unique features of differing hardware.
- Combine markup, scripting, styling, and data access into one easy-to-learn language (RFML).
- Optimized exclusively for creating stunning mobile UI’s as efficiently as possible.
Developer Adoption
One of the arguments for HTML is that it’s easy to find developers who understand it. However because HTML on its own is so poorly designed for mobile, you have to leverage 3rd party frameworks like SenchaTouch or JQuery Mobile to create anything of value. These frameworks are like new languages in themselves and require just as steep of a learning curve (or more) as learning HTML. Ask any good developer and they will tell you that learning a new programming language is easy, but learning a new SDK or Library takes time.
Learning a proprietary markup language like RFML takes about the same time as becoming proficient in a mobile HTML framework.
Build Once, Run Anywhere
One of the great things HTML promised was that we could build an app once and it would run on any device. I won’t argue that this is true, but what I will argue is whether this has any significance in the mobile world. This might have been a killer feature when there were hundreds of different operating system/hardware combinations, but is this really a problem that exists in mobile? I think most people in the industry would probably agree with me that the future mobile ecosystem probably has room for 2 or 3 major operating systems. If this is the case, then build-once, run 3 places should be sufficient.
Could you imagine if the iPhone, a Ferrari, or the Mona Lisa were created by a committee?
Instead of trying to build a system that ran exactly the same on all platforms from day one, we chose to focus on one platform (Apple iOS) and make sure we did it extremely well, and then take what we learned and do it equally well on the next. As such, Red Foundry on Android wasn’t available at first, but it’s going to be available very soon.
Another problem that we’ve run into with HTML in the past is supporting the myriad of browsers and their own unique rendering and extension idiosyncrasies. This isn’t going to get any easier with mobile. New mobile browsers are released on a seemingly monthly basis and each of them are trying to add their own special sauce by “enhancing” the HTML spec with their own tags and extensions. This is why developers spend so much time today writing code or utilizing libraries to abstract and fix browser inconsistencies.
Because Red Foundry maintains the one and only “browser” (renderer) for RFML, we can essentially ensure the highest level of compatibility on each platform.
Speed of Innovation
One of the things that drives me absolutely crazy about HTML5 is the immense amount of excitement over new features that should have been available 10 years ago. To illustrate the W3C’s glacial pace, work on HTML5 began in 2004 and isn’t expected to be finalized until 2014! You can Flash-bash all you want, but if we left things up to the W3C, we’d only now be starting to do “crazy” things with our browser, like streaming video and animations. The simple fact is that platforms like Red Foundry and Flash must exist alongside HTML in order to see any innovation in this space. Yes, it’s true that Flash is now dying out in mobile, but that is only because HTML is beginning to catch up to it after 10 years— Flash has had an extremely successful run by any measure.
Apps that take advantage of unique hardware features will sell more devices, not universally accessible web apps.
At Red Foundry, we can innovate at the speed the market demands. We can also deliver the Red Foundry runtime in a binary library, which enables our customers to extend it with native code to accomplish nearly anything.
Discoverability & Openness
One of the main draws to HTML development in mobile is the ability to bypass Apple’s confusing, arbitrary, and unfair control over their App Store. There is no argument that this is true, but just because something is unfair, doesn’t necessarily mean it’s bad. I frequently have 10 minute bouts of swearing like a sailor over frustrations with the App Store approval process, but in the end I’ve always been okay with it. Why?:
- iPhone users are mentally trained to look for an app in the App Store before they look on the web. The App Store has become the “Google” for discovering mobile apps.
- I know who I’m dealing with— I don’t have to spend hours working on SEO for my web app and dealing with the hundreds of web search engines that might help people discover it. Apple makes it extremely transparent and simple to get my app noticed in their store— make it awesome, and choose a great 100 characters worth of keywords. Now I’m not saying that you don’t also need to market your app outside of the App Store, but it’s certainly not a requirement.
- I get a level playing field. Why isn’t the App Store dominated by huge publishers? Because you can’t pay for placement. Apple doesn’t care how popular your app is, they only care if it’s amazing; and if they think it’s amazing they will make it popular. The same cannot be said for web search engines like Google. In order to get noticed on the web, you have to be popular to begin with.
- They make it really easy to charge for my hard work and for people to pay for that hard work. Pretty self-explanatory.
In Conclusion…
I hope this gives some insight as to how and why one company in the mobile industry made the decision between open standards and proprietary technologies. HTML was and is a world-changing technology, but that doesn’t mean it solves all the world’s problems— it has strengths and weaknesses like any other technology and should be considered because it solves a specific problem, not just because it’s ubiquitous and open.
Another important thing to keep in mind: Proprietary does not mean Evil. We didn’t choose to build a proprietary technology so that we could muscle out the competition and charge users exorbitant fees (building apps with RFML is completely free), nor do we care about being dictatorial about the future of our platform (our customers play a vital role in guiding us). Open and organized standards are extremely important in our world, but when it comes to creating something truly unique and innovative, they don’t always fit the bill. Could you imagine if the iPhone, a Ferrari, or the Mona Lisa were created by a committee? Sometimes you just need stick to your principals and forge your own route to innovate and reach success.
No one cares how you get there, only that you arrive in style.
Cheers,
-jim
It’s been an amazing year for Red Foundry, and 2012 is gearing up to become even better! It’s hard to believe that only 2 years ago that I, along with co-founders, Ron Franczyk and Andrew Newman started to build the foundation of the company you see today. Our vision then, as it is still today, is to unleash the power of applications on mobile and connected devices by building great products and technologies to remove the cost, complexity and barriers associated with developing apps. As veterans of successful startups we’ve learned a few lessons, but none more lasting and important than to do what you love and hire brilliant people for their passions and talents to fill in the gaps. Personally, my passion and talents have always centered around creativity by designing, building and evangelizing great technology. Fortunately I’ve been able to do this at Red Foundry, but as we continue to grow, my day-to-day responsibilities as CEO have started to take me away from what I love to do. I can’t say this is a big surprise, because I knew the duties of CEO would eventually overshadow my passion for creativity— and when that happened we would need to find the right person with a talent and passion to take on that role. The only surprise is that it took so long to find that person! But it does take time to find and recruit great talent, and in this case I’m glad we were picky and took our time.
