Recently I’ve received very nice Private Message on Sencha Forums from Sosy and I’d like to share it with you (with the author’s permission). Here it is:

Hello Saki, i would like to say, thank you!

I am new to ExtJS, comming from the PHP/MySQL side (still loving it, but its different already now) (sounds familiar?).

Started for 3 weeks with ExtJS, didn’t like Javascript, cause to abstract for my eyes and head. Read a lot in this forum, started try and error, loaded a lot of examples, tried to figure out why what works and how.

And above all, i am using a lot of your scripts to learn, i love it how you did things.

Tomorrow i started reading about Extjs again (that is my start in the morning, coffee (my own, because i am an coffeeroaster, Firefox, google -> ExtJS) And then read anything what i can find about it.

Bought a book, (ExtJS cookbook, which sucks, nothing in it to use for me) and so on.

But the highlight of tomorrow, or even better, since i started with Ext, was in your blog, found under philosophy.

First of all the leading commata issue, men, Saki i almost had spoken some curses on you as i start to struggle with your code and saw the leading commata.

What i thought was, geee, it says Author: Ing. Jozef Sakalos, well only an Ing. can be this abstract, no wonder that he can programm in Ext.

Then (i only admit this to you, but more on that later) i started to reorder your scripts, remove the leading commata. (*shame*). But for me that was a good start to go through the code, the calls and so on.

Now it comes, why i want to say thank you!

Then i read your second post under philosophy, Changing viewpoint to Ext…

I started reading and, for the first time in 3 weeks i saw some light at the end of the tunnel, reading that you came from the PHP/MySQL side, and how you discriped the fact of what and how you assume it has to work, in reflect to Ext (exactly as how i see it) and on how it has to be.

This all together is changing my thoughts incredibly, even the leading commata thing, i still can believe that i will do that, because it looks really, really ugly for me, but i am also someone who can lay down old habits, if there are really good argumenst.

Thanks Saki, you gave me hope on keep programming in Ext and try to learn it.

Regards from an Dutch guy living in Germany,

Paul Willemsen aka Sosy.

Share

This spring I was contacted by one company with the request of consulting on their application developed in PHP and ExtJS Javascript Library. They wanted to come on site, stay with them one week and advise. I usually take such jobs but I always want to know what product is expected so I know in advance if I can deliver it to the full satisfaction.

These guys succeeded to keep it covered and I was only told: “Come here and work with us for a week.” Being curious enough I succumbed to the temptation and taken the job.

The evening I came they had shown me a beautiful application with many windows, forms, grids, accordions. The application was very complex and I immediately knew that I’m going to work with pros. Uttering words of commendations I was still in a mystery because I still didn’t know what I was there for.

So I asked: “What do you expect from me that you were able to develop this alone?” They said: “Well, it is slow!”

Indeed, Ext window with a form and grid took around 4 seconds to show all it contents before the user could interact with it. And it was intranet! No slow internet connection bottlenecks.

“Yes, that’s too much! Let’s start tomorrow to find out why”, I said.

Next day I dug into the bowels of the application and I found that they generated javascript code on the server and then they loaded it to the client. I mean, not only JSON data but the full javascript executable code with the application.

I was not fully sure if this alone could cause the slowness so we started some profiling of both PHP and Javascript code and finally we decided to rewrite the application to adhere to Writing a Big Application in Ext.

To keep it short, by the end of the week, when done, the very same Ext window opened in less than 500ms. Well done, isn’t it.

Anyway, what could be the reasons why it was that slow in the first place?

1. The server needs some time to generate the javascript. It may not be a lot, however, if you count all database accesses, decision logic and javascript code generation it is probably more than to create a JSON string with data only.
2. The embedded javascript adds to the size of server-client data transfers. This didn’t attribute too much to the time in this particular case but it can get worse if the internet connection is slower.
3. The embedded javascript cannot be cached at client. If the application is in a referenced javascript file then, if the server is configured properly, it is cached at client. Of course, the initial load takes longer but then only the html markup and JSON data are actually transferred from the server.
4. And probably worst: In this kind of loading a request is sent to deliver a component, let’s say a grid. The grid code is returned, the grid is instantiated and rendered and now it needs data. So another request is sent to deliver the JSON data. It’s just too much.

Take this please as my observation and my experience. There may be cases when component loading can work better and faster and I’ll be only glad if I’ll have an opportunity to see such application.

I have found another post that others could be interested in, originally posted on May 25, 2007. The original text follows:

What works for me are leading commas. Why?

First, compiler or script interpreter doesn’t care if I’ve written leading or trailing commas. The only who cares is myself and other human beings that will read, understand, modify and debug the code.

So first comes reading and understanding. Lets take the following examples:

var o = {
    id:2,
    useAccessibilityFeatures:true,
    autoLoad:true,
    name:'demo',
    translateHelpTexts:true
};

In this example, if I want to check if I haven’t forgotten a comma or if I don’t have an extra comma there (infamous IE extra comma error) I have to look at the ends of all five lines with various lengths to see if comma is there and, in the case of the last line, to check that comma is not there.

var o = {
     id:2
    ,useAccessibilityFeatures:true
    ,autoLoad:true
    ,name:'demo'
    ,translateHelpTexts:true
};

In this example I just look at the code as a whole if it has the expected appearance (first line w/o comma to the left and then column of commas).

You know, one line will always be different because number of commas is one less than number of properties.

The modifying of the code or putting some leading comments before the properties to temporarily disable them is pretty same in both cases. What makes bigger difference is a handling of errors I may have done in the code by browser. Let’s make an error in the examples:

var o = {
    id: 2,
    useAccessibilityFeatures: true,
    autoLoad: true,
    name: 'demo',
//    translateHelpTexts: true
};

What happens here? Please-help-my-app-works-in-FF-but-not-in-IE help forum query, waiting for some hours for reply and then not believing: How could I be that stupid?

var o = {
//   id:2
    ,useAccessibilityFeatures:true
    ,autoLoad:true
    ,name:'demo'
    ,translateHelpTexts:true
};

And what happens here? Nice fat syntax error in both Firefox and IE with line number. Finding the line in the code and fix it is the matter of seconds and I can continue with some more important things.

I have better things to do as to hunt a stray extra trailing comma in the code for hours. And you?

I have found one of my older posts to Ext Forum when I have been with Ext for a couple of weeks, just after initial shocks of cognition that if I’m going to use this library I need to step out of my old habits and routines and I need to change my mind about web development.

I think that the original text is very useful for newcomers who would travel same or similar route as I had. There is one more note to it:

Ext made a tremendous step forward since I’ve written this article. Now, server not only does not generate an HTML markup for pages but also it is not needed to generate containers for Ext components. We can do very well with empty body: <body></body>.

The original post dated June 7, 2007:

I’ve decided to write on this viewpoint shift to help others to move swiftly to the Ext concept from “the standard web design”. Believe me, you will have to change the viewpoint; be prepared that what you knew before is not valid anymore, prepared to forget the long-years-worked schemes, prepared that you will maybe need to throw away your hardly written, debugged nice PHP (or other) classes or functions.

Well, this doesn’t sound too good, does it? Is it worth to? Shouldn’t I stay in my ruts where everything just works?

Answer is simple: It’s up to you. Brave enough? Continue reading then.

What we are used to? First of all user has an URL to click. When he clicks the browser sends a request to the server. Server prepares the complete page with styling, pictures, tags, forms, labels and mainly with more links (URLs) and sends it back to the browser.

User then fills-in some data and when he/she’s done clicks submit. The new request travels to server, server processes the data and returns another full page (success or failure or new form), right?

OK, forget this! Except of the first request and first page returned it doesn’t work like this. (Well, it may but why to move to Ext then?)

How the hell it’s working then?

Good. We make the first request, something comes from the server but I wouldn’t call it a full page at all. It’s a kind of concept of to-be-the-page. Imagine you have a navigation on the left and main display are on the right. Yes, you have to load something there so the page is not empty but if you have more than on tab in the center you don’t need to load anything into inactive tabs. User maybe never clicks “third one” so why to run server script and transmit data of something that is never requested.

Now, user clicks something in the left navigation and we want to display it in the center. The request is sent to the server but it is different in that that it runs in the background without reloading the main page. When data arrives we just fill (with the great help of Ext) the main display area and we’re done.

We could (almost) say that one site equals one page, or better to say one concept or framework, and that we load the content into this framework on demand in the background.

Well and what about data?

The same! If we need to display tabular data we just use grid in the center and load it with data from server. Beware, when I say grid I mean grid created by Ext not some complex html table prepared by server and sent to client. The Ext grid is nice, full of features that the “classic” can only dream of (sorting, column resizing and hiding and many more) and the only thing it needs from the server is data.

The same is true for trees, views and other components.

And what about sending data?

This was my major pain in the transition period. I kept looking for forms, hidden fields, field names and all well known things wondering why I had troubles to find some. Yes, they exist but concept of form full of inputs and hidden fields then submit then new page as the only way to get data to the server is gone.

Let’s take an editable grid as an example. I see grid and I need to change data in it. Classic approach would be: click, new page or a popup with form, submit, new page with result or reload of the grid as minimum. This was what I was looking for. Never thought that it can be that simple as to (double)click the cell I want to change the value of, change it and that’s it. And how data gets to the server? In background. Works almost like spreadsheet.

What job is left for the server?

Not too much. It has to prepare the main page but there is not much dynamics needed in that so PHP processor maybe stays idle here and a static HTML will do. Then it has to react to requests sent from client for either another static data (HTML fragments) or we wake up PHP (or other) processor to do some validation and/or database engine SQL-ing.

It is incredibly simple! Sometimes that simple that it is difficult to digest the simplicity. Should you have troubles with anything in Ext start to think “How to make it simple?” That is the right way.

A philosophical conclusion.

Ext doesn’t only provide an easier way to do things in browsers. It is creating the new application platform. You do not need to ask anymore if this or that application is for Linux, Mac or Windows. It’s for a browser with javascript and it doesn’t matter which operating system is installed on the computer the browser runs in.

Happy coding!