Dave Porter, SproutCore Core Team Member & Lead Developer, recently delivered a webinar on 14 Ways HTML5 Makes a Major Difference for Web and Mobile and in this blog post are the answers to the questions that were asked at the end of my presentation. If you didn't have a chance to view the live version, please follow this link and watch the recorded session.
1. In your opinion what is biggest reason to have your site or mobile app developed in HTML5?
Of all the reasons that I go over in this presentation, the biggest is definitely Write Once, Deploy Anywhere. This was always the great promise of the open web, so it’s not news: what’s news, and what this presentation is about, is that the tradeoffs that always held the web back have all but disappeared!
2. Explain the difference between native apps, web apps and mobile websites.
There are three axes here: native vs. web, mobile vs. desktop, and content vs. app. This presentation is mostly about the first one: the open web’s newfound (in the last two years or so) ability to deliver the speed and capabilities of native. Those same boosts in speed & capability have made it a great option for developers (and a convenient option for users) of mobile apps and websites.
For more on mobile vs. desktop and content vs. app, check out my presentation on how to move forward once you’ve chosen HTML5 for your project.
3. If I have an app built in HTML5 can I take advantage of the phones features and capabilities like vibrate, camera, geo-location, accelerometer et cetera?
Two answers: Yes and yes.
If you need features that haven’t made it into HTML5 yet (say, vibrate), you can go the PhoneGap route. PhoneGap (and similar frameworks) wrap your HTML5 app in a native wrapper, and expose any features that haven’t made it through the standards process yet. This restricts you to app stores, however.
Luckily, the standards process is hurtling forward, and things like accelerometer, camera, and geolocation are all in HTML5 and live in your friendly mobile web browser! Firefox’s mobile OS project is pushing the boundaries even further, too – like the battery level API that they’ve recently gotten standardized and should be available in this year’s generation of new phones.
4. Can you make older CMS systems responsive design or its better to start again with a newer version?
Retrofitting responsive design can be a challenge, and it’s always easier to build a feature that was designed in from the start. That having been said, your CMS of choice almost certainly has a good selection of responsive themes, and you may just be able to swap one in!
5. What’s next after HTML5?
Although there exists a clearly delimited specification called “HTML5”, that’s probably not what you’re asking about. HTML5 has sort of become this wildly over-extended buzzword, representing an ongoing, dynamic, really thrilling process of breakneck innovation on the open web. When the HTML5 movement began, there were no devices that had both web browsers and accelerometers, but here we are with a functional standard and implementations in the wild.
So HTML5, the movement, is a process more than a delimited specification. What’s next? More breakneck innovation.
6. Many claim that HTML5 Cannot compete with native because of the inferior user experience. What is your opinion on this?
You do hear that a lot. It’s a nonsensical statement, but there’s some truth under it. User experience isn’t technology, it’s what you do with it, and lots of folks are designing and building fast, responsive, exceptional user experiences on the web.
So in large part, this is an antiquated idea. The underlying technology is entirely capable. That having been said, native app development has been around longer, and the toolsets are often more mature on the native side. HTML5 has effectively caught up to native, letting its cross-platform and ease-of-deployment advantages shine; now you’ll see the toolsets starting to catch up as well, making it easier than ever to build great “native-quality” experiences on the web.
7. How easy is it to convert HTML5 web app to native app using phonegap, etc.?
8. Apple is the winner in the native apps monetization. What opportunities (e.g channels, stores) have developers to monetize and distribute html5 apps?
Apple has certainly done a great job creating sales channels and monetization strategies from whole cloth, and they deserve a lot of credit for it. They were of course aided by the monolithic nature of their ecosystem, and that’s a point of great contrast with the open web.
Sales channels on the web are beginning to mature: my last project, the Kobo Instant Reader, got a major boost when it made the front page of the Chrome Web Store, for example. Firefox is working hard on this problem as well. And of course one of the best parts about being as universally supported as HTML5 is that you can take the same code that your web app uses, package it up in PhoneGap or Titanium, and sell it anywhere – the App Store, Google Play, Windows Store, you name it!
9. What are your thoughts on game development in HTML5?
10. What is the most significant HTML5 advantage over Flash?
Viability on mobile is the log that broke that camel’s back, and we’re better for it.
11. What is SproutCore?
What a great question! SproutCore is a Rich Web-Application Development framework, based heavily on Apple’s Cocoa. It takes a really revolutionary, orthogonal approach to web apps, discarding a lot of the web’s document-centric nature and bringing years of application development best practices to bear. It’s the best framework out there for building native-quality web apps. If you’d like to know more, check out the introductory presentation I gave back in February.
12. In front end web development, what exactly is the use of an MVC framework?
This is a great question, which really highlights the new world that SproutCore lives in. Most web application stacks treat the browser as the slow, far-away View layer, and handle the Models and the Controllers on the server side. This makes for a slower, less-responsive, offline-incapable “application” which runs as a series of documents strung together with hrefs. Definitely sub-optimal.
SproutCore’s approach is fundamentally different: it moves the whole of the MVC pattern into the browser, with only data loaded dynamically (into the M part). It acts, and develops, like a native app, and it makes for a much better user – not to mention developer – experience.
13. Is SproutCore seamless with jQuery, HTML5, CSS3?
SproutCore is built on jQuery, HTML5 and CSS3. But those technologies, and the associated years of accumulated web development wisdom, represent a heavy compromise between the Internet’s original (and still very relevant) structure as a network of linked documents, and its recently-burgeoning purpose as an application platform. SproutCore optimizes aggressively for the application case, and leaves behind a lot of document-y cruft in the meantime. It takes HTML5, CSS3 and JS and builds a robust, desktop-quality application development experience on top of them.
This question represents a number in the same vein, so I’ll address each of the “web trifecta” directly:
CSS – There’s only one difference between standard web-dev stylesheets and SproutCore’s: in SproutCore, element positioning is done in code, not in CSS. This is necessary for some of SproutCore’s more aggressive optimizations. Outside of positioning, SproutCore uses CSS the same way you’re used to. It comes with a very nice default theme called Ace, which gives you all the good-looking widgets that you need; if you want to give your app a distinct look, then extending or replacing Ace is easy and satisfying.
14. What are some signs that a project is an app rather than an appified document?
There are two simple considerations that you can use to decide where your project lands.
The first is whether the information you’re serving up is more document-like, or more data-like. On the document side, think of news articles, blog posts, or recipes. If they’re not changing regularly, then things like bus schedules and price lists can be thought of as documents as well. On the data side are things like dynamic inventory lists, reservation listings, transactional information, stock market prices, and things like that which are likely to change a lot.
The second consideration is whether your users will be passively consuming the information, or whether they’ll be actively manipulating it – whether by searching in a lot of different ways (read-only manipulation) or by actually getting their hands dirty creating and editing new data or documents.
No matter what kind of information you’re serving up, if your users are passively consuming it, then you don’t need an app. And even if your users will be generating a few transactions, for example placing an occasional order on an e-commerce site, then you probably don’t need an app. But if each user is involved with dynamically searching, editing or creating, then you need an app! Even with blog posts: if they’re reading it, it’s just a web page, but if they’re writing it – think, Google Docs – then it can get quite app-y.
15. Is it free or paid? What is the SproutCore licensing situation?
It’s free free free! SproutCore is open-source tip to toe and MIT-licensed for maximum freedom for you and your company. We at Appnovation hope that you’ll consider us for your development and ongoing support needs, and we at SproutCore hope that you’ll consider contributing back to our community, but if you choose SproutCore, you’ll be using it under a free, perpetual license.
16. We have some pretty heavily visited online properties, can sproutcore handle that kind of traffic? Are there any high-traffic sites that use SproutCore?
SproutCore actually builds out the absolute best-case scenario for high traffic sites. Your application’s static files are packaged for maximal cacheability, and more of your application is static than with any other framework or stack. Meanwhile, the dynamic side is kept to the absolute minimum: data only, and preferably with RESTful JSON (although it’s trivial to build in support for any weird legacy APIs). So the majority of your app loads off of Apache, for example, while the Ruby or Python side is doing what it does best and serving bare bones data. Each part is as lightweight as possible.
I recently completed work on a web ebook reader for Kobo Books, Inc., which is the third- or fourth-largest ebook vendor. You can check it out at read.kobo.com. SproutCore’s primary corporate backer is a little company called Apple Inc., and their property icloud.com serves as a web extension for iPhone, and actually as a web version of their iOS operating system. If you’ve got an iPhone and an iCloud or iTunes account then you should check it out to see what SproutCore can really do.
17. Does SproutCore support any templating systems?
SproutCore sports a very powerful, highly optimized custom view API which gives you direct control over the DOM creation process – if you want it. (If you’re familiar with Backbone’s approach, ours is similar.) You can use this control to leverage the templating engine of your choice, and we encourage you to!
18. How does SproutCore integrate with, or compare to, HTML5 "native apps" for mobile devices built with PhoneGap/Cordova?
SproutCore is a powerful addition to the PhoneGap stack! With a SproutCore app wrapped in PhoneGap, you can turn your app from “native-caliber” to native-deployable via the iOS, Android and BlackBerry app stores. It’s 2013 and everybody everywhere has gotten behind the promise of the open web; PhoneGap/Cordova helps take your app the last step of the way to native.
19. Does the framework support a data persistence layer?
SproutCore’s data layer (the M in MVC, if you will) is very robust. Along with actual models, there’s a queryable data store in memory, and a data source for interfacing with any kind of API you might have to work with. The data layer is one of the banner application development features that SproutCore ports over from the desktop world.
“Data persistence” can refer to two different types of local storage: session, and long-term. If you’re rapidly reloading full pages from the server every time local state changes enough, then storing session information locally is very useful. But SproutCore applications are different: they run as true persistent applications, so you don’t need to do anything special to store data for the duration of the session – its whole data layer is just there, the whole time!
In terms of long-duration state storage, SproutCore has a really nice wrapper around localStorage (including a fallback for older browsers); for bigger data, we plan on adding support for IndexedDB & WebSQL soon (as soon as the standardization and market penetration get to the right spot).
20. Is it similar to Sencha ExtJS?
I haven’t used Sencha, but yes, the promise of a fully client-side MVC app is the same. SproutCore’s optimizations are more aggressive from a DOM-avoidance perspective, and of course SproutCore is MIT-style Free and Open Source!
21. Can you talk about the development environment? Is it possible to jump from a LAMP stack into SC?
Yup — SproutCore is generally deployed on a LAMP stack. The Apache layer serves up the static files (packaged for maximal cacheability, easing the burden on your static servers), while the P layer of your choice serves up bare bones data for client-side consumption. You’re going to be building your application differently than a standard out-of-box Django, PHP or Drupal site, but the same skills apply.
22. Does it come with pre-built widgets like datagrid, charts?
SproutCore’s view layer is chock full with desktop-caliber widgets. Its CollectionView class, and children like ListView, GridView and TableView, are optimized for enormous data-sets with thousands of rows. (SproutCore’s promise of a 100,000-item list view at the same speed, with the same memory footprint as a 10-item list, is one of its banner features, and I’ll be giving another presentation soon on taking full advantage of it.) There aren’t any plug-and-play chart views in the core framework, but I believe the extended community has some views that may serve your needs, and if they don’t, we hope you’ll commit some back!
23. What browsers do you support?
Everything all the way back to IE7. SproutCore abstracts as much as it can, and we’ve built a lot of backward-compatibility behind those abstractions.
24. Is there a preferred IDE for SproutCore?
25. What about mobile and responsive design patterns, does have support for that?
SproutCore’s layout engine is automatically responsive, in that it encourages you to lay out your application relative to the browser window (or screen, on mobile) rather than building it to a specific width. For more advanced responsiveness, we’ve got a new feature called Design Modes slated for 1.10 which will allow for responding easily and dynamically to different screen widths. The Kobo Instant Reader (read.kobo.com) makes heavy use of an early version of it; I encourage you to take a look.
26. How does it compare to YUI - What about dynamic module loading?
Dynamic module loading is super simple in SproutCore (via SC.Module), and some of the highest-performance apps I’ve seen use it to load less-used parts of the app lazily. SC even preloads them as strings, using a technique that Gmail pioneered a few years ago, when idle.
27. When will a comprehensive book on SproutCore be coming out?
Very soon! The lead developer of SproutCore himself Tyler Keating is writing one now, due for release this summer. He's the best framework-innards guy that I know, and I'll definitely be picking up a copy when it's available.
28. Is there any latency/locking issues with multiple users who are editing same data on the server?
This is of course one of the big challenges of modern applications: how do you maintain consistency between many copies of the same data? There are many long books (and many robust debates on the IRC channel) about this. You’ll have to figure out how best to solve this question for your particular needs, the same as if you were building a Django or PHP app, or a native app backed by the full power of Amazon’s Web Services. Whatever design you come up with, though, SproutCore has the tools (a full-featured data store, data source interface layer, and built-in statechart) to help you build a fast, responsive web application.
29. What do you see coming up in future for SproutCore?
That’s speaking in terms of features. In terms of market penetration, I see SproutCore’s future as, among other things, the natural successor to Adobe Flex in the corporate-intranet, data-heavy space. In a few years, I expect a lot of folks to be spending their work-days manipulating data in SproutCore instead of Flex or (shudder) Access. On their PCs, Macs, phones or iPads by the way.
30. How do I get involved?
If you’re interested in taking a closer look, head to sproutcore.com to download it and have a look at the guides. We have an active mailing list via Google Groups, and we’re on IRC at #sproutcore on freenode.