15 Jun 2012 11:19 AM #1
Need help about Sencha, How to start ?
Need help about Sencha, How to start ?
Posting it again in Community Discussion.
I am new to Sencha products. I want to use grid in my web application (ASP.NET and C#.NET). It is simple application (NOT MVC). I tried to read documentation but it seems there is not info regarding previous version than 4.0. And 4.0 help is based on MVC pattern.
Where can i get the implementation/coding detail about Sencha Grid?
Any help would be greatly appreciated.
Thanks and Regards,
15 Jun 2012 11:54 AM #2
It has allot of advantages:
- most ExtJS books are still about ExtJS 3.x (or compatible)
- Ext 3.x is still at least 2X faster than Ext 4.x on ANY browser for most scenarios (there are a few exceptions, but in most of the cases it's true - all benchmarks show this.
- ExtDesigner 1.1.x (not 1.2.x - cause is buggy, or Sencha Architect cause it can only MVC style) generate very good and efficient code, that you can extend in your project.
- online API and docs are here: http://docs.sencha.com/ext-js/3-4/#!/api
Hope this helps.
17 Jun 2012 3:40 AM #3
I would disagree.
The use of MVC with ExtJS 4 is entirely optional. If you don't want to use it then fine, you can use an ExtJS 3 app structure in ExtJS 4 no problem.
ExtJS 4.0 had massive performance problems and that made it unusable in larger apps. With 4.1 that's no longer the case. It doesn't matter whether it's slower than 3, what really matters is whether it is possible to write a fast app and with 4.1 it is.
ExtJS 4 is much, much nicer to work with as a developer. It also has more features than 3.
I wouldn't even begin looking at Designer/Architect until you've had a bit of a play with the framework itself. Those tools have their place but there are many factors to consider before deciding whether or not to use them.
17 Jun 2012 4:55 AM #4
Ext 4 was promised to solve the Ext 3 performance problems, but made them worse. Ext 4.1 still doesn't solve that as it is not faster than Ext 3 .
From an end-user's point of view, Ext 4 doesn't have more features, as it doesn't have more visible components, or even worse, plugins and extensions that worked with Ext 3 don't work with 4.x anymore (some of these components even come from Sencha employees ).
What is really bad is the MISSING backward compatibility: both for the framework and for the tools.
So all in one, Ext 3 with it's big working plug-in ecosystem and the Ext Designer 1.1.x for generating allot of code, is the most efficient combination for creating a rich internet application so far.
17 Jun 2012 6:49 AM #5
I'm an ExtJS consultant, I use ExtJS every day. I was made a moderator on the back of the knowledge and experience I showed in helping hundreds of community members on these forums. Why you feel that makes me less qualified to make an objective judgement about the relative merits of ExtJS 3 and ExtJS 4 I'm not sure. Anyone who has built applications on ExtJS has a vested interest in seeing Sencha do well and I'm no different to you in that regard.
By extension I suppose you could argue that gaining experience always comes at the expense of reduced objectivity. I can see some merit to that argument but it doesn't bode well for getting good advice.
I agree that 4 is slower than 3, which is in turn slower than 2. However I think that's something of a distraction and unfortunately a lot of developers use the relative performance as an excuse for the performance of their apps.
Let's say that ExtJS 3 is 2x faster than 4.1. I don't think it is as much as that but I'm happy to use that figure for discussion purposes.
In my experience, following best practices plus a small amount of performance optimizing makes a much, much bigger difference than library version choice. The difference between 1 second and 2 seconds in UI responsiveness is irrelevant, either way it's terrible. With better code the comparison becomes 10ms vs 20ms. Sure, ExtJS 4.1 may be slower but users can't tell the difference between 10ms and 20ms so who cares?
When your boss is yelling at you to make the app faster it's very convenient to pass the buck onto the framework. Whenever I'm targeting performance problems (be it in ExtJS or elsewhere) I'm usually looking for a much bigger improvement than a mere 2x. Typically performance problems are with specific parts of an app and I'm looking to get a 10x or 100x improvement.
With 4.0 performance was a real struggle but with 4.1 I don't find it any harder than it was with ExtJS 2 or 3. It doesn't come for free but it is very attainable.
The transition of community extensions (UXs) from 3 to 4 is a problem. I'd say that generally this is more of a problem for upgrading apps rather than starting a new one from scratch though. You should always be sceptical of UXs, it's difficult to know how well written they are or how much difficulty they will cause you upgrading in future. You've got to ask yourself whether you're willing to pin the success of your UI on some code bashed together by a bloke in a shed. A couple of UXs might be a risk worth taking but I've seen apps that use dozens of them and that's just asking for trouble.
On the point about new features, ExtJS 4 does have a number of new features from an end-user's perspective. Generally there's a progression of features whereby they first become official demos and then subsequently become core features. Off the top of my head, tree grids, drawing, several charting features and row editing all became core features in 4. New demos, such as TreePicker, have been added and may become full features in future. That said, many of my favourite features aren't end-user facing, that doesn't mean they don't exist or don't have any value.
17 Jun 2012 2:32 PM #6
Considering that there are also some Ajax requests there, in most of the time it's starting from 500ms, so the user unfortunately notices. If we bring Tabs to the game, the users perceives even a bigger difference. Another visible fact is not just the bad response time but also the hit on the CPU - that is very visible for the user, since sometimes the browser is freezing because of this (mostly IE). One can compare also the memory and cpu of both Ext3 and Ext4 official examples and see that the difference is quite big there too - so on complex applications, not just hello world hand coded examples, the difference will be even worse .
as the documentation covers what it does, and it does what it's saying, developers figure it out pretty quickly all sort of APIs. Even if namings and other things are not consistent, humans(and average developers) are very good at that, even if they don't like it or don't find it beautiful.
Fixing JS performance problems due to a few MB huge JS frameworks is something that is not in the range of most average developers however.
For us the decision to use ExtJS and not something else, in allot of cases depended on the availability of such UX elements - since one is supposed to just use them, not invent them like it would have been for other frameworks. Most of the Ext core UI elements exist in other frameworks too, so Sencha wouldn't have won in first place the race if it weren't for those many UX elements (this is true for most projects where Ext was chosen)
So for me to be able to sell to my managers the new version of Ext plus to have them understand and pay the migration costs from 3 to 4, there must be more visible elements there, not less (when counting the UX elements too).
18 Jun 2012 7:53 AM #7
You've made a number of good points in your last post. Despite first appearances I don't feel they're necessarily at odds with the points I was trying to make, they're just different observations of the same eco-system.
With the obvious exception I've actually quite enjoyed reading your posts. It's nice to see criticism presented without the usual screaming and negativity. I look forward to seeing you around the forums in future.