Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Books Book Reviews

Learning Ext JS 133

stoolpigeon writes "Rich Internet Applications (RIA) have often been associated with some type of sandbox or virtual machine environment to make desktop features available via the web. Many applications though, have left behind the restrictions and demands of those technologies, implementing RIAs as pure web interfaces. One key technology in this area is JavaScript. It's been well documented that working with JavaScript can be problematic across various browsers. In response a number of JavaScript libraries have been created to alleviate the issues in dealing with different browsers, allowing developers to focus on application logic rather than platform concerns. One such library, focused on providing tools for building RIAs is Ext JS. For the aspiring developer looking to use Ext JS, Packt provides a guide to the library in the form of Learning Ext JS." Read on for the rest of JR's review.
Learning Ext JS
author Shea Frederick, Colin Ramsay, Steve 'Cutter' Blades
pages 309
publisher Packt Publishing
rating 8/10
reviewer JR Peck
ISBN 978-1-847195-14-2
summary Build dynamic, desktop-style user interfaces for your data-driven web applications.
The book is written for people with experience in doing web development. The authors state that a working knowledge of HTML and CSS are important, but experience with JavaScript is not essential. I think that a reader that has not used JavaScript may want to supplement this guide with something that covers the basics of JS. Experienced developers that haven't worked specifically with web programming should have no trouble keeping up. Anyone completely new to the idea of programming, scripting, markup, etc. really will need to take some time to get familiar with those concepts before they dive into this book. The authors do not spend time teaching programming, they are focused purely on realistic applications of Ext JS.

The authors begin by stating that, "Ext is not just another JavaScript library..." and it is understandable that they would feel this way. I am unsure why one wouldn't think so other than a personal preference for the product. That said Ext JS can be used alongside other JS libraries and does provide a lot of features 'out of the box' that make it an attractive choice. The emphasis on RIA widgets and building strong applications is nice as Ext JS is not working to be all things to all developers.

The book is heavy on code and examples but not so much so that it falls into the cook-book style of writing. Learning Ext JS is more of an extended tutorial with ample explanation to help the reader not only understand the code but why certain choices are made. Frederick, Ramsay and Blades have done a good job of working through the examples in a concise manner. While the book is the result of group work, it does not have the feeling of being written by a community. I did not run into an abundance of repetition and topics flowed well. Learning Ext JS also covers installation and integration of the library as well as a very quick survey of tools for development. While short these sections would be extremely important to anyone coming into web development with little experience.

It's a quick read, and doesn't delve extremely deeply into more advanced topics. Rather, a reader new to Ext JS will get a launch that should make the library usable in a practical way and also give them the framework to push deeper. The book was written and published just as Ext JS moved between versions. The new version is backwards compatible with the material in this book and a number of the changes in version three would not have fallen within the scope of this book, so it is still a good place to get started with Ext JS. Those who want to dig deeper will need to look elsewhere.

The brevity of the book wont work for those folks who want to really dig down deep into Ext JS. I on the other hand, wasn't looking for a massive tome to lug around and grind through. I was happy to have a very accessible tool that would get me started quickly and that is what I got. On the other hand I do like to be able to find what I need quickly and nothing is more important to me when learning than a solid index. Unfortunately the only really large ding I have for the book is that the index is weak. It would be a lot worse if the book were larger, so the brevity helps here a bit, but it's still unfortunate. This does make the ebook version a little more attractive. Packt will bundle them at a cost that makes the addition of the electronic copy very attractive. That said, the easy flow does it make it easy to read this book front to back while working the examples. Learning Ext JS just wont be my first choice when I need to quickly check a reference.

I've discussed the shallow coverage, but this does not mean that the book is not useful. The Ext JS library bundles enough functionality into the stock widgets, that decent applications could be written with nothing more. Creating custom widgets is covered and extending existing code as well, but this is later in the book. The material prior to that covers not only the use of the provided widgets but how to tie them together, theme an app and then handling data. This means the reader pretty much has everything in hand to build a stock application. The focus is on dealing with these issues on the client side. The examples do include a small amount of back end code when necessary for the execution of examples. All the examples are available to download from the Packt site and come packaged with all necessary scripts, images, etc.

I've always worked primarily with desktop applications. I've done some work with web applications, but it seems to me that increasingly the tools that I use the most are web based. With technology like Google Gears making those applications available whether I'm connected or not they have become much more attractive. Tools like Ext JS make it much easier for me to transition over to this new way of developing applications. I've found that Learning Ext JS has been a valuable resource in taking what is a great resource and allowing me to get the most out of it more rapidly than I would have otherwise.

You can purchase Learning Ext JS from . Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.


This discussion has been archived. No new comments can be posted.

Learning Ext JS

Comments Filter:
  • Re:Boo (Score:1, Interesting)

    by Anonymous Coward on Monday October 05, 2009 @02:49PM (#29647985)

    Why don't you write a book about how to design a proper website that doesn't use any javascript?

    Can you give an example of such a "proper" website? Something with a .gov extension perhaps?

  • by Anonymous Coward on Monday October 05, 2009 @02:53PM (#29648035)

    I was working on a large scale project (with way too much application-like behavior on a web page) that switched from DOJO to EXTJS. We were planning on using their LGPL version at the time. EXTJS actually turned out to be one of the better toolkits out there as far as documentation and clarity in the API went and things were looking pretty good. Then, one day the people behind EXTJS announced a licensing change. This would have been fine under normal conditions, but they claimed that it never was released under the LGPL. They tried some silly technicality where they said it was only released under the LGPL under some other terms. The LGPL itself clearly says any added terms can be removed, but they insisted it couldn't. We had a big enough corporate backing where buying licenses was an option, and was pretty likely as things got closer to deploying, but this really shook us up. These guys totally screwed over a large part of their community. I strongly believe they are wrong about the "never being under LGPL" thing, but we weren't going to be wasting time dealing with lawyers and fighting them. It was a lot easier to drop ExtJS from our project and go switch to another toolkit (eventually YUI). So, anyway, just a disclaimer the company behind EXTJS is EXTREMELY unprofessional, and bad to deal with. They now claim to have a GPL version, but that is only useful if you plan on keeping your code open. A lot of people may think, it's web client code, who cares, but for some of us web client code is becoming more and more like any other application code. So, the moral of the story is, ExtJS is a nice toolkit, but the corporate entity behind it is terrible and will stab you in the eye. Avoid using them at all costs!

  • by cliveholloway ( 132299 ) on Monday October 05, 2009 @03:03PM (#29648151) Homepage Journal
    I have no mod points right now, but hopefully you'll get modded up - great insights - thanks
  • by Kenja ( 541830 ) on Monday October 05, 2009 @03:25PM (#29648437)

    I've been doing a lot of work with extjs for building web applications (business type apps with Domino or Salesforce as the back-end source), and for that its great. From time to time I've looked at using parts of it for web pages and it fails for a couple reasons.

    The big one is that you want to design things from the outside in, with containers in containers and layouts within layouts. Which is perfect for totally controlling the behavior of an entire page to make it look at feel like an application. However, if you just want to put a menu on a page, the container hierarchy becomes cumbersome.

    Course, this is all just my opinion. Can't prove any of it.

  • by amicusNYCL ( 1538833 ) on Monday October 05, 2009 @03:44PM (#29648695)

    That's a nice story, so I might as well give my story too.

    I started using ExtJS when they were using the LGPL. I read through the terms of the LGPL and realized it wasn't really the type of thing I was looking for (our application isn't open source), so I looked into their commercial license. I looked over the terms and price of the commercial license and met with my boss to tell him that this was the library I wanted to use to build our next application, and that the commercial license was a better fit for our plans. He agreed, and we purchased the license. We're a small company, less than 20 employees, but the few hundred dollars for the commercial license was a no-brainer (a few hundred dollars isn't a lot of money for any company to spend on product development).

    We went ahead and also got the support package which gave us SVN access, support forum, etc. During my first several months I posted several times to the support forum and got my questions answered. In addition, like you pointed out, the API documentation is one of the better examples of good documentation (far from perfect, but far more than what a lot of other products have). It took a few months to really get comfortable with everything, but the learning process was easy and the product made sense to use.

    As ExtJS 3.0 rolled around I decided to plug that in to the application and see how it worked. I've got about a page of changes that need to be made to get it to work with ExtJS 3.0, but considering all of the changes that went into the new version it looked like we were eventually going to want to use it, so we went ahead and bought another commercial license for 3.0. ExtJS is using GPL3 now, but that didn't apply to us.

    The core developers of Ext, which are the people running the company, all post in the forum and have all been quite a bit of help with regard to tracking issues and dealing with bugs. They respond to requests for documentation pages, new examples, bug reports etc. I've never thought them to be unprofessional (let alone EXTREMELY unprofessional, in caps), nor "bad to deal with". They are available for communication through the forum, email, and phone.

    For our own application, it now has about 3000 hours of development behind it and continues to grow, and we're just getting ready to begin marketing and selling it. ExtJS has continued to be a good product to use and develop with, and I've got no regrets about choosing ExtJS as the framework for our application.

  • by lkcl ( 517947 ) <> on Monday October 05, 2009 @03:50PM (#29648761) Homepage

    One of the editors of the RIA wikipedia [] page keeps reverting any changes made which make reference to the fact that, overwhelming evidence to the contrary, extensive use of javascript does actually qualify as creating applications that are "Rich".

    it would be very helpful if someone (other than myself) could review the discussion, add references to this book, citing it as an example of how javascript can, if utilised correctly, result in "Rich Media Applications".

  • by hey ( 83763 ) on Monday October 05, 2009 @03:52PM (#29648785) Journal

    Too many JS toolkits!
    Will it ever settle down?

  • by obender ( 546976 ) on Monday October 05, 2009 @04:35PM (#29649371)
    Why did you switch from Dojo to ExtJS? Does the criteria still apply today?
  • by Cyberax ( 705495 ) on Monday October 05, 2009 @04:42PM (#29649485)

    The problem is that the company behind the ExtJS claims that the server-side code tightly coupled to JS code. So it makes it a derived work with all implications.

    Yes, I'm too lazy to search for this statement on their site right now.

  • by Anonymous Coward on Monday October 05, 2009 @05:28PM (#29650375)

    Well, since we're adding anecdotes....

    I have been using GXT (An extjs variant built on top of GWT) for some of my home projects. Personally, I don't care if they're forced to be GPLv3, because I don't mind sharing the source of what I'm working on. I can't help but notice that I've been unable to get the most recent release of GXT (version 2.0.2) since I don't have a support contract with them. They're making the claim that this "patch release" is available in advance of the normal release, though it's been two full weeks since this has been released and the community has seen no public release of their supposedly GPLv3 code. I'm not going to get into the semantics of whether this is supported under the GPLv3 or not because I don't care. Combined with a varying response times in the forums (it took 7 days for an EXT employee to even respond to the question about the 2.0.2 release), this increasingly shady company is putting up all the warning signs it can. As a user actively looking for another Toolkit, I agree with the OP: Stay Away.

  • by amicusNYCL ( 1538833 ) on Monday October 05, 2009 @05:37PM (#29650497)

    You can't know and test for all known web browsers, nor can you test in future browsers that don't exist yet.

    That's correct, but I can update the Javascript framework I'm using, which does get updated as browsers are released.

    Did you know that JavaScript has feature sniffing that is a perfectly viable alternative?

    Of course, as soon as Ext starts using feature checking then my applications will too. Until then, I'll continue writing one piece of code that runs the same in all browsers.

  • by Anonymous Coward on Monday October 05, 2009 @05:42PM (#29650559)

    I'm the original commenter here and I thought I'd respond and clarify a few things.

    1. Why we switched from Dojo

    Someone had asked why we switched. We were on the old (pre 1.0) Dojo, and Dojo had gone 1.x many months earlier. The new Dojo was a rewrite and was very incompatible and immature. It didn't have many of the features we were using in our app, so porting it over was going to be a pain. As we got into another cycle of adding features it became clear that old Dojo wasn't what we wanted to invest in, and the new Dojo wasn't ready for prime time. So, we looked into all the toolkits at the time and ExtJS seemed to be one of the best.

    I will say again, that I really liked ExtJS, and I may even say that it is one of the better toolkits out there. That being said, I can't use it in any of my projects, and I'll explain why in the next section.

    2. It was a stab in the back, and they were unprofessional

    Someone responded with their story and the pleasure of working with ExtJS and how the devs are in the forums, and all that. I was a regular in the forums as well, so and I know a bit about their support, though I never personally have used it.

    I work for a large company. GPL code is not an option, but LGPL is. Even so, when code is entering production we would almost definitely get licenses and support contracts, just because that is the way it is done in large companies. The LGPL was fine for development, and so we used it.

    The license change was a big deal. Sure, if you were a commercial user already it had no impact on you, so it is easy to say it wasn't a big deal, but if you were a community user things were different. Suddenly, these guys were claiming that it never was under LGPL unless you met their terms, and they were explaining a far more strict version of their terms than their terms read to anyone. They were ignoring clauses about the terms and reacting fairly harshly to people who argued. I wasn't the only one who was pissed off. A large amount of the community was. At least 3 "forks" appeared in the next few weeks claiming to be forks of the LGPL version, though their legal stance is questionable because of the absurd "it never was LGPL" claims.

    Here we were, developing a large scale app integrating with their stuff, and the company goes and does something that pissed off a huge amount of their community. Yeah, we were going to go with the commercial license eventually, but now we had to rethink. Did we really want to deal with a company that played games like this? Did we really want to deal with a company that hurt its users like this? We were hurt by it. It cost us many hours, but we decided to abandon our ExtJS version and move on to a toolkit from a more professional and open backing. (YUI) I miss ExtJS, but I'm not going back to it. They screwed us over and their community. I don't want to work with people like that.

    3. Web apps can be closed source
    A few people have replied that web apps can't be closed since you have to send the source. I know this is a common argument, but things are changing. Web apps are really becoming apps now. Look at the speed improvements in FF3.5 and Chrome. Things are changing. The days of believing that JavaScript implies openness are ending. As the apps get bigger companies are going to be protecting their code, and not just by copyright. There will even be algorithms in the JS that they want to protect. They may be limited to obsfucation as a technique, but that can be pretty decent. I think the people who believe that JavaScript is open since you are sending the source will be changing their minds in the next few years as people do incredible in browser things that took them a lot of time to do, and want to protect their assets.

  • by mgkimsal2 ( 200677 ) on Monday October 05, 2009 @08:33PM (#29652165) Homepage
    Why the switch away from Dojo to ExtJS in the first place, if you don't mind my asking? And why not move back to Dojo instead of YUI?

Competence, like truth, beauty, and contact lenses, is in the eye of the beholder. -- Dr. Laurence J. Peter