Sencha Touch, ExtJS, Cmd where is it all going?

Sencha Touch, ExtJS, Cmd where is it all going?

I'm a developer who has been using Sencha (ExtJs) for about 5 years now, and it was always a very good software until you made it a complete "Sencha" package. I'm wondering where are you going with all that and what are your guide lines? I'm also very frustrated cause my company bought sencha complete on my persuasion and now I see that it is still an uncompleted product.

Some of my problems/observations during last couple of months:Sencha Touch
1. You release software with outdated documentation:http://docs.sencha.com/touch/2-1/#!/guide/building
- sencha create jsb - does not exist any more and there is no guide on how to do it with Cmd 3.0
There is no documentation on how to compile Sencha Touch app or at least I didn't find it, somehow browsing around forums I found ithttp://docs.sencha.com/touch/2-1/#!/...tive_packaging
- sencha package <configFile.json> -this command does not work, someone commented on it long ago you still haven't fixed it
3. I tried to persuade a client to build his mobile app on sencha touch platform and to native compile it for all of the platforms by telling him that this will greatly lower his cost.
Then I tried to create test app to show it to my client, I needed to use drag'n'drop then I realized that:
4. you have Ext.util.Droppable but it's not working, it's simply not implemented, then I created needed components on my own and lost 2 days to do it, after that I compiled my app to find that:
5. one simple app has 6MB, and after some tries and fails I succeeded in native compiling of production build, and this is not documented anywhere and I don't even know if this is the proper way, but I think that app with size of 6MB is not the way.
6. After native compile and pushing installing my app to android device I found that loading screen is not shown (did not even try to find out why), this does not happen on debug app only on production build, but this is something that is your out of the box code, I didn't mess with this.
7. Some minor problems of different render on device than on desktop browser

ExtJS 4.0
I've worked with 3.x versions of ExtJS and I was very satisfied. Then I persuaded my company to upgrade to 4.0 when it was available. That was a mistake cause we had to:
1. make all our company users use FF until 4.1 comes that fixes speed issues. And after 4.1 came it still is not fast in IE but it is usable, I don't need to tell you how problematic is to change company policy of browser usage
2. We had some problems with some bugs, using our premium support we submitted those bugs only to come with a "This bug has already been submitted and will be fixed in next release" but some of those bugs are still there after 6 months and also once we had a reply: "This bug comes up only 2 out of 10 tries so it's not a issue", or something like that. Try to explain to my superior why every day 25 out of 120 of our company employees step on this bug.
3. You published Sencha Cmd 3 which does not have a sencha create jsb command and thus broke our deployment procedure. I tried to upgrade from 4.0.7 to 4.1.2 and everything works fine except deployment, we simply did not make our components the compass and sass way cause that was not available in 4.0. So my question is how can you make such a big step from 4.0 to 4.1, why is there no documentation on these new steps, why do we need to use one more tool and learn one more thing (compass and sass)? Why is compass so much better, until now I had a simple css file I loaded in my index.html file, that css file had my custom css rules and custom components css rules.
4. In new cmd and production app build you take index.php or index.html or whatever and use that as a starting point and even change that file so that includes production files. Well some people don't use index.php or index.html and are using dynamical templating engine and front controller, so trying to compile through a file is a fail cause it cannot be done. sencha create jsb was a much cleaner way cause you could create it through a domain URL or a file.

Sencha Eclipse plugin
I don't event want to start on how this is a half finished product.

My general questions is how come you make such big steps in minor releases, how come you publish unfinished products when you know that you product is being used in an enterprise environment?
Why do you fail to update documentation when you push your big changes?

Are you aware that when you used ExtJS 3.x you just wrote .js files and included them in your index.html file and everything was working fast, now we have to install sencha cmd, rubby, compass, <br>use command prompt to create files (controllers, models, views), edit app.json, build.xml, package.json files. While I'm a fan of ExtJS MVC structure this forcing of yours to use many tools made development actually slower.
ExtJS 3.x:
1. Create .js
2. include in index.html
3. put some custom css wherever you want
4. use debug or production extjs fil
and that is it
ExtJS 4.x
1. Install sencha cmd
2. Install rubby
3. Install compass
4. Create project using cmd
5. Create files using cmd
6. Create custom css files for every custom component
7. Edit app.json to inlcude custom css and images
8. Use cmd to create production app (if you have front controller in your site forget about this)
9. Pray to the God that it doesn't fail and publish this

How is this faster than ExtJS 3.x?

And after all that pray to the God that 4.1 doesn't get upgraded to 4.2 cause you will need to install python, perl, smalltalk and maybe pascal.

Only good thing is that I succeeded using sencha cmd 2.0 in 4.1.2 environment and I am still able to compile the app old way. And I think I will stick with this.

I'll try to answer your questions the best I can, and I'm sorry to hear you've been having so many troubles using the frameworks.

Sencha Touch: there were a lot of documentation bugs that had crept up over the last few months. We've taken a concerted effort to clean those up and pushed a big set of docs fixes earlier this week. Check them out again, hopefully you'll see a lot cleaner and more accurate documentation there. Regarding the size of the application and the mobile packaging issues you found, the size is mitigated by using Sencha Cmd to build your application. Clearly, if you had trouble getting the old SDK Tools up and running this would have been hard :-), but with Cmd 3.0 you can build and minify your application, as well as do all the native deployment thing.

Ext JS: there were performance issues in Ext JS 4.0, no argument there. We've addressed a large number of them in 4.1 as you point out and there's additional work to make Grids and other components faster in 4.2. As you note the build/deploy process has become more complex as we moved from 3.x to 4.x and a large part of that is to accomodate larger and more complex applications that are being built with Ext JS. It's definitely more steps to get up and running, but the long term management and maintenance we believe is easier with Cmd and Sass/Compass, et al. Again, in a lot of cases this will lead to more up front configuration steps as you mention, but we hope developers see the value in the process as their projects get more complex. Now, regarding templating systems and front end controllers, I'm sorry to hear that it's gotten more complex for you in your environment You're always welcome to use ext-all.js and not use the loaders and the parts of the app.json you don't want.

Sencha Eclipse Plugin: I'm sorry that you've had trouble with the Eclipse plugin. The feedback I've received from a lot of our customers is that it's helped them quite a bit in their development process.

Documentation: just to let you know, we know that the documentation and the maintenance of it causes a lot of issues for our customers, community and developers. We're working hard on making the right changes in house to get our process better so that those kinds of problems go away. It's not ideal, but it's a known problem here and we're working to address it.

Thanks for taking the time to let us know about your experience. I am sorry to hear that you have had challenges getting up and going with newer releases and newer tooling (Sencha Cmd). If you want to go deeper in to any of those specifics, I encourage you to post the details in smaller/focused threads to help us help you.

I will try to cover some of yours points on Ext JS / Cmd in a general way here:

3. You published Sencha Cmd 3 which does not have a sencha create jsb command and thus broke our deployment procedure. I tried to upgrade from 4.0.7 to 4.1.2 and everything works fine except deployment,

Upgrading to Sencha Cmd is not required to upgrade to Ext JS 4.1.2, though we do recommend it as your time permits. There are certainly changes in Cmd vs JSB but, as I will elaborate below, these should be more helpful once you are familiar with them.

we simply did not make our components the compass and sass way cause that was not available in 4.0. So my question is how can you make such a big step from 4.0 to 4.1, why is there no documentation on these new steps, why do we need to use one more tool and learn one more thing (compass and sass)? Why is compass so much better, until now I had a simple css file I loaded in my index.html file, that css file had my custom css rules and custom components css rules.

We have used Compass starting with Ext JS 4.0, but did not provide any kind of workflow automation around it - you had to do that yourself or ignore it and use the provided CSS files. This is the same now, except that a Cmd-generated application contains calls to Compass to automate this for you. I must assume that is what you mean in this case? If so, these can be disabled by setting the "skip.sass" option for the generated build script.

The Cmd theme guide (http://docs.sencha.com/ext-js/4-1/#!.../command_theme) was updated for Cmd 3.0.2 so should be a good reference for using Cmd to produce themes. This is the only aspect where Cmd uses Compass, so I am assuming this is probably relevant to your comments.

4. In new cmd and production app build you take index.php or index.html or whatever and use that as a starting point and even change that file so that includes production files. Well some people don't use index.php or index.html and are using dynamical templating engine and front controller, so trying to compile through a file is a fail cause it cannot be done. sencha create jsb was a much cleaner way cause you could create it through a domain URL or a file.

In a Cmd-generated application we generate a default index.html file. This is then compiled using the Cmd page compiler, but this is just one mode for using Cmd. For more details on alternative modes that do not operate against a markup file, see http://docs.sencha.com/ext-js/4-1/#!...and_app_single for starters. There are other guides the go in to the lower-level commands that give you precise control over the JavaScript build.

sencha create jsb was a much cleaner way cause you could create it through a domain URL or a file.

The critical problem with the previous technique is the requirement to have a running server to serve the page as a pre-requisite for building the application. While this can often be "bootstrapped" in some way, it was quite problematic for many environments.

The current version of Cmd provides many ways to start from source JavaScript (or markup) and produce a build suited to your needs. If you have some specific Cmd questions and the guides are not clearing things up, I hope you can drop by http://www.sencha.com/forum/forumdis...p?8-Sencha-Cmd and provide some details on what you are needing to do.

As mentioned in the previous post, we are working to address the shortcomings in the documentation and guides - we appreciate any feedback on where this material is failing people so that we know what needs fixing. While we work on that, I hope the forums are a place where your questions can be answered.

I am worried about ExtJS too

I am worried about ExtJS too

I am a professonial ExtJS developer and make my money with developing with this framework. I have the Sencha Complete package and pay good money for this. But I have already 2 occasions where I had to downgrade my software to the GPL version 4.0.7 (from 4.1.2), because of bugs in the commercial higher releases. It is for me not understandable that the commercial later releases of ExtJS are having flaws that 4.0.7 doesn't have. And regarding support I agree that Sencha is taking things not very serious. I have also reported a bug that was not in 4.0.7, but is in 4.1.2. As a remark I got that it was not clear if the bug would be solved in 4.1.3.

Come on, how can you release a newer version, only available to commercial developers and have bugs in it, that the GPL version doesn't have? Why am I paying suppport, to only hear that bugs might not be solved. I am a great admirer of ExtJS, but please take it serious. I have projects, with budgets over 15.000 Euro and therefor I am really relying on good ExtJS releases. That is what I pay for, I hope.

I have a few big projects still running build with ExtJS 3. And I must say they are running flawless and fast.

ExtJS 4 is slower than version 3, but nevertheless I would never build another project again in version 3, simply because I don't want to keep the knowledge updated for 2 versions of the framework.

Please Sencha, keep ExtJS the best framework for frontend Ajax development up to date and don't put all your cards on the mobile Touch. There are still enough customers out there that don't have their employees fiddling around with tablets. Some developers are earning their bread with it. Don't underestimate that.

I am sorry to hear of those problems. We do take Ext JS stability and improvement very seriously and have a dedicated team working on it. If you want to share the tickets you have open that would be helpful to be more specific, but in general.

Originally Posted by jvandemerwe

I had to downgrade my software to the GPL version 4.0.7 (from 4.1.2), because of bugs

Moving from 4.0.x to 4.1.x is a process that we have documented (http://docs.sencha.com/ext-js/4-1/#!/guide/upgrade_41) because there are some important changes to be aware of. Perhaps you are encountering bugs but if you are unaware of these issues, you could be encountering them.

Minor note - you should be able to download any release of the commercial licensed products via support so you should not have to switch to a GPL licensed version ... if that matters to you. Given a particular version number, the only difference between GPL and commercial releases is the license.

Originally Posted by jvandemerwe

how can you release a newer version, only available to commercial developers and have bugs in it, that the GPL version doesn't have?

While we cannot guarantee a regression-free release, we treat regressions very seriously and they are the primary reason we hold releases beyond their target dates. Finding them prior to release is obviously critical to that and we make every effort to do so using automated and manual testing on all supported browsers.

Despite the efforts made, however, bugs do escape. Bugs reported by support customers are given priority attention in the maintenance release process. Also, support can in some cases provide "overrides" or workarounds until the bug is resolved. I don't know your specific situation, but you can request an override. Whether or not a particular issue can be "hot fixed" in this way is case-by-case.

On the performance of Ext JS 4, have you been able to try out Ext JS 4.1.x to see how that changes things for you?

@jvandemerwe
I am sorry to hear of those problems. We do take Ext JS stability and improvement very seriously and have a dedicated team working on it. If you want to share the tickets you have open that would be helpful to be more specific, but in general.

Ticket: EXTJSIV-8118

Originally Posted by dongryphon

Moving from 4.0.x to 4.1.x is a process that we have documented (http://docs.sencha.com/ext-js/4-1/#!/guide/upgrade_41) because there are some important changes to be aware of. Perhaps you are encountering bugs but if you are unaware of these issues, you could be encountering them.

But Sencha is already working on 4.1.3 with a nightly build on 4.1.4. I even see a 4.2 Beta. What I would like to know is, why you are fixing things that don't seem to be broken in the first place. Making big steps in an upgrade from 4.0 to 4.1 is rather tricky. It is like changing wheels on a riding car.

Don't underestimate how many developers are already professionally building on a "4" release. Going from 3 to 4 was a big step forward (and somewhat painful). Within a "4" release it should not lead to unwanted behavior when upgrading the framework release in my software. Because small teams don't have tons of time to test the software (already in production) all over again, just because they don't trust the upwards compatibility. And that is just what seems to happen now. My applications have tons of panels and windows with as many other classes. I can't spend hours of time testing everything again, simply because my customers won't pay it. And if the reason for a release upgrade would be a great performance improvement, it would be good reason to consider it, won't it?.

Originally Posted by dongryphon

Minor note - you should be able to download any release of the commercial licensed products via support so you should not have to switch to a GPL licensed version ... if that matters to you. Given a particular version number, the only difference between GPL and commercial releases is the license.

I am aware of that, but what my point is here, is that there seems to be no extra benefit to pay for support, if the commercial last version doesn't offer any improvement or gain over the GPL version. I know "cheaters" that are using the free GPL version to build commercial software.

Originally Posted by dongryphon

On the performance of Ext JS 4, have you been able to try out Ext JS 4.1.x to see how that changes things for you?

The performance on Ext JS 4 is not as good as in version 3, but my customers are not bothered by it, for it is acceptable (with Google Chrome). Version 4.1.x is faster than 4.0.x, but not as fast as version 3. But as I stated earlier, version 4.1.x is still not as good as version 4.0.7 is. So the discussion about performance is not so relevant, if I don't dare to use it in a production environment yet. What is exactly the Ext JS 4 version that Sencha recommends for using in a production environment?

Concluding: if version 4.1 is such an improvement over 4.0.x, than make some hurry to fix it. I would look so good with my customers, if I could present a great performance improvement just overnight.

I am aware of that, but what my point is here, is that there seems to be no extra benefit to pay for support, if the commercial last version doesn't offer any improvement or gain over the GPL version.

This is strange logic, you buy a commercial licence to avoid the viral give it away to anyone and everyone obligations of GPL. What made you believe a Sencha commercial licence provides access to a superior engineered branch of the library?

Anyhow in your most recent post you seem to have retracted the allegation that the commercial variant is inferior to the GPL licenced library.

Seriously Irked and Worried

Seriously Irked and Worried

I think what we need is reassurance from Sencha that they are still taking Ext-Js seriously.

The whole darn industry is awash with mobile-tablet hoopla. Personally, I don't care much for these platforms; my clients are all sitting at their boring old-fashioned desks with boring old-fashioned PCs with boring old-fashioned large screens.

You can see the mobile-app bubble-mania everywhere. Suddenly every one wants to implement totally ill-conceived projects on mobile just because it is the 'cool' thing. Granted, there are some good reasons to having a mobile-app. But not for everything. (I just had a client want an iPhone App to list their contacts with. I told them to just deliver a responsive web-page. They thought I was from the Ark. Apparently one of their competitors has a swanky new App which can be downloaded from the iStore. God help us.)

Can we get a reassurance from Sencha on whether or not they are still taking 'boring old-fashioned desktop rich applications' seriously and that there is still a sizeable focus - both on talent and budget - within Sencha for Ext-JS?

Or have Sencha's directors been told to focus on mobile because they think desktop is toast?