Why I moved away from Sencha to Phonejs?
Why I switched from Sencha Touch to PhoneJS for mobile development. Discover the performance trade-offs and framework limitations.
Sencha is a well-known framework for mobile development. Not only for mobile development, but it does a hell of a lot more than that. Not only that, but it surely has a wonderful history with JavaScript framework development. I don't have anything to complain about that.
But today I'm going to talk about specifically one framework: Sencha Touch. I was trying to find something that could be developed once and deployed everywhere. Yes, it's kind of a new trend in mobile development nowadays.
And I do have working experience with jQuery Mobile, but still I chose Sencha due to its performance and preference for architecture. I did the same mistake which Rob Sullivan mentioned a couple of days back.
@kunjee it's always a balance of being able to push yourself but make sure you don't go over a cliff from the push.
— Rob Sullivan (@DataChomp) March 23, 2014I practically pushed myself over the cliff. I have nothing particular against Sencha Touch. It is nothing but an overly awesome product. Maybe the problem is on my side. I'm not only doing mobile work. Mobile application is part of a bigger idea or a bigger application. So there are many other things than just running that same thing on mobile.
Framework should help, and if I can't get it up and running in hours, it's getting in my way of development.
That same thing happened with me. I tried Sencha Touch, and other than having lots of boilerplate code, the Sencha command tool is also broken. Even a few months back there was no way to generate a store using the command. I never understood why.
There are two ways of programming that are ruling the market as of now: Object Oriented Programming and Functional Programming. In the latter, you can compose functions and code normally stays small, while in the first one, code is more expansive, and there's a complete tooling chain around that. One of those is Scaffolding. If that is broken, there's no way I can write that much code, especially in JavaScript. Dynamic typing languages are good if you can use that nature, but if you're writing code like it's statically typed, that's like the worst of both worlds.
JavaScript is already a functionally object-oriented language. If I'm doing only the object-oriented part of it, I need my tools up and running perfectly.
I also tried Sencha Architect. It's good for starting, but after using it for a while, it started getting in my way. And I was spending more time learning the tool than solving the real problem. I personally don't like this kind of tool.
Maybe I'm not smart enough to use Sencha products.
[UPDATE]
I spent quite a bit of time learning Sencha, and in the same amount of time, I was able to complete an application using a simpler PhoneJS. It's a little slow at startup, but at least I'm not slowing down my application development just to get out of the development state.
Frequently Asked Questions
The author found that Sencha Touch had too much boilerplate code and broken development tools (like the command tool for generating stores), which got in the way of development rather than helping it. They needed a framework that could be set up and running in hours, not one that required extensive setup and tooling overhead for JavaScript development.
When writing JavaScript in a purely object-oriented style, you lose the benefits of the language's functional programming capabilities while still needing perfect tooling to manage the verbose code. This creates the worst of both worlds—requiring extensive scaffolding and development tools that often don't work reliably, especially in dynamically-typed languages like JavaScript.
A good framework should help accelerate development rather than hinder it. It should be quick to set up and running (ideally within hours), have reliable development tools and command-line utilities, and work well with JavaScript's natural functional-object-oriented nature rather than forcing one paradigm exclusively.
While the author had working experience with jQuery Mobile, they initially chose Sencha Touch for its superior performance and architectural preferences. However, these advantages were outweighed by Sencha's complexity, boilerplate requirements, and broken tooling that made development slower and more cumbersome.