ExtJS4: practical impressions
When choosing a software platform, the eyes usually run up - here it is, everything is here and everything is always excellent. All sorts of comparative matrices do not help anymore - you can see that in framework X there is no connection to the industrial system of automatic flushing toilets, but this information is not always useful.
And I want to understand what this or that library is good for in practical applications, I want to read about someone’s experience. And this is not very. For example, by ExtJS, I did not find anything like that. 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 universal generalizations.
')
So conditions. I need to write a beautiful web interface of a rather large 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 value the convenience and speed of their work much more than the thingies that you get used to in three days. They also like to propose any changes and they very much approve 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 - I don’t really like messing around with the web interface and try to get rid of this part quickly.
So, the positive sides 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, luxurious. Rich selection of controls, carefully selected colors, pre-written styles. Suffice it to say that you can not deal with either HTML or CSS at all, and forget them both as a bad dream. There is access to the DOM in the library just in case, but I have never used it - everything is decided and so.
The application is easy to dock with REST, as long as REST gives the data in the correct (and not very complicated) format. It suffices to describe only where to go for the data - and voila. Out of the box, the entire gentleman's CRUD set works.
Almost all user actions can be brought to the interface and not load the server with them. The share of the latter is only additional validation of data and work with the database. This makes it very easy - literally up to 5-10 kb of code (nodejs, mojo - I tried several options, everywhere it turns out well).
Now about the shortcomings.
He is one, but global - all this, like those Christmas tree toys, is not pleasing. Programming on ExtJS not only brings no pleasure, but quite the opposite. It is an abundant source of frustrations, complexes, and clips.
The overall style of the library is best conveyed by the word "monstrous". This is a kind of mastodon, in which the score files with the source goes to dozens. When you connect the page to the browser is loaded about 6 megabytes of all good and this time is very, very noticeable.
Because of the terribly slow loading, it is impossible to program in my favorite way, which I learned from Fort - minor edits. You make one change, see the result, rule. Repeat. It doesn't work that way - until this elephant is loaded after each change, you forget what you wanted to do. Thoughts have already gone somewhere far, on lush green fields and white mountains with waterfalls.
ExtJS is terribly difficult to learn. It is huge, it is not clear where to start. Textbooks and books generally refer 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 written there is outdated long ago.
I am ashamed to say, but I wrote a banal application from scratch for almost a week, suffering from sudden mood swings. All the time I wanted to beat my head against the wall - everything was incomprehensible. I have not taught any technology with such suffering.
The second application, however, was no better. A little faster, but not much.
In version 4, your application should be done on the principle of MVC. In practice, this means that even the hello world will consist of a dozen files, spread out in several different directories. And before you start programming any task, you will need to create and decompose these files. This is not HTML, which opens even with a blank page. The situation is reminiscent of professional weightlifters, who, before approaching the projectile, need to warm up and warm up their muscles for several hours.
The set is standard. The model describes your data, in the storage - how to get to this data, in views - how it will look. Here everything is more or less logical.
A type controller connects the view with 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 with its help to write some kind of self-sufficient widget, which could then be inserted wherever you want.
With the data, too, not all is well. Storage assumes that all data is always completely homogeneous. It is possible, however, to describe some nested entities in a one-to-many manner, but this additional data is only readable - it is impossible to write them, which makes the whole project useless.
The interface description is something. It is described purely declaratively - and this is a plus. But as he is described, my God. With the help of Javascript data declaration - and there are few types of data, arrays and hashes. Therefore, any screen, with just a pair of controls, is a long footcloth of a declarative code, with structures repeatedly nested into each other. Search under these conditions, where the extra bracket stands - this is hell. To simplify the declaration is impossible - it is necessary to describe every sneeze, useful default values ​​practically do not exist.
Therefore, any change in the interface or code, even the correction of a grammatical error, necessarily implies a long search for the place where, in fact, must be corrected. First you need to try to remember where it is, then rummage around a bunch of nested directories, choose the right file from a dozen again, and in it search for a long, long time in the code, which because of multiple indents usually leaves where the devil knows where, and pray that nesting will not break.
There are errors in the library. Not very much, but there is. However, because of the total, they turn into a nightmare - they cannot be fixed in any way. It is not clear what they are from, it is not clear what needs to be changed, it is not clear what the matter is. It is especially hard if these are errors in the layout algorithms - then you find yourself just with a blank page and an incomprehensible message in the console.
Or users write to you - the table is not loaded at us. You open - and the truth is not loaded. Yesterday I loaded, but today I don’t, and you didn’t change anything at this place.
It is no better with your own mistakes. Diagnostics are very often very mysterious and only after a couple of months you begin to guess that “undefined” somewhere deep in the depths of ExtJS means the missing Store attribute when describing a drop-down list.
Accordingly, debugging becomes useless. Your own code is purely declarative, there is nothing to debug there, and to deal with the megabytes of code of the library itself is an exercise that requires tremendous courage.
Writing your own controls or modifying old ones is another matter. 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 want. But if there are a few more changes, a sharp leap in complexity follows. From declarative descriptions, we find ourselves somewhere deep in a pit with lions, DOM, unobvious events, parent objects and the devil knows what else.
In general, the general style of the framework resembles Maykrosoftovsky. It is easy, very easy to do what was previously foreseen by the authors, but a step to the left, a step to the right - immediately execution.
Based on the foregoing, in my next project (and I have many different ones), I’ll try something different for the interface.
And I want to understand what this or that library is good for in practical applications, I want to read about someone’s experience. And this is not very. For example, by ExtJS, I did not find anything like that. 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 universal generalizations.
')
So conditions. I need to write a beautiful web interface of a rather large 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 value the convenience and speed of their work much more than the thingies that you get used to in three days. They also like to propose any changes and they very much approve 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 - I don’t really like messing around with the web interface and try to get rid of this part quickly.
So, the positive sides 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, luxurious. Rich selection of controls, carefully selected colors, pre-written styles. Suffice it to say that you can not deal with either HTML or CSS at all, and forget them both as a bad dream. There is access to the DOM in the library just in case, but I have never used it - everything is decided and so.
The application is easy to dock with REST, as long as REST gives the data in the correct (and not very complicated) format. It suffices to describe only where to go for the data - and voila. Out of the box, the entire gentleman's CRUD set works.
Almost all user actions can be brought to the interface and not load the server with them. The share of the latter is only additional validation of data and work with the database. This makes it very easy - literally up to 5-10 kb of code (nodejs, mojo - I tried several options, everywhere it turns out well).
Now about the shortcomings.
He is one, but global - all this, like those Christmas tree toys, is not pleasing. Programming on ExtJS not only brings no pleasure, but quite the opposite. It is an abundant source of frustrations, complexes, and clips.
The overall style of the library is best conveyed by the word "monstrous". This is a kind of mastodon, in which the score files with the source goes to dozens. When you connect the page to the browser is loaded about 6 megabytes of all good and this time is very, very noticeable.
Because of the terribly slow loading, it is impossible to program in my favorite way, which I learned from Fort - minor edits. You make one change, see the result, rule. Repeat. It doesn't work that way - until this elephant is loaded after each change, you forget what you wanted to do. Thoughts have already gone somewhere far, on lush green fields and white mountains with waterfalls.
ExtJS is terribly difficult to learn. It is huge, it is not clear where to start. Textbooks and books generally refer 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 written there is outdated long ago.
I am ashamed to say, but I wrote a banal application from scratch for almost a week, suffering from sudden mood swings. All the time I wanted to beat my head against the wall - everything was incomprehensible. I have not taught any technology with such suffering.
The second application, however, was no better. A little faster, but not much.
In version 4, your application should be done on the principle of MVC. In practice, this means that even the hello world will consist of a dozen files, spread out in several different directories. And before you start programming any task, you will need to create and decompose these files. This is not HTML, which opens even with a blank page. The situation is reminiscent of professional weightlifters, who, before approaching the projectile, need to warm up and warm up their muscles for several hours.
The set is standard. The model describes your data, in the storage - how to get to this data, in views - how it will look. Here everything is more or less logical.
A type controller connects the view with 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 with its help to write some kind of self-sufficient widget, which could then be inserted wherever you want.
With the data, too, not all is well. Storage assumes that all data is always completely homogeneous. It is possible, however, to describe some nested entities in a one-to-many manner, but this additional data is only readable - it is impossible to write them, which makes the whole project useless.
The interface description is something. It is described purely declaratively - and this is a plus. But as he is described, my God. With the help of Javascript data declaration - and there are few types of data, arrays and hashes. Therefore, any screen, with just a pair of controls, is a long footcloth of a declarative code, with structures repeatedly nested into each other. Search under these conditions, where the extra bracket stands - this is hell. To simplify the declaration is impossible - it is necessary to describe every sneeze, useful default values ​​practically do not exist.
Therefore, any change in the interface or code, even the correction of a grammatical error, necessarily implies a long search for the place where, in fact, must be corrected. First you need to try to remember where it is, then rummage around a bunch of nested directories, choose the right file from a dozen again, and in it search for a long, long time in the code, which because of multiple indents usually leaves where the devil knows where, and pray that nesting will not break.
There are errors in the library. Not very much, but there is. However, because of the total, they turn into a nightmare - they cannot be fixed in any way. It is not clear what they are from, it is not clear what needs to be changed, it is not clear what the matter is. It is especially hard if these are errors in the layout algorithms - then you find yourself just with a blank page and an incomprehensible message in the console.
Or users write to you - the table is not loaded at us. You open - and the truth is not loaded. Yesterday I loaded, but today I don’t, and you didn’t change anything at this place.
It is no better with your own mistakes. Diagnostics are very often very mysterious and only after a couple of months you begin to guess that “undefined” somewhere deep in the depths of ExtJS means the missing Store attribute when describing a drop-down list.
Accordingly, debugging becomes useless. Your own code is purely declarative, there is nothing to debug there, and to deal with the megabytes of code of the library itself is an exercise that requires tremendous courage.
Writing your own controls or modifying old ones is another matter. 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 want. But if there are a few more changes, a sharp leap in complexity follows. From declarative descriptions, we find ourselves somewhere deep in a pit with lions, DOM, unobvious events, parent objects and the devil knows what else.
In general, the general style of the framework resembles Maykrosoftovsky. It is easy, very easy to do what was previously foreseen by the authors, but a step to the left, a step to the right - immediately execution.
Based on the foregoing, in my next project (and I have many different ones), I’ll try something different for the interface.
Source: https://habr.com/ru/post/172271/
All Articles