Sencha Con 2013 Wrapup

July 21, 2013 1 Comment

So another great Sencha Con is over, and I’m left to reflect on everything that went on over the last few days. This time was easily the biggest and best Sencha Con that I’ve been to, with 800 people in attendance and a very high bar set by the speakers. The organization was excellent, the location fun (even if the bars don’t open until 5pm…), and the enthusiasm palpable.

I’ve made a few posts over the last few days so won’t repeat the content here – if you want to see what else happened check these out too:

What I will do though is repeat my invitation to take a look at what we’re doing with JavaScript at C3 Energy. I wrote up a quick post about it yesterday and would love to hear from you – whether you’re at Sencha Con or not.

Now on to some general thoughts.

Content

There was a large range in the technical difficulty of the content, with perhaps a slightly stronger skew up the difficulty chain compared to previous events. This is a good thing, though there’s probably still room for more advanced content. Having been there before though, I know how hard it is to pitch that right so that everyone enjoys and gets value of out it.

The biggest challenge for me was the sheer number of tracks – at any one time there would be seven talks happening simultaneously, two or three of which I’d really want to watch. Personally I’d really love it if the hackathon was dropped in favor of a third day of sessions, with a shift down to 4-5 tracks. I’m sure there’s a cost implication to that, but it’s worth thinking about.

Videos

There were cameras set up in at least the main hall on the first day, but I didn’t see any on day 2. I did overhear that the video streams were being recorded directly from what was being shown on the projectors, with the audio recorded separately. If that’s true I’d guess it would make editing a bit easier so maybe that’ll means a quick release.

Naturally, take this with a pinch of salt until the official announcement comes out. In the meantime, there’s at least one video available so far:

Grgur lets off some steam

Grgur lets off some steam

Fun Things

The community pavilion was a great idea, and served as the perfect space for attendees with hang out away from the other rascals running around the hotel. Coffee and snacks were available whenever I needed them, and there was plenty of seating to chill out in.

I missed out on the visit to the theme park, which I hear was by far the most fun part of the event. Having a theme park kick out everyone but Sencha Con attendees while serving copious amounts of alcohol seemed to go down very well with the attendees!

Unconference

I had been hoping to give a presentation on the new C3UI framework at the unconference, but unfortunately there were no projectors available at that part of the event. My outrageous presentation style tends to require a projector and a stage to stomp around on so that was a no-go for me.

Maybe next time a lightning talk track alongside the unconference would be a good addition. So long as there is a projector 🙂

All in all, what a fantastic event. Can’t wait for next year.

Filed under extjs, senchacon, touch Tagged with , , , , ,

Sencha Con Attendees: I Need You

July 19, 2013 2 Comments

Love working with Sencha frameworks? Want to come work with me on the next generation? I moved on to C3 Energy about a year ago, where we are busily building the operating system for the largest machine ever conceived by humans – the Smart Grid.

The Smart Grid is an amazing concept that’s being rolled out right now. C3 Energy is the only company in existence that addresses the full stack of Smart Grid architecture – from generation through transmission and end-user consumption.

But what’s that got to do with JavaScript? Well, my team gets to work on building the UI that powers everything that happens on the smart grid. We have some unique requirements that have led us to write our own beautiful little framework, optimized for end-user performance and developer productivity. Naturally, this leaves me feeling like this:

Success Kid

We’re a small (70 person) company of exceptionally talented people. We have a staggeringly successful collection of people both on the board and as the executive team.

We’d like to attract more people like us, and the Sencha community is the perfect place to look – especially given how much the framework has been inspired by what I helped create at Sencha.

If you’re intrigued but don’t know much about this space, I can’t recommend this video enough. This is a presentation our CEO Tom Siebel gave a few months back, introducing why the company exists, which problems it’s solving, and why we’re doing what we’re doing. If you can watch this without getting excited, this probably isn’t for you 🙂

siebs

You’ll get to work alongside people like this every day at C3. It’s really an incomparable feeling, and I’d love to introduce you to it. If you’re interested in finding out more in a low pressure way, drop me a comment or a tweet (@edspencer) or come grab me so I can buy you a beer.

Filed under senchacon

Sencha Con 2013: Ext JS Performance tips

July 19, 2013 10 Comments

Just as with Jacky’s session, I didn’t plan on making a separate post about this, but again the content was so good and I ended up taking so many notes that it also warrants its own space. To save myself from early carpal tunnel syndrome I’m going to leave this one in more of a bullet point format.

Nige

Ext JS has been getting more flexible with each release. You can do many more things with it these days than you used to be able to, but there has been a performance cost associated with that. In many cases this performance degradation is down to the way the framework is being used, as opposed to a fundamental problem with the framework itself.

There’s a whole bunch of things that you can do to dramatically speed up the performance of an app you’re not happy with, and Nige “Animal” White took us through them this morning. Here’s what I was able to write down in time:

Slow things

Nige identified three of the top causes of sluggish apps, which we’ll go through one by one:

  • Network latency
  • JS execution
  • Layout activity

Network latency:

  • Bad ux – got to stare at blank screen for a while
  • Use Sencha Command to build the app – single file, minimized
  • 4810ms vs 352ms = dynamic loading vs built

JavaScript execution:

  • Avoid slow JS engines (he says with a wry smile)
  • Optimize repeated code – for loops should be tight, cache variables outside
  • Ideally, don’t do any processing at render time
  • Minimize function calls
  • Lazily instantiate items
  • Use the PageAnalyzer (in the Ext JS SDK examples folder) to benchmark your applications
  • Start Chrome with –enable-benchmarking to get much more accurate timing information out of the browser

Layouts

Suspend store events when adding/removing many records. Otherwise we’re going to get a full Ext JS layout pass for each modification

 grid.store.suspendEvents();
 //do lots of updating
 grid.store.resumeEvents();
 grid.view.refresh()

Ditto on trees (they’re the same as grids)
Coalesce multiple layouts. If you’re adding/removing a bunch of Components in a single go, do it like this:

 Ext.suspendLayouts();
 //do a bunch of UI updates
 Ext.resumeLayouts(true);

Container#add accepts an array of items, which is faster than iterating over that array yourself and calling .add for each one. Avoid layout constraints where possible – in box layouts, align: ‘stretchmax’ is slow because it has to do multiple layout runs. Avoid minHeight, maxHeight, minWidth, maxWidth if possible

At startup:

  • Embed initialization data inside the HTML if possible – avoids AJAX requests
  • Configure the entire layout in one shot using that data
  • Do not make multiple Ajax requests, and build the layout in response

Use the ‘idle’ event

  • Similar to the AnimationQueue
  • Ext.globalEvents.on(‘idle’, myFunction) – called once a big layout/repaint run has finished
  • Using the idle listener sometimes preferable to setTimeout(myFunction, 1), because it’s synchronous in the same repaint cycle. The setTimeout approach means the repaint happens, then your code is called. If your code itself requires a repaint, that means you’ll have 2 repaints in setTimeout vs 1 in on.(‘idle’)

Reduce layout depth

Big problem – overnesting. People very often do this with grids:

{
    xtype: 'tabpanel',
    items: [
        {
            title: 'Results',
            items: {
                xtype: 'grid'
            }
        }
    ]
}

Better:

{
    xtype: 'tabpanel',
    items: {
        title: 'Results',
        xtype: 'grid'
    }
}

This is important because redundant components still cost CPU and memory. Everything is a Component now – panel headers, icons, etc etc. Can be constructing more Components than you realize. Much more flexible, but easy to abuse

Lazy Instantiation

New plugin at https://gist.github.com/ExtAnimal/c93148f5194f2a232464

{
    xtype: 'tabpanel',
    ptype: 'lazyitems',
    items: {
        title: 'Results',
        xtype: 'grid'
    }
}

Overall impact

On a real life large example contributed by a Sencha customer:

Bad practices: 5187ms (IE8)
Good practices: 1813ms (IE8)
1300ms vs 550ms on Chrome (same example)

Colossal impact on the Ext.suspendLayout example – 4700ms vs 100ms on Chrome

Summary

This is definitely a talk you’ll want to watch when they go online. It was absolutely brimming with content and the advice comes straight from the horse’s mouth. Nige did a great job presenting, and reminded us that performance is a shared responsibility – the framework is getting faster as time goes by, but we the developers need to do our share too to make sure it stays fast.

Filed under extjs, javascript, senchacon Tagged with , , ,

Sencha Con 2013: Fastbook

July 19, 2013 9 Comments

I didn’t plan on writing a post purely on Fastbook, but Jacky’s presentation just now was so good I felt it needed one. If you haven’t seen Fastbook yet, it is Sencha’s answer to the (over reported) comments by Zuckerburg that using HTML5 for Facebook’s mobile app was a mistake.

Jacky on stage

After those comments there was a lot of debate around whether HTML5 is ready for the big time. Plenty of opinions were thrown around, but not all based on evidence. Jacky was curious about why Facebook’s old app was so slow, and wondered if he could use the same technologies to achieve a much better result. To say he was successful would be a spectacular understatement – Fastbook absolutely flies.

Performance can be hard to describe in words, so Sencha released this video that demonstrates the HTML5 Fastbook app against the new native Facebook apps. As you can see, not only is the HTML5 version at least as fast and fluid as the native versions, in several cases it’s actually significantly better (especially on Android).

Challenges

The biggest challenge here is dynamically loading and scrolling large quantities of data while presenting a 60fps experience to the user. 60fps means you have just 16.7ms per frame to do everything, which is a hugely tall order on a CPU and memory constrained mobile device.

The way to achieve this is to treat the page as an app rather than a traditional web page. This means we need to be a lot more proactive in managing how and when things are rendered – something that traditionally has been in the domain of the browser’s own rendering and layout engines. Thankfully, the framework will do all of this for you.

As an example, Jacky loaded up Gmail’s web app and showed what happens when you scroll a long way down your inbox. The more you scroll, the more divs are added to the document (one new div per message). Each div contains a bunch of child elements too, so we’re adding maybe a dozen or so nodes to our DOM tree per message.

The problem with this is that as the DOM tree gets larger and larger, everything slows down. You could see the inspector showing slower and slower layout recalculations, making the app sluggish.

The solution is to recycle DOM nodes once they’re no longer visible. In this way, a list that seems to have infinite content could contain only say 10 elements – just enough to fill the screen. Once you scroll down the list, DOM nodes that scrolled off the top are detached, updated with new data and placed at the bottom of the list. Simple. Ingenius. Beautiful.

Prioritization

There’s usually a lot more going on in an app than just animating a scrolling view though. There’s data to load via AJAX, images to load, compositing, processing, and whatever else your app needs to do. And then there are touch events, which need to feel perfectly responsive at all times, even while all of this is going on.

To make this sane and manageable, we have a new class called AnimationQueue. All of the jobs I just mentioned above – handling touch events, animation, network requests and so on – are dispatched through the AnimationQueue with a given priority. Touch event handling has the top priority, followed by animation, followed by everything else.

AnimationQueue does as much as it can in that 16.7ms window, then breaks execution again to allow the browser to reflow/repaint/whatever else it needs to do. What this means is that while scrolling down a large list, it’s likely that our CPU/GPU is being taxed so much that we don’t have any time to load images or other low priority jobs.

This is a Good Thing, because if we’re scrolling through a large list there’s a good chance we are going to skip right over those images anyway. In the end they’re loaded as soon as the AnimationQueue has some spare time, which is normally when your scrolling of the list has slowed down or stopped.

Sandboxing

The final, and most complex technique Jacky discussed was Sandboxing. The larger your application gets, the larger the DOM tree. Even if you are using best practices, there’s an expense to simply having so many components on the same page. The bottleneck here is in the browser itself – looks like we need another hack.

To get around this, we can dynamically create iframes that contain parts of our DOM tree. This way our main page DOM tree can remain small but we can still have a huge application. This not only speeds up browser repaint and reflow, it also improves compositing performance, DOM querying and more.

This all happens under the covers and Jacky’s aiming on including Ext.Sandbox in Sencha Touch 2.3 so that all apps can take advantage of this huge improvement. He cautioned (rightly) that it’ll only make 2.3 if it’s up to his high standards though, so watch this space.

Filed under senchacon, touch Tagged with , , , , , , , , , ,

Sencha Con 2013 Day 1

July 18, 2013 7 Comments

Sencha Con 2013 kicked off today, with some stunning improvements demoed across the product set. I’m attending as an audience member for the first time so thought I’d share how things look from the cheap seats.

Keynote

The keynote was very well put together, with none of the AV issues that plagued us last year (maybe they seemed worse from behind the curtain!). It started off with a welcome from Paul Kopacki, followed by some insights into the current status of developers in the world of business (apparently we’re kingmakers – who knew!). One of Blackberry’s evangelists came up and made a pretty good pitch for giving them a second look (the free hardware probably helped a little…)

The meat, though, was in the second half of the presentation. We were treated to a succession of great new features across Ext JS, Sencha Touch and Sencha Architect, which I’ll go into in a little more detail below.

But it was Abe Elias and Jacky Nguyen who stole the show in the end. Unleashing a visionary new product, Sencha Space, they demonstrated a brand new way to enable businesses to elegantly solve the problem of BYOD (Bring Your Own Device).

Nobody wants to be given a mobile phone by their IT department when they’ve got a brand new iPhone in their pocket. But those IT guys have good reason for doing this – consumer browsers are currently inherently insecure. Sencha Space solves this problem by providing a single app that employees can install, log in to and gain access to all of the apps needed to be productive in the company.

I could write a lot more about it but the 2 minute video below can surely do a better job:

Ext JS upgrades

The keynote lasted most of the morning, but in the afternoon Don Griffin came back on stage to tell us more about what’s coming soon in Ext JS. Don heads up Ext JS these days, and is one of the most intelligent and experienced people I’ve had the joy of working with. I’m pretty sure he gained the largest amount of spontaneous applause of the day during the Ext JS talk, which is no surprise given the awesome stuff he showed us.

I forget which order things were revealed in, but these things stood out for me:

  • Touch Support – while this may seem anathema to the thinking behind Ext JS, it’s an undeniable fact that people try to use Ext JS applications on tablets. Whether they should or not is a different question, but in this next release it will be officially supported by the framework. Momentum scrolling, pinch to zoom and dragdrop resizing are all supported at your fingertips.
  • Grid Gadgets – quite likely the coolest new feature, Gadgets allow you to render any Component into each cell in a Grid, in an extremely CPU and memory efficient manner. Seeing a live grid updating with rich charts and other widgets at high frequency was a fantastic experience
  • Border Layout – allows your users to rearrange the border layouts used in your apps with drag and drop. Easy to switch between accordion layout, box layout or tabs
  • A shedload more. The enforced pub crawl has temporarily relieved me of a full memory. So impressed with everything that was demonstrated today.

Sencha Touch upgrades

Jacky came up and delivered a presentation on what’s coming up in Sencha Touch, using his idiosyncratic and inimitable style. Some of the things that stood out for me:

  • Touch gets a grid. It performs really well and looks great. Good for (sparing) use on tablet apps
  • XML configs. Not sure how I feel about this yet, but ST 2.3 will allow for views to be declared in XML, which is transformed into the normal JSON format under the covers. You end up writing few lines of code, but the overall file size probably doesn’t change too much. With a decent editor the syntax highlighting definitely makes the View code easier to read though
  • ViewModel. Just as we have Ext.data.Model for encapsulating data models, we now have ViewModel for encapsulating a view model, which includes things like state. Leads to a much improved API for updating Views in response to other changes
  • Theming. 2 additional themes were added, and the others have all been refactored to make theming even easier

Again there’s a lot more here and I couldn’t possibly do it all justice in a blog post. It’s geniunely thrilling to see these young frameworks mature into stellar products that are being used by literally millions of developers. Very exciting.

Architect upgrades

Architect has come a really long way since its inception a couple of years ago. The new features introduced today looked like some of the largest steps forward the product has ever taken. I’m finally getting close to actually thinking about using it in real life (I’m a glutten for editing code in Sublime Text). Some standout features:

  • New template apps to get you up and running with a new app in seconds
  • Integration with Appurify, which allows you to test your Architect apps on real devices hosted by their service
  • Allows you to install third party extensions into Architect, and have them seamlessly integrated into your project

Day 1 Summary

Although I worked with these people for years, somehow I’m still surprised when I see every single developer giving world class presentations. I don’t know how I was able to leave Sencha a year ago, but every time I interact with Abe, Don, Jacky, Tommy, Jamie, Rob, Nige, and all of the other rockstars at that place I’m reminded what a great and unique time that was. Really looking forward to what tomorrow brings!

Filed under extjs, senchacon, touch

%d bloggers like this: