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 been with ExtJS for a couple of weeks coming from PHP/mySQL world and I must admit that I had to totally change my viewpoint of the application design and I had to go through many trial-and-error attempts to achieve that something reasonable appeared on the screen with a behavior I wanted.
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!
- Ext, Angular, React, and Vue - 27. June 2019
- The Site Resurgence - 11. February 2018
- Configuring ViewModel Hierarchy - 19. June 2015
11 Responses
like the ..if(true!==x).. which is readen ‘if true is not exactly eqaul to x”
my thoughts:
positive:
1. defensive-programming technique which can be replaced by using good IDE
negative:
1. each code line should act as a logic-unit.
2. differs from 99.9% of the other front/back-end code . no-one is going to rewrite all the extensions and the backend to fit.
3. unreadable,confusing and annoying ( that\’s personal pov)
* that applies also to some other techniques, like the \
…like an “application browser” I was going to say before the rest of my comment mysteriously disappeared underneath that curious backslash up there.
Crawlers? Why would you want search engines indexing a web application? to have your google search results polluted with grid views and OK buttons? Wouldn’t you rather the search engine index the site that discusses your web-application?
Web applications and web-sites are two different concepts that I would like to see diverge and not converge.
But what I really want to muse on is when a framework, such as Ext, becomes natively supported by web-browsers eliminating the need to load half a megabyte of Ext core functionality interpreted Javascript. In fact, I would like to see a different kind of browser emerge, something like an
Hi,
what about a crawlers? Data came involved in JS so bots can\’t indexing the site. Is any solution to generate simple HTML output for crawlers or browser without JScript?
Hi Saki,
Thank you so much for sharing all your knowledge. I’m sure you are a very big reason extjs is so successful!
You’re welcome. I’m always glad if I can help. 🙂
hi saki,
i’ve been using ext for about a week, and after read your post about (your) viewpoint of ext i’m start to feeling what and why extjs are created for.
it’s really cool.
thanks saki.
I’m very glad I could help you. I understand very well how you feel and what you are looking for; I was in your shoes a year ago.
Hi Sacki,
Thanks very much.
As I’m trying since a few days to understand the
“who do what ?” or/and the “where to do things ?”,
this paper is great for me.
By the way, the extensions and plugins you share are
impressive and of a great utility.
Loic
PS: sorry for the approximative english