Why Lavaca is the only sane HTML5 mobile development framework out there (and why Sencha Touch sucks)

A few weeks ago I found myself on a journey to find the best go-to framework for HTML5 mobile development. The objective: develop a cross-platform mobile version of an online digital store. Having some (extremely frustrating and negative) experience with Sencha Touch, and having an overwhelming desire to avoid being put in a situation where I’m swearing at my screen at 3am while going through painful, agonising debug sessions of the Sencha Touch core I was determined to find a better alternative.

Quite honestly, I was surprised by the amount of junk out there. Most mobile HTML5 platforms I found were either obviously outdated (showing off screenshots of “native widgets” from iOS 5.0 era sporting an iPhone 3GS, and ancient Android design atrocities that will remain unidentified), or tried to reinvent the wheel. That is until I found Lavaca.

Before explaining why Lavaca is great, I’d like to elaborate just a tiny bit on why Sencha Touch or jQuery Mobile (the two “kings” of mobile HTML5 at the time of writing this post) aren’t.

The main problems I experienced with Sencha Touch:

  • Size (1mb+ compressed for just the framework), which means that whatever you do, however big or small your app is, the user will have to download at least 1mb of stuff onto their phone. I know that theoretically mobile speeds are always increasing, but 1mb?!
  • Reinventing the wheel (which is the reason Sencha is so fat): there’s nothing about Sencha Touch that even closely resembles JavaScript. It’s like they had no choice but to use JavaScript, but they hate it’s guts, so they rewrote the whole freaking thing. Honestly, in 100 lines of Sencha code, you’d be troubled to find even 10 lines of pure JavaScript that just makes sense. Everything depends on everything, hence the big loading size. Loading Sencha, you’re basically loading a whole new programming language.
  • There are 50 ways to do the same thing, of which 40 aren’t documented, and 3 are really the right way to do it (all of them undocumented) .. which coupled with reinventing the wheel makes it impossible to do anything without acquiring the need for anger management courses.

[edit] To anyone saying that Sencha is the best thing since sliced bread, and I’m just missing out on the wonders of it, I would write up a long rant, but someone already did it for me: https://gist.github.com/cinsoft/3279190 [/edit]

jQuery Mobile seems to fare a bit better on the size, and consistency issues. But it seems to be a bit confused at what it is trying to offer. On one hand, it’s trying to be minimalistic – so it lacks features. On the other hand, it is trying to cover lots of ground when it comes to widgets, ui components, cross platform themes e.t.c

Here’s where Lavaca make sense of all this:

  • Size: my whole app, before any optimisation, including all the lavaca components weighed less than 200kb. That’s extremely lightweight, and I believe I could cut off considerable parts of it. This is very important for a mobile app.
  • Embracing existing standards rather than ignoring them (in other words, not reinventing the wheel): In a way, Lavaca is more of a toolkit than a framework. It loosely couples a number of existing open source projects (requirejs, cordova, backbone, jquery e.t.c) into a development workflow that makes sense, speeds up development while providing an excellent minimalistic framework for app development on top of it all- it’s quite a refreshing feeling when you can write code in actual JavaScript , and rely on existing, proven and mature tools for your workflow. Rather than ignoring all the existing trends in HTML5 and JavaScript world, Lavaca embraces them, using them to the fullest extent.
  • Modular approach: Since the framework is very loosely coupled, you can very easily replace, modify or completely remove entire sections of it. Your’e not forced to use any of the components, and you’re free to rewrite any part to suit the needs of your application.

Of course, not all is perfect with Lavaca. The project is still pretty young, and even though it’s at version 2+, the documentation could be a bit more detailed. There is still practically no community around the project, and most times you would be on your own if you encounter a bug. I wouldn’t recommend you to dive into this one unless you have some experience with JavaScript, HTML5, MVC and complex app development in general. However, the embracing of existing tools and the straightforward and logical approach to it all make it super easy to figure things out.

In future posts, I’ll try to cover subjects in Lavaca development not mentioned on their website, and overlooked by the documentation, so stay tuned.

You can check Lavaca out right here:

  • Arthur Kay

    I’ve got a clear bias towards Sencha’s products, but I need to clear up some false statements in this post.

    (1) Sencha Touch doesn’t weigh 1MB – are you including examples, documentation and ALL of the themes? If you’re using the framework correctly, it loads only the required JS dependencies. Going the extra mile to use Sencha Cmd, you can minify your application build dramatically. This is all clearly mentioned in the Sencha documentation, and there are user guides (in the docs) explaining how to do this.

    (2) “there’s nothing about Sencha Touch that even closely resembles JavaScript” is complete garbage. The framework *IS WRITTEN* in JavaScript, and if you’ve ever looked at the source code it’s pretty easy to follow. Sencha Touch does use a “class system” – but it’s generally easy to understand.

    I can appreciate that Sencha Touch has a learning curve which isn’t trivial, and I understand that you’re frustrated with that. That doesn’t mean it sucks… in fact, your comments about JQM being minimalistic and Lavaca being imperfect lend credence to the argument that Sencha Touch is one of the better (best?) choices for building an HTML5 mobile app. Is it perfect? No, but again it doesn’t suck.

    I also find it interesting you rag on Sencha Touch for documentation bugs, yet you say the non-existent community and things “overlooked” in the Lavaca docs are basically fine with you. You can’t play both sides of the coin on that point.

  • Francesco Belladonna

    @arthurkay:disqus: Well, actually I understand his feeling. I’ve never written code with Sencha Touch or JQuery Mobile, but I DO have written code with ExtJS. And I felt completely in the same way: there are thousands of ways to do the same thing, only 2-3 are correct and all of them are NOT documented. I written a rather big project with it, and I finally (once concluded) that it would be a maintenance nightmare keeping ExtJS, so I removed and rewritten the UI entirely.

    They have beautiful presentation for the documentation, however it’s not true that it’s well documented, they have GREAT UI widgets, but once you want to implement something that inherit from them/expand them do something similar, you are left alone. You loose the ability to directly write in html, making basically all your knowledge useless.

    And yea I found myself in the same situation: I had to debug for long nights, the CORE of ExtJS.

    Yea, I believe the post can’t be misunderstood but really, the strange part of facing the same issue as the OP for a different library from the same company, make me think that there may be an issue with it.

  • israelidanny

    Arthur Kay – First of all, thanks for reading and sharing some of your thoughts, that’s greatly appreciated. It’s nice to hear a different angle from a Sencha Touch enthusiast ;) Quite honestly, I was very enthusiastic about Sencha Touch until I had to face all those late nights debugging it’s core, just like Francesco Belladonna.

    Regarding the documentation, the size, and the re-definition of programming paradigms – I think they’re all connected. Cruising through Sencha documentation feels a lot like going through a Java framework documentation. Many paradigms are borrowed from that world. The way the class system is set up, the interfaces, inheritance e.t.c. On top of that you also have a lot of different things tailored specifically for the framework (extending via xtype object notation, the way the event system works e.t.c).

    You end up having to learn a lot of paradigms and techniques that are completely unique to Sencha Touch, and of very little use outside of it.

    In fact, most times when I would have some problem with Sencha Touch, I would trace it back to the core that I would debug and have to patch. I spent countless nights patching up problems, or debugging my app for hours only to find that some known core bug is causing the completely cryptic error messages I’m getting.

    In contrast to all this, Lavaca doesn’t try to change the way you think about Javascript, but rather rides on top of existing, well documented tools where possible (such as RequireJS, Dust, Grunt, e.t.c). So in a way, it’s MUCH easier to deal with problems (while Lavaca is only generally documented, it doesn’t re-invent the wheel , and you can easily find any solution to most problems within the larger Javascript community). 90% of my misunderstandings with Lavaca were solved in a short 20 minute debug session, and a look-up of how one of the existing, widely adopted tools worked. 90% of my misunderstandings with Sencha ended up with long nights trying to dig out the problem because of how vastly Sencha differs in it’s architecture from most of what’s out there in the JS world.

    • Arthur Kay

      “You end up having to learn a lot of paradigms and techniques that are completely unique to Sencha Touch, and of very little use outside of it.” That’s an interesting take on your experience with the Sencha frameworks. I can agree that our *syntax* isn’t replicated in the greater JavaScript world, but it’s honestly a pattern you see in *every other* programming library. Perhaps this is magnified by the fact Sencha Touch (and Ext JS) are bigger, more encompassing frameworks – but this really isn’t anything new. As a JavaScript developer, I’m come to assume that my base knowledge of the language isn’t used all that much by any framework. Looking at most of the jQuery code I’ve seen written in my lifetime, I can tell you I’ve seen very little “actual JavaScript” being used.

      “I spent countless nights patching up problems, or debugging my app for hours only to find that some known core bug is causing the completely cryptic error messages I’m getting.” Are you suggesting that Sencha Touch has core bugs which prevent (presumably) average apps from functioning? I’ll agree that it’s frustrating when an error is caught deep in the core framework, but 99% of the time it’s the result of a simple configuration error. The key for Sencha is finding ways to clarify the documentation and streamline the learning curve (and perhaps having better error messages) – but I think it’s unfair to paint the framework as generally buggy when that’s not the case.

      If I can put words into your mouth, I would sum up your post (and follow-up comments) as “I had a hell of time learning and debugging an app built with Sencha Touch”. That’s a fair assessment (if accurate), one I can’t argue against much. On the other hand, Sencha has a HUGE community plus paid support – did you make use of those channels while you were up late on those countless nights?

      “90% of my misunderstandings with Sencha ended up with long nights trying to dig out the problem because of how vastly Sencha differs in it’s architecture from most of what’s out there in the JS world.” Again, a fair statement. To be more fair, a LOT of what’s popular now in the JS world didn’t exist when Sencha Touch was first released. While I am *clearly biased*, I’ll suggest that some of Sencha’s tools are better than what’s available elsewhere. Perhaps we can agree to disagree ;-)

      • http://www.povolotski.me/ Danny Povolotski

        “Sencha has a HUGE community plus paid support – did you make use of those channels while you were up late on those countless nights?” – I haven’t tried out the paid support, – but I did plug in quite a bit into the community.

        I think that what you see as maturity and good feature covering, I end up seeing as bloat – perhaps a good direction for Sencha could be to introduce even more modularity?

        However, our discussion here sparked an interest in me to dedicate some time to a more scientific comparison of various frameworks. Most things I find are a bit outdated, and I’m interested to compare size / intended use / performance between various frameworks out there.

        • http://www.mitchellsimoens.com/ Mitchell Simoens

          I think the word “bloat” is very bad word to use here. Bloat means that there is stuff present that is not needed. If you use a build file that contains all classes in Sencha Touch (or Ext JS) then some of that is bloat for your application. But, as Art has said and what you said you will be trying out, using Sencha Cmd you can build only what you want for your app removing much of the “bloat”. Just don’t agree with the word choice.

          • http://www.povolotski.me/ Danny Povolotski

            Fair enough. Would you agree, though, that it would be fair to expect two apps of similar functionality (say, tabs, forms) to be comparable in size? .. What would your expectation be, as far as modularity and compression go, of the size of a simple two tab app, with static html, and a form. This is the experiment I want to make in a few different frameworks. Seems to me like a fair comparison, isn’t it?

            I don’t see why modularity, if it really exists in Sencha, shouldn’t bring the apps to very similar sizes. If then, Sencha Touch would still be WAY larger than any other framework – would you agree there is some level of bloat?

          • http://www.mitchellsimoens.com/ Mitchell Simoens

            Actually, no I wouldn’t expect the size to be similar. Again, Sencha Touch does so much more the Lavaca so it’s not a fair apples to apples comparison. Sencha Touch is setup to handle more complex apps so having an app with just a form Sencha Touch may not be the right thing to use. Another analogy, say you have a small screw to screw in and handle in a cabinet. A drill may not be the right tool to use when a screw driver is the right tool. A drill is setup to handle a larger task.

          • http://www.povolotski.me/ Danny Povolotski

            Alright, so in the case of Sencha Touch (not ExtJS), what is it exactly that it is setup to handle that’s so incredibly complex and can’t be achieved in a leaner, more agile way? Any practical examples?

          • http://www.mitchellsimoens.com/ Mitchell Simoens

            I’m not sure it’s been defined what is actually wrong with the code other than it’s “bloat”. Real feedback is always welcomed, just general statements are really hard to understand what is actually meant.

          • http://www.povolotski.me/ Danny Povolotski

            Regarding bloat, I was gonna go into a long rant, but found this instead:

          • Thomas Pilgaard Miller

            What I think Sencha Touch does extremely well is handling touch gestures. I haven’t come across anything that seems comparable components like the Carousel in terms of flexibility, responsiveness and consistency across devices. If I am simply uninformed I’d very much like to know of other solutions that work just as effortlessly as Sencha.

            I find these things to hold true for next to all aspects I’ve had to deal with in Sencha.

            I’ll go out on a limb here since I’ve only briefly glanced over the Lavaca docs and API but I haven’t really found anything that relates to touch gestures? Have I missed anything here?

          • George Henderson

            I am a Lavaca core contributor. There originally was a touch library built into Lavaca that worked with jQuery. We decided to remove library in favor of leveraging an open source project dedicated to touch gestures with a broader reach. Lavaca’s event system now works with Hammer.js’s jQuery plugin. Lavaca does not come with a built in touch carousel like Sench Touch, we recommend you build your own and then open source it :) . For one example how you might build a touch interaction in Lavaca check out David Dulak’s Lavaca touch helpers https://github.com/daviddulak/lavaca-touch-helper

          • Thomas Pilgaard Miller

            George – thanks for the reply – I appreciate it.

          • http://www.mitchellsimoens.com/ Mitchell Simoens

            I guess a big problem I have with a “library” that uses other libraries is that it can be very easy to produce spaghetti code. APIs aren’t the same and depending on someone supporting their own code is very hit and miss. Of course Sencha Touch doesn’t do everything under the sun (reason why I have so many GitHub repos) so that means I have a lot of things people use but I have a very hard time finding time to support my own code past what I use it for. This is increasingly more evident with the micro-lib activity as of late. I think it’s cool that something works well with others but get into a complex, large app and things can break down very easily.

          • http://www.povolotski.me/ Danny Povolotski

            @mitchellsimoens:disqus – That actually makes a lot of sense :) .. What’s a library that in your opinion has good balance on this issue?

          • Arthur Kay

            To be fair, most of that rant is the author complaining about Sencha’s code not matching his personal standards. You could look at anyone’s code and find something “wrong” with it by that measure. Also for the record, the author has several other gists bitching about how things “suck” (AMD, jQuery, MooTools, etc) – I don’t really know what to make of that.

          • http://www.povolotski.me/ Danny Povolotski

            Yeah, the guy is a bit of an antisocial pain :) … But I agree with his “bloat” findings (the DOM query stuff, User Agent string as opposed to feature detection,desperate attempts to use Java-style classical inheritance everywhere, cover-ups of tons of mistakes). All that takes up 1000′s of lines in Sencha.

            Also – despite everyone telling me Sencha CMD is so amazing at modularity, I haven’t been able to go any lower than 500+kb for the minified files of JUST the framework – let me know if you had any better luck – or know anyone who did.

          • Arthur Kay

            It would depend on which parts of the framework you’re including. All of the framework, minified in sencha-touch-all.js, is 671kb. The “core” of the framework, minified in sencha-touch.js, is 131kb. While I’m not claiming Sencha Touch plus your application code will quite hit the 200kb mark, the results will obviously vary depending on what’s being used.

  • http://www.povolotski.me/ Danny Povolotski

    @Arthur Kay:disqus – In my next post I’d probably do a study of the sizes of different mobile applications, any special tips / tricks on getting Sencha as skinny as possible?

    • Arthur Kay

      Yes, use Sencha Cmd! There are lots of user guides and videos/presentations in Sencha’s online docs: http://docs.sencha.com/touch/2.2.1/#!/guide

      • http://www.povolotski.me/ Danny Povolotski

        Thanks! I’m going to experiment with it, and my next post will probably be a more scientific comparison of framework sizes / performance.

  • http://www.blackwaterops.com Brandon Wirtz

    Lavaca is not really a framework. To be a framework you kind of can’t be some of the things that makes Lavaca not entirely suck. But Lavaca really only makes sense if you have users with no cache accessing your stuff via Modem. Let me explain.

    To be a framework you can’t be Modular. The whole point of a framework is it is all there, and it is always there. Because then you can cache it the same for everybody, and because everybody has it, no one has to download it so you get it for “free”.

    Ok, so a Framework can be modular, but making it so negates all the benefits of using the framework.

    It bundles things that should be frameworks in a way that doesn’t let you cache those frameworks. So all those bits of Cordova, and Jquery and backbone that Lavaca borrows from… Now you don’t have those, and they aren’t being pulled from your cache, they are being sucked down when you get Lavaca.

    Notice I said sucked down. That’s what it is. No one has Lavaca in their cache, there isn’t a universally hosted by Google version of it. Danny says why “There is still practically no community around the project” and that is why no one sane will use Lavaca.

    It sucks. It doesn’t know what it wants to be when it grows up. And it borrows from a bunch of other frameworks that do have communities. If you want your framework to get traction, suck less, steal less, have a plan, and be a cache friendly framework with really great CDN’s serving your bits.

    • http://www.povolotski.me/ Danny Povolotski

      You raised up some interesting points. From what I know, most mobile frameworks / toolkits end up minifying and uglifying themselves into one solid JS file that in some cases loads itself into some form of local cache (be it local storage, or broswer cache e.t.c). If that’s the case – wouldn’t that somehow make the whole CDN caching less relevant? Also, I wouldn’t necessarily classify borrowing functionality of other frameworks in their entirety as stealing.

      I’m not saying I completely disagree, but I’m questioning whether CDN caching is relevant in the mobile “application/site” scenario (if you package something via Cordova, you’d rarely go to CDN’s , but rather have all your JS code stored in the package).

      Also, nothing seems to prevent you from taking any CDN-hosted JS files within the package, and instead of using them within the RequireJS compiled stack – put them into the of your single-page app.

      Also – I’d like to hear your opinion of a mature, good candidate for an alternative mobile development framework / toolkit. I’m still on the search for the “Holy Grail” for HTML5 app development.

      • Will

        “Holy Grail” for HTML5 app development => AngularJS! :D just my opinion…

      • kellyrmilligan

        Just to chime in on this comment with a few clarifying points:

        - Lavaca does not contain any code from BackBone. It has functional equivalents in the form of models and collections, but has it’s own viewpoint on those.
        - With the switch to RequireJS, the workflow that comes with the starter project focuses on optimizing your project for distribution using the RequireJS optimizer, rather than having Lavaca on a CDN. A build that does only include Lavaca’s core components could be made available for this purpose.
        - Lavaca has a core framework that was made modular with the 2.0 release with RequireJS. The project also pulls in other components that can be useful when developing a single page app for mobile/responsive web as well as an app wrapped with Cordova.

  • steida

    I prefer github.com/steida/este (based on Google Closure) for mobile dev. Compiler is huge benefit. For mobile dev, you need only right css.

    • http://www.povolotski.me/ Danny Povolotski

      The website linked to in the repo seems to be down. Is there any documentation / community around it?

      • steida

        Site is here: este.jit.su I’m still waiting for domain migration :( Community is huge, whole Google, Facebook etc. :-) Este.js is Closure Library, which is maintained by Google pretty well, and my Este library, which is basically something like better Backbone + app with presenters etc., View is Facebook React, tap events is Google Polymer. So Este.js itself does not have huge community, but included projects does. My own code is here: github.com/steida/este-library

        • http://www.povolotski.me/ Danny Povolotski

          Looks neat! I will definitely check it out.

  • Will

    I don’t know, Lavaca may work for small projects but it doesn’t seem to be near the capabilities or support of Sencha/jQuery.

  • Ivan Jouikov

    This is clearly written by someone who has not taken the time needed to reach any level of proficiency in Sencha Touch. The very fact that you lump Sencha Touch to jQM shows that you don’t understand the magnitude of what you’re dealing with here.

    You expect to try Touch or ExtJS on some project and form opinion of it? I have worked with ExtJS for almost 5 years now, but I only consider myself “Journeyman” in my terms of proficiency with it. I’ve used it on many projects and learned something from each. It is a massive framework that covers many aspects of web application development, most of which you would not use on a single project.

    You go to school for years to become proficient in reading and writing. Before you make conclusions about Touch, give it some years.

    • http://www.povolotski.me/ Danny Povolotski

      I’ve been working with Touch / ExtJS for 3 years across many projects, and I had the last straw broken a few months ago.

      I think ExtJS is great for what it’s trying to be – a complete UI / App framework to duplicate desktop app experience on the web. I do, however, think that the premise of taking a mammoth that tries to replicate desktop experience on the web and port it to mobile is a poor design choice. Mobile HTML5 has to be about elegance, not about who’s the biggest behemoth that can do the most.

      Elegance and intuitiveness are important aspects of any framework. You don’t have to work with a bloated framework for 5 years to realise it’s bloated.

      • Ivan Jouikov

        I think you’re confusing a steep learning curve with framework being a hinderance.

        Yes it is easier to learn framework 200kB in size than one 1MB+ in size. Intuitiveness is nice, but lack of pre-learning curve intuitiveness, while a minus, is to be expected. Algebra is not intuitive, especially without knowledge of basic Math. If you don’t know basic Math, would you say “Algebra sucks because it’s not intuitive?” Does lack of immediate intuitiveness make it bad?

        As far as compactness goes, I restate my point – you haven’t taken the time to learn the framework. Leveraging the class system dependency and Sencha CMD command line tool, you can extract only the JS you need down to a few hundred kB.

        What you refer to as “bloat” I refer to as my toolbox. I have lots of tools, but I only use the ones I need for a job.

        • http://www.povolotski.me/ Danny Povolotski

          Ivan – I think you’re still missing what I’m saying, because I’m stating the opposite of what you’re understanding . . Sencha has INITIAL intuitiveness, and seems very agile, but ends up being inflexible and very different in it’s paradigm than 90% of the current Javascript world after going a bit deeper.

          On the other hand, modular, lightweight, frameworks that are more up-to-date with current programming paradigms seem a bit limiting at first because “not everything is included”, but once you get over a few basics – you end up skyrocketing.

          I don’t mind initial learning curves, I do mind flexibility “walls”.

          Again, I could be wrong – yours, and some other comments sparked my interest, and I’m working on a different approach of comparison for mobile frameworks. I’ll gladly have you look at my code for a sample Sencha App once I go forward with it.

  • http://www.mitchellsimoens.com/ Mitchell Simoens

    I’m sorry but there is no way to compare Lavaca to Sencha Touch. Of course Lavaca is going to be smaller in size, it’s does a small sliver what Sencha Touch can do. Lavaca has ~45 classes listed in it’s “API Docs” (which by the way, API Docs don’t even come close to what Sencha has) where as Sencha Touch has many times more due to the many times more features it has. Features, not bloat (see my past reply about bloat).

    It’s like saying a Mini Cooper is better than a semi truck. They are both vehicles but the semi can haul quite a bit more than a Mini can. sencha-touch.js is just 124 KB (wait, that’s smaller than Lavaca but it’s not an apples to apples comparison). Of course sencha-touch-all.js is quite a bit larger but holds all classes that you may not need.

    Also, your statement about downloading the “1MB” file each time is false due to ability to cache files in the browser. Further more, Sencha Cmd support delta updates so when you have an update to your app, the user doesn’t have to redownload the entire app, just the delta updates that gets stitched into the already cached application which allows for less download per update.

    Can talk more about the statements made but I think it’s clear that this post isn’t made from an expert in the 3 frameworks that are discussed here which is not fair for all 3 frameworks. You like Lavaca and I’m not going to try to talk you out of that. jQuery is a great product in it’s own right. That’s fine. But person A may read this, devote lots of time with Lavaca and may waste their time building functionality for their app that Lavaca simply just doesn’t have. Sencha Touch is a large framework which makes it not the right fit for every developer need, that where others like Lavaca may succeed.