Building Rich Internet Apps with Drupal & HTML5 - Q&A

Thank you for attending my webinar - Building Rich Internet Apps with Drupal & HTML5. I really appreciate the support and the amount of interest in this topic that you guys have shown! This blog post is dedicated to answering the questions that were asked during the webinar; unfortunately I couldn't get to all the questions but please feel free to leave any more in the comments and perhaps there will be a Part 2 of this Q&A.

Q1: What type of applications would you recommend to develop using these technologies together?

Applications like the one I’ve shown in the demo are the perfect example. And for good reason, I have shown a reader app, not because I want to promote Kobo, but to demonstrate the effectiveness of HTML5, CSS3, and JavaScript (which is what Sproutcore is about) in creating a web-app. A reader app ties in with the concept of Hybrid Model perfectly. The Kobo server not only serves data for this HTML5 Reader app but for their native iOS, and Android app, which follows our model – the server-side is separated from the client-side.

Facebook apps are good candidates to use these technologies. Facebook gives you a Canvas to work with, which essentially loads your website into an iframe, however, performance is not that great when working with traditional-style websites. For every page request, Facebook has to load the webpage first, and then show it to the user. Facebook is acting as a middle-man. So if you can eliminate the need for Facebook to fetch pages then your app will perform so much better.

In a nutshell, if you foresee that your application is going to have a content repository with workflows and needs to be highly interactive then a JavaScript HTML5 UI coupled with Drupal is best choice.

Q2: How could we introduce and streamline this hybrid model into a development environment?

As mentioned before the Hybrid Model demands a deeper consideration in deciding on how to separate business logics or requirements for client-side and server-side. It‘s architecture that is not too well adopted for websites, but for web applications it’s second nature. To start off, Business Analyst will need to gather as many requirements as possible so that the Solution Architect or Lead Developer can draw the line between what business requirements can be accomplished on client-side and what on server-side. Once that is established, we should focus our attention to designing the JSON REST API. Front-end and Back-end developers must agree upon the API before any work can begin. In this case, both front-end and back-end can work in parallel.

Q3: What do we do with the themes and templates on Drupal and is the UI going to be on the same server or somewhere else?

Since external users are not interacting with Drupal directly, we don’t need Drupal to do any themes and templates. Now our JavaScript HTML5 UI is external to Drupal, meaning it is not a Drupal theme. We may view the UI as a standalone app that talks to Drupal. So the UI doesn’t need to be living on the same server, in fact, performance-wise, the UI would ideally be hosted somewhere like on a CDN (Content Delivery Network). However, it can be on the same server with Drupal just not within the Drupal directory.

Q4: Can you please define assets briefly?

In our context, “assets” refer to anything that enriches the UI, or adds “life” to it. These are, but not limited to: images, video and audio files, Flash (SWF) objects, CSS, and JavaScripts.

Q5: This might get answered later on... but I thought one of the great strengths of Drupal was its theming! If Drupal becomes SaaS, where is the theming motor going to come from?

I agree that one of the great strengths of Drupal, besides content managing, is the theming/template engine. When we drop that part from Drupal and attach our external UI crafted from the HTML5 and JavaScript, the template motor is coming from the JavaScript framework that we are using. I highly recommend using a strong framework such as Backbone.JS, Sproutcore, or Ext JS. For the theme, you may want to combine the templates with a CSS framework like Compass and/or Foundation 4.

Q6: It seems like "thickening" the client is a good choice for sites that are frequently used. What are some best practices for sites that may be visited infrequently and aren't likely to create app interest in users/viewers?

As you’ve termed it “thickening” the client is good for sites that are frequently used, but that’s not all. Websites that want to respond well to users, say, the user clicks a button or a menu pops up or the page would flip and content is already there, and with no wait time between the interactions, thickening the client is a reasonable thing to do.

Now for sites that are infrequently visited, the best practices for deciding whether or not to go the web-app route:

1. If your current websites are mainly displaying static content, don’t require a lot of user interaction and it’s fine to have users waiting for page load, then stick with traditional websites.
2. Benchmark your website; find out what is your general audience. Some users have no problem with plain-old websites, but some users love fancy and quick-n-snappy UI in websites.
3. If you foresee or plan for your current website to have increased functionalities and it’s going to become like an application, this is the great opportunity to “thicken” the client.

Q7: What happened to "don't store state" in the browser? Is this old-fashioned advice that's not needed anymore?

The statement, “don’t store state” in the browser, is typically referring to the stateless model that the World Wide Web and the HTTP protocol is based upon. Because state is not preserved in the underlying protocol, it would make sense to not have the browser remember the state. Now that we are moving toward web-apps and HTML5 is meant to accelerate the process, stateless design is becoming outdated. If you look closely at the HTML5 features list, we have Local Storage, WebSQL, IndexedDB, and Application Cache, these essentially break the stateless design pattern. Now, let’s take a step back and look at how we implement a website before HTML5, we use cookies/sessions and URL to allow the browser to be state-full. In a sense, we’ve already broken the stateless design pattern. One thing to remember is that the HTTP protocol is always stateless, so we are always communicating in a stateless world. What we’ve done is altered how the app behaves but not the communication.

Q8: Drupal seems to be using Backbone.JS how does this compare with Sproutcore?

In a nutshell, Sproutcore and Backbone work in the same way. Sproutcore is heavily on the client-side MVC structure while Backbone is a bit more relaxed. Backbone is super light weight in comparison to Sproutcore. One reason that Sproutcore is more suited for web-app is the Statechart feature which only not organizes views but also drives the application. Statecharts can be seen as the Finite State Machine in Computer Science. Backbone.JS and Underscore.JS are being added to core because they need to provide the foundation for the inline editing feature in the coming release of Drupal 8, and because Drupal 8 is headed toward SaaS, Backbone.JS would really benefit Drupal.

Q9: Is there a recommended IDE for Sproutcore?

Any IDE that can keep track of JavaScript functions and files is great. Sublime Text 2 is a good choice because you will run into cases where you must search through files to look for function names. I personally use Komodo just because I do PHP and JavaScript.

Q10: How much PHP programming is involved in your Hybrid Solution based on Drupal? Can you implement serverside business logic in JavaScript? Can Sproutcore be used server-side?

PHP programming would be the same amount as it is when creating your own modules. It really depends on the business logics you planned to implement on the server. However, if all the business logics can be achieved with contributed modules, then no code writing is needed.

Implementing server-side business logic in JavaScript is not a good idea because of security issues. Keep in mind that JavaScript is not safe; anyone can download the script and look at it. So it is not wise to implement server-side logic there. So in the Hybrid Model, I advised that the client-side only implement that logic which is closely related to display, for that reason.

Can Sproutcore be used on server-side? No. Sproutcore is for the client, if you want server-side JS, use Node.JS instead.

Q11: How can you access the MySQL DB in Drupal? Do you need PHP to do so or can JavaScript on the server be used for this?

Drupal database abstraction layer provides the API to read/write to the MySQL DB. Your JavaScript client will call to the JSON REST services Drupal provides to get data, and Drupal using the DB abstraction layer will handle getting data from the DB.

Q12: What is the preferred IDE for PHP/Drupal?

I use Komodo personally.

Q13: Using the hybrid model, how does one configure the Drupal appearance / theme aspects? What are the ways in which I have to tailor Drupal so that it acts as a content repository and not a UI driver?

In the Hybrid Model, we have dropped the appearance/theme portion in Drupal for external users, meaning visitors will interact with the JavaScript HTML5 UI instead, and only administers would log into Drupal directly. Essentially, if you do a fresh install of Drupal it is already a content repository. The remaining piece is to provide a JSON REST API for the UI to connect to Drupal. Say, we have 'example.com/' pointing to your UI, and 'admin.example.com/' is your Drupal instance, you can create a landing page to allow Admin to login.

Q14: What type of app is good for HTML5 only?

This is a very open-ended question as any app can benefit from HTML5. There's not really an app that is only good for HTML5. So if your app utilized at least 2 or 3 HTML5 components then it is a good app for HTML5. Games, for example, use the Canvas component and WebGL (on Chrome) to render graphics. Reader applications, like Kobo, use Local Storage, Application Cache, History, and IndexedDB.

Q15: Do I have to develop the web-app from start to finish in Drupal to be able to use all of the Drupal features or can I just incorporate it into my existing website?

Honestly, it is best to design the web-app from start to finish in Drupal and in JavaScript UI, because it’s much better to layout where client-side and server-side business logic would belong in the beginning. But you can start anywhere in between, all you have to do is build that JSON API and make sure that API hooks into all the Drupal features you need, so when the UI calls, everything is there.

Q16: Also, Is it a must to use PHP MVC or framework to be able to use it?

No, the Hybrid Model is really an architectural layout to structure your application. You don’t need to limit yourself to MVC frameworks on server-side and client-side. In fact, Drupal is not a MVC framework, it is still a PAC, and yet I recommend using Drupal for server-side.

Q17: If a web-app/website has some interactive content as well as some more static content, can Drupal serve up static pages while the client-side JS serves up dynamic content? (a hybrid-hybrid model?)

Yes. You can do that, as long as you have set aside which URL points to the web-app and Drupal, they can work simultaneously. For example, Drupal site only serves static node pages, and all your Views are outputting JSON instead. Calling those Views will split out JSON and not the actual page.

Q18: It looks like SproutCore uses Ruby and RubyGems somehow - can you please explain how that fits with JavaScript?

Sproutcore is JavaScript. Sproutcore uses Ruby and RubyGems to build and compile your JavaScripts into an app package.

Q19: How would you benefit from Drupal-HTML5-CSS3-JS vs.Node.JS-HTML5-CSS3-JS? i.e. What is the benefit of doing server side Drupal versus 100% JS using Node.JS?

Drupal gives you the benefits of having a CMS, and Node.JS doesn’t. It only gives you the structure to build an application. The question is why build a CMS yourself when you already have it, and all you really need to do is add the JSON REST API component. There is no real benefit in the underlying technology, in terms of, mixture of PHP with JS and pure 100% JS. Even if you implement 100% JS on both sides, you still need to build REST component for the client and server to communicate.

Thanks for reading along; I hope this Q&A has proved helpful!