Today’s the first day of actual talks at SenchaCon. This post, and tomorrow’s post, will mostly be notes I take during the talks. I’ll post an analysis at the end of the conference.

Keynote

Sencha’s CEO was up first, talking about their vision for where Sencha is going. He highlighted three big trends they’re riding: mobile, sharing, and HTML5. He pointed out that desktop sales have been flat now for some time but the mobile platforms (smartphones, tablets and even laptops) have been growing exponentially over the same time period. He says that sharing has become a core feature of apps these days; people expect it, and it’s strange for an app to not have sharing.

Google talked about Chrome’s role in revitalizing the development of web technologies, and especially about the Chromebook. One very interesting thing they pointed out was that there’s a huge interest in Chromebooks from businesses and government. These organizations are very interested in them because they’re stateless, which reduces administrative costs, and because many employees basically spend all their time in web browsers anyways.

Jarvus Innovations demoed their custom t-shirt printing site which uses Ext.JS.

Juniper also talked about their “Junos Space” platform, which uses Ext.JS. It also lets application developers create custom, hosted, applications using Ext.JS.

Sencha’s big vision for the future is that web technologies are going to take over app development, and expand into other devices. A big device they talked about is in-car dashboard apps that integrate with apps on other devices and use platform-specific sensors like gas levels. Maybe they’ve got something in the works here that they’re not talking about?

Introducing Sencha Touch 2

Performance

The big focus in Sencha Touch 2 is performance. They claim improvements of 10-30% in startup time vs 1.1. It also has a new layout engine which uses the browser’s CSS engine to lay out the components rather than laying them out via Javascript. This new engine improves layout performance; they showed a video where it does a re-layout of the kitchen sink app in 0.35s vs 0.98s. At that point, they say, the phone’s layout animation is the limiting factor.

They also improved interaction performance by using ‘selective use of CSS3 transforms’ to eliminate flicker, etc.

Sencha Touch 2 uses CSS-based layouts so Javascript doesn’t get invoked to layout the components. This means that the layout process is asynchronous and not dependant on the Javascript runtime. It’s also smarter about re-using DOM elements especially for lists, since creating DOM objects is very expensive. Doing this manually is a large part of how you improve the performance of a Sencha application, and now this is (hopefully) all done by Sencha Touch automatically.

Other improvements

They also say they’ve improved their internal processes a lot, adding a QA team and code review process. They’ve also made much-needed improvements to their documentation and learning materials.

Q&A

Here’s a few of the questions that were asked. There were a couple others that I either missed or didn’t find interesting. I found in this talk that the speakers tended to talk around the question and never answer it unfortunately.

• How does Sencha support multiple devices? Speaker mostly dodged the question.
• Has Sencha fixed problems where, during keyboard input, the viewport turns into a sliver? Yes, the new layout engine in 2.0 should be more correct because it uses CSS for layout.
• What’s the difference between PhoneGap and Project “Ion”? Ion will have good continuous integration support, etc.

Introducing Designer 2

Designer is turning from a visual layout designer, kind of like Interface Builder for Cocoa / Cocoa Touch pre-XCode 4, into an integrated development environment with a layout designer. I’m seeing it turning into something more like Expression Studio. It includes a code editor for inserting code into event handlers, generators for MVC components, source control integration, and native deployment (to the Apple App Store, or the Android market). Designer 2 also includes support for Sencha Touch; the current stable release only supports Ext.JS.

Q&A

This session had a longer Q&A session that had some interesting questions.

• Will Designer support generating MVC stubs? Designer will fully support MVC, but it isn’t quite there yet.
• What unit testing frameworks does Sencha support? Sencha uses Jasmine internally, but doesn’t really recommend any in particular.
• Why is Sencha creating an IDE instead of integrating with Visual Studio or Eclipse? They did not want to rely on the release schedule of a third party, and like to develop their platform all internally. They said they do plan on integrating with Eclipse, but didn’t give details.
• Will Designer support custom theming and custom templates? Yes, it’s in the roadmap but they’re “focusing on the basics” right now.
• If I have an existing application not developed in Designer, will Designer be able to open it? No, Designer has a specific filesystem layout it uses. Because every project has its code structured differently. They recommend developing it again, from scratch, in Designer. (Aside: This was a common thread in a few talks. Sencha doesn’t really allow forward-porting of applications from previous versions of their frameworks. They assume that all projects are either greenfield or will stick with an earlier version of the framework.)
• Does Designer support Ext.JS 3.x? No, you should be moving to Ext.JS 4.

MVC in depth

These talks were a rapid-fire tour through MVC in Sencha Touch and Ext.JS. Honestly, I missed a few parts, but I think I captured the most important bits.

Part 1

Why use MVC in Sencha? By applying a standard application structure you can keep things organized, prevent spaghetti code, and allow collaboration between developers.

Sencha’s implementation of MVC also includes a standard directory layout that’s similar to Rails with controllers in MyApp/app/controllers, models in MyApp/app/models, etc.

Overall, Sencha’s implementation of MVC is fairly standard. The most interesting part is the controller which is bound to the view using “component queries” to get references to objects on the view using CSS selectors, then lazy binding to bind to their events (more on this below).

Part 2

Biggest difference between most MVC implementations on the web (e.g. Rails, Django, etc.) is that in server-side MVC the actions are based on pages, whereas Sencha’s client-side MVC actions are based on user actions.

It’s an event-based model where controllers bind to view events like so:

this.control ({
  'contact-listpanel': {
      activate: this.onListActivate
  },

  'contact-listpanel > list': {
      select: this.onListSelect
  },

  'button[action=addcontact]': {
    tap: this.onAddButtonTap
  }
});

This snippet of code, from a controller’s init method, binds to the activate, select, and tap events of their respective components. Bindings are lazy, similar to the jQuery’s ‘.live()’ method, where event bindings apply to DOM elements created now and in the future. You declare that you’re interested in an event, and if a control appears at some point that matches a query, you will be bound to it.

Sencha uses an “Event Bus” model for dispatching events. When an event is fired, its controller dispatches an event to the application object:

this.application.fireEvent(‘stationstart’, context);

Then someone else can bind to the ‘stationstart’ event and do an action when it occurs.

In Sencha Touch 2.0, the initialization process is a two-phase process:

- Application: init - All controllers: init - Application: launch - All controllers: launch

The init methods should do all the event binding, whereas the launch methods should do the rest of the initialization (creating views, loading data from stores, etc).

Using Node.js with Sencha Technologies

Rationale for server-side Javascript: using Javascript everywhere means fewer context switches for developers. It also allows code portability between the client and the server.

Node.js is Google’s v8 Javascript engine (same as Chrome uses) with I/O libraries on top. All I/O is non-blocking (aka. “evented”).

Craig implemented a Node.js module called node-extjs which lets you use Ext.js or Sencha Touch’s MVC architecture on the server-side. This allows code to be shared between the client and the server, such as models with validations that exist on both the client and the server.

There’s also three projects to blur the difference between clients and servers: now, dnode, hook.io. now is the most interesting. It lets the client invoke methods on the server via a function call, or vice versa, via WebSockets.

Q&A

• What about debugging node programs? There’s a package called “node-inspector” that’s like Web Inspector for introspecting node applications.
• Does node-extjs use Ext.JS’s loader mechanism? Yes, it does.
• How does CouchDB compare to other NoSQL databases? CouchDB is very simple and all Javascript-based (Aside: not quite — it’s implemented in Erlang, but he’s right that all the extension points are Javascript). MongoDB is very good, but there’s no Ext.JS integration for it.

Sencha.io

Sencha.io has three core services: Login, Data, Messages.

Login

Provides authentication, registration (both via a standard form, and via an API), etc. Allows user groups, and searching by properties (including custom properties).

Data

Data is replicated locally on devices and synchronized to the cloud. Data can be shared between users to allow collaboration. Data can be updated while offline, and will be synced automatically when connectivity is restored. Only the user’s individual data is stored on the device.

This of course opens the door for inconsistencies. Sencha.io allows collisions, then uses a conflict resolution. When a property is set to two values independently, then it uses a timestamp to determine the winner.

He called this a ‘timestamp’ first then later clarified that it’s not an actual time. But, he didn’t go into details. I suspect he means that it uses a vector clock or MVCC, but that’s speculation and doesn’t answer how they resolve conflicts. He didn’t mention any manual mechanism for pushing conflict resolution up to the application like Riak does.

Messages

Allows device-to-device communication, either one-to-one or one-to-many. Offline messaging is a core feature, so messages are queued up while offline and delivered later.

Has a couple different protocols for client-server communication, including the default polling one and an asynchronous push one. He seemed to say that it uses different ones in different situations.

Messaging models supported:

• Service requests (request-response, or RPC)
• Broadcasting data (one sender, many recipients)
• Collecting data (many senders, one recipient)

Messages are just JSON blobs. The one-to-many messaging reminds me of AMQP with message queues and brokers.

Q&A

• Is data encrypted? No, except authentication.
• Can we access data using SQL, etc.? No.
• Can you use social network logins for the Login service? Yes. It also supports third-party authentication providers.
• Asked by me: Can you replicate shared data on the devices? Yes.
• What’s the business model? Free for now. There will be some sort of ‘enterprise tier’ later that will be paid.
• Will Sencha.io support Ext.JS? Yes, eventually. It actually works right now, by accident. Official support will come soon.
• How are devices uniquely identified since UDIDs change? They put a random number into local storage. Of course this can be deleted, in which case it’ll appear as a new device. Devices are bound to users, so if data is stored in the user object, then it’ll appear on whatever device they use. This only would be a problem for anonymous users.
• (Did not hear question) Sencha will re-write HTML files to point references to sencha-touch.js to a CDN so it loads faster. It also ships device-specific code, or do other tricks (e.g. progressive loading).
• Can you inspect the device’s queues to figure out when messages aren’t being delivered? Yes, there will be a console / other debugging tools.
• How fast is message delivery? Does it support real-time? In the asynchronous push delivery, latency will be about the same as the network latency. For the polling delivery it will depend on the polling policy.