ExtJS4: hands-on experience
When choosing a software platform, eyes usually run wide - here it is, here it is and everything is invariably excellent. Different kinds of comparative matrices no more help - you can see that in the framework X there is no connection to the industrial system of automatic flushing of water in toilets, but this information is not always useful.
But I want to understand what this or that library is suitable for in practical applications, I want to read about someone’s experience. And with this not very. For example, on ExtJS I did not find anything like this. I had to try it myself.
The following are my impressions of working on ExtJS 4.1.1. They are, by definition, subjective and do not pretend to be universal generalizations.
So, the conditions. I need to write a beautiful web interface of great complexity. I really want all this to look like an application, not a website. The application is intranet, so beauty is not particularly needed. Users much more value the convenience and speed of their work than the little things that you get used to in three days. They also like to suggest all sorts of changes and are very encouraged when these changes are made quickly. The issue of compatibility with browsers is not worth it - they will sit on what I say.
An additional condition is that I don’t really like to mess with the web interface and try to get rid of this part as quickly as possible.
So, the positive aspects of ExtJS 4.1.1.
You can achieve a globally set goal with its help - you can really write a web application on it. It will look professional and beautiful, I would even say luxuriously. A wide selection of controls, carefully selected colors, pre-written styles. It’s enough to say that you don’t have to deal with HTML or CSS at all, and forget both of them like a nightmare. There is access to the DOM in the library just in case, but I have never used it - everything is solved as it is.
The application easily interfaces with REST, the main thing is that REST returns data in the correct (and not particularly complicated) format. It is enough to describe only where to go for the data - and voila. Out of the box, the entire gentleman's CRUD kit works.
Almost all user actions can be moved to the interface and not load the server with them. The share of the latter remains only an additional verification of the correctness of data and work with the database. This greatly simplifies it - literally up to 5-10 kb of code (nodejs, mojo - I tried several options, it works out well everywhere).
Now about the shortcomings.
He is one, but global - all this, like those same Christmas tree decorations, is not happy. Programming on ExtJS not only does not bring any pleasure, but quite the opposite. It is an abundant source of frustrations, complexes and clamps.
The general style of the library is best conveyed by the word "monstrous". This is a kind of mastodon, in which dozens of files with source codes are counted. When you connect the page to the browser, about 6 megabytes of all good is loaded and this time is very, very noticeable.
Due to the terribly slow loading, it is impossible to program in my favorite way that I learned from Fort - minor edits. You make one change, look at the result, rule. Repeat. It doesn’t work out - until this elephant boots after each change, you forget what you wanted to do. Thoughts had already gone far away, into the lush fields of greenery and white mountains with waterfalls.
Learning ExtJS is terribly difficult. It is huge, it is not clear where to start. Textbooks and books mainly relate to the third version, and it, in turn, is not very similar to version 4, in which almost everything is done differently. For the same reason, forums are almost useless, because everything that is written there is long outdated.
It's a shame to say, but I wrote a trivial application from scratch for almost a week, while suffering from sharp mood swings. All the time I wanted to bang my head against the wall - absolutely everything was incomprehensible. I have not taught any technology with such suffering.
The second application, however, was no better. A little faster, but not by much.
In version 4, your application should be made on the principle of MVC. In practice, this means that even hello world will consist of a dozen files arranged in several different directories. And before you start programming any task, these files will need to be created and decomposed. This is not HTML that opens even with a blank page. The situation is reminiscent of professional weightlifters, who, before approaching the projectile, need to warm up for several hours and warm up their muscles.
The set is standard. The model describes your data, in the storage (Storage) - how to get to this data, in the views - how it will all look. Everything is more or less logical here.
The type controller connects the view with the handlers, but in fact in the fourth version it is not brought to mind and is usually useless. It is assumed that you will have a global controller for each entity and it is completely impossible to write some kind of self-sufficient widget with it, which could then be inserted wherever you want.
With data, too, not everything is safe. The repository assumes that all data is always completely homogeneous. True, it is possible to describe some embedded entities in a one-to-many manner, but these additional data are only read - they cannot be written, which makes the whole idea useless.
An interface description is something. It is described purely declaratively - and this is a plus. But how is he described, Lord. With the help of the Javascript data declaration - and there are not many types of data, arrays and hashes. Therefore, any screen, with just a couple of controls, is a long footstep of the declarative code, with structures repeatedly nested into each other. To look under such conditions in which place the extra bracket is is hell. It is impossible to simplify declarations - it is necessary to describe each sneeze; practically no useful default values exist.
Therefore, any change in the interface or code, even the correction of a grammatical error, necessarily involves a long search for the place where, in fact, you need to edit. First you need to try to remember where it is, then rummage through the heap of nested directories, there, select the file you need again from a dozen, and rummage in it for a long, long time, because of the multiple indentation, the devil usually goes where, and at the same time pray that the nesting will not break.
There are errors in the library. Not very many, but there are. However, due to their total complexity, they turn into a nightmare - they cannot be fixed in any way. It is unclear what they come from, it is not clear what needs to be changed, it is not clear what the matter is. It is especially difficult if these are errors in layout algorithms - then you find yourself simply with a blank page and an incomprehensible message in the console.
Or users write to you - our table does not load. You open - and the truth is not loaded. Yesterday it was loaded, but not today, despite the fact that in this place you did not change anything.
The situation is no better with your own mistakes. Diagnostics is very often extremely mysterious, and only after a couple of months you start to guess that “undefined” somewhere deep in the bowels of ExtJS means the missing Store attribute when describing the drop-down list.
Accordingly, debugging becomes useless. Your own code is purely declarative, there is nothing to debug there, and to deal with megabytes of code for the library itself is an occupation that requires great courage.
Writing your own controls or modifying old ones is something else. However, if the modifications are not very large, then this is done relatively easily - the old object is inherited and changes are made to it. This is usually the easiest way to get the library to do what you need. But if there are a few more changes, a sharp jump in complexity follows. From declarative descriptions, we find ourselves somewhere deep in a pit with lions, a HOUSE, non-obvious events, parental objects and the devil knows what else.
In general, the overall style of the framework resembles Microsoft. It’s easy, very easy to do what the authors had foreseen in advance, but a step to the left, a step to the right - immediately execution.
Based on the foregoing, in my next project (and I have a lot of different ones), I still try something else for the interface.
But I want to understand what this or that library is suitable for in practical applications, I want to read about someone’s experience. And with this not very. For example, on ExtJS I did not find anything like this. I had to try it myself.
The following are my impressions of working on ExtJS 4.1.1. They are, by definition, subjective and do not pretend to be universal generalizations.
So, the conditions. I need to write a beautiful web interface of great complexity. I really want all this to look like an application, not a website. The application is intranet, so beauty is not particularly needed. Users much more value the convenience and speed of their work than the little things that you get used to in three days. They also like to suggest all sorts of changes and are very encouraged when these changes are made quickly. The issue of compatibility with browsers is not worth it - they will sit on what I say.
An additional condition is that I don’t really like to mess with the web interface and try to get rid of this part as quickly as possible.
So, the positive aspects of ExtJS 4.1.1.
You can achieve a globally set goal with its help - you can really write a web application on it. It will look professional and beautiful, I would even say luxuriously. A wide selection of controls, carefully selected colors, pre-written styles. It’s enough to say that you don’t have to deal with HTML or CSS at all, and forget both of them like a nightmare. There is access to the DOM in the library just in case, but I have never used it - everything is solved as it is.
The application easily interfaces with REST, the main thing is that REST returns data in the correct (and not particularly complicated) format. It is enough to describe only where to go for the data - and voila. Out of the box, the entire gentleman's CRUD kit works.
Almost all user actions can be moved to the interface and not load the server with them. The share of the latter remains only an additional verification of the correctness of data and work with the database. This greatly simplifies it - literally up to 5-10 kb of code (nodejs, mojo - I tried several options, it works out well everywhere).
Now about the shortcomings.
He is one, but global - all this, like those same Christmas tree decorations, is not happy. Programming on ExtJS not only does not bring any pleasure, but quite the opposite. It is an abundant source of frustrations, complexes and clamps.
The general style of the library is best conveyed by the word "monstrous". This is a kind of mastodon, in which dozens of files with source codes are counted. When you connect the page to the browser, about 6 megabytes of all good is loaded and this time is very, very noticeable.
Due to the terribly slow loading, it is impossible to program in my favorite way that I learned from Fort - minor edits. You make one change, look at the result, rule. Repeat. It doesn’t work out - until this elephant boots after each change, you forget what you wanted to do. Thoughts had already gone far away, into the lush fields of greenery and white mountains with waterfalls.
Learning ExtJS is terribly difficult. It is huge, it is not clear where to start. Textbooks and books mainly relate to the third version, and it, in turn, is not very similar to version 4, in which almost everything is done differently. For the same reason, forums are almost useless, because everything that is written there is long outdated.
It's a shame to say, but I wrote a trivial application from scratch for almost a week, while suffering from sharp mood swings. All the time I wanted to bang my head against the wall - absolutely everything was incomprehensible. I have not taught any technology with such suffering.
The second application, however, was no better. A little faster, but not by much.
In version 4, your application should be made on the principle of MVC. In practice, this means that even hello world will consist of a dozen files arranged in several different directories. And before you start programming any task, these files will need to be created and decomposed. This is not HTML that opens even with a blank page. The situation is reminiscent of professional weightlifters, who, before approaching the projectile, need to warm up for several hours and warm up their muscles.
The set is standard. The model describes your data, in the storage (Storage) - how to get to this data, in the views - how it will all look. Everything is more or less logical here.
The type controller connects the view with the handlers, but in fact in the fourth version it is not brought to mind and is usually useless. It is assumed that you will have a global controller for each entity and it is completely impossible to write some kind of self-sufficient widget with it, which could then be inserted wherever you want.
With data, too, not everything is safe. The repository assumes that all data is always completely homogeneous. True, it is possible to describe some embedded entities in a one-to-many manner, but these additional data are only read - they cannot be written, which makes the whole idea useless.
An interface description is something. It is described purely declaratively - and this is a plus. But how is he described, Lord. With the help of the Javascript data declaration - and there are not many types of data, arrays and hashes. Therefore, any screen, with just a couple of controls, is a long footstep of the declarative code, with structures repeatedly nested into each other. To look under such conditions in which place the extra bracket is is hell. It is impossible to simplify declarations - it is necessary to describe each sneeze; practically no useful default values exist.
Therefore, any change in the interface or code, even the correction of a grammatical error, necessarily involves a long search for the place where, in fact, you need to edit. First you need to try to remember where it is, then rummage through the heap of nested directories, there, select the file you need again from a dozen, and rummage in it for a long, long time, because of the multiple indentation, the devil usually goes where, and at the same time pray that the nesting will not break.
There are errors in the library. Not very many, but there are. However, due to their total complexity, they turn into a nightmare - they cannot be fixed in any way. It is unclear what they come from, it is not clear what needs to be changed, it is not clear what the matter is. It is especially difficult if these are errors in layout algorithms - then you find yourself simply with a blank page and an incomprehensible message in the console.
Or users write to you - our table does not load. You open - and the truth is not loaded. Yesterday it was loaded, but not today, despite the fact that in this place you did not change anything.
The situation is no better with your own mistakes. Diagnostics is very often extremely mysterious, and only after a couple of months you start to guess that “undefined” somewhere deep in the bowels of ExtJS means the missing Store attribute when describing the drop-down list.
Accordingly, debugging becomes useless. Your own code is purely declarative, there is nothing to debug there, and to deal with megabytes of code for the library itself is an occupation that requires great courage.
Writing your own controls or modifying old ones is something else. However, if the modifications are not very large, then this is done relatively easily - the old object is inherited and changes are made to it. This is usually the easiest way to get the library to do what you need. But if there are a few more changes, a sharp jump in complexity follows. From declarative descriptions, we find ourselves somewhere deep in a pit with lions, a HOUSE, non-obvious events, parental objects and the devil knows what else.
In general, the overall style of the framework resembles Microsoft. It’s easy, very easy to do what the authors had foreseen in advance, but a step to the left, a step to the right - immediately execution.
Based on the foregoing, in my next project (and I have a lot of different ones), I still try something else for the interface.