Forgot your password?
typodupeerror
Books Book Reviews

Learning Ext JS 133

Posted by samzenpus
from the read-all-about-it dept.
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 amazon.com . 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:
  • by Infernal Device (865066) on Monday October 05, 2009 @02:47PM (#29647953)

    I suppose it all depends on what their licensing terms are today at this given moment.

    • Is a ridiculously easy way to present your data in a "prettified" form. The ExtJS forums are full of useful advice and code samples. As for the licenses: http://www.extjs.com/products/license.php [extjs.com]
    • They've pretty much gone down the path of GPL + Commercial split that a lot of tools have. I really think mySQL was the first widely used one to follow this path, and ExtJS kind of has the same viewpoint. I know there's a lot of criticism here, but it's a pretty fair set of options imho. I think I was much more critical of the mySQL view of their database drivers. Though I don't have any plans of using ExtJS in a commercial app for redistribution that wouldn't be GPL in nature.

  • Bah. I already use EXT3 (and I am planning to migrate to EXT4). What could this EXTJS have more?
  • 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!

    • Re: (Score:3, Interesting)

      by cliveholloway (132299)
      I have no mod points right now, but hopefully you'll get modded up - great insights - thanks
    • by tukang (1209392)

      They now claim to have a GPL version, but that is only useful if you plan on keeping your code open

      You probably already know this but it's worth mentioning that under the GPL you're only required to share the code with people who use it (i.e. execute the code), so if you only use it internally or your customers only use the web output you don't have to share it with anyone.

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        Are you sure? If you distribute an application you have to share the code under GPL. If you distribute the JS, even in an obsfucated state, aren't you distributing the application? They are running code on their browser. They got it from somewhere. I would think that qualifies as distribution, and therefore they have the right to the source. Please, correct me if I'm wrong.

        • by ASBands (1087159)
          I believe this is relevant:

          The "source code" for a work means the preferred form of the work for making modifications to it.

        • by AlXtreme (223728) on Monday October 05, 2009 @03:53PM (#29648803) Homepage Journal

          They are running code on their browser. They got it from somewhere. I would think that qualifies as distribution, and therefore they have the right to the source. Please, correct me if I'm wrong.

          You are correct: you are distributing the GPL code, you would have to put the javascript code you wrote under the GPL as well. This is the reason why most javascript libraries go with the BSD license or LGPL.

          Then again, you are distributing your own code ("proprietary" or not) anyway.

      • So, none of that applies. However, claiming you OWN javascript is as silly as claiming you own HTML. Just accept that if it is worth copying, someone will and make your application depend on the service it delivers, not the code itself.

        • I was thinking the same thing. But then again, HTML and CSS is fairly simplistic compared to Javascript (yes, I know HTML and CSS can get hairy if you need to do certain things). Javascript requires a lot more thought, design, and good old fashioned programming skills. I too think it's silly, but I can also see how someone might feel that a huge library like EXTJS, jQuery, etc, could be more than just some client-side plain text file.

          I think as we see more logic embedded within javascript, and thus more

      • Re: (Score:3, Interesting)

        by Cyberax (705495)

        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.

    • Re: (Score:3, Insightful)

      by tomhudson (43916)

      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.

      There's one important difference.

      Web client code, by its' nature (it has to run on the client) isn't something you can hide. Any obfuscation can be de-obfuscated given enough incentive (and the fact that you've tried to hide it is "incentive enough" for some people). They HAVE to have the source to run it. (and this ignores the whole "performance hit

      • by Qubit (100461)

        Web client code...isn't something you can hide. Any obfuscation can be de-obfuscated given enough incentive...They HAVE to have the source to run it.

        To build on what someone else said, just because a user is given the obfuscated code doesn't mean that the application writer/hosting company has fulfilled all of their GPL obligations.

        For example, let's say you take the Ext JS (using a GPLv3-licensed copy), build an application A on top of it and throw it up online. So A is a derivative work and thus must be GPLv3-licensed as well.

        If a user U loads one of your web pages and in the process downloads a local copy of A, then not only do you need to provide a

        • by tomhudson (43916)

          Good point wrt the gpl and obfuscating code.

          Two points:

          1. if your code only calls functions in the library, you only need to provide a copy of the library (at no time is the library linked, either statically or dynamically, to your code);
          2. the library is dual-licensed, so people who buy and deploy the commercial version don't need to give anything

          That being said, I think the whole idea of trying to obfuscate javascript is self-defeating. The real gravy and meatballs, crown jewels, etc., is the stuff (dat

          • by Haeleth (414428)

            if your code only calls functions in the library, you only need to provide a copy of the library (at no time is the library linked, either statically or dynamically, to your code);

            This is plausible, and quite possibly true. But there are GPL advocates who would argue that loading your code into the same JS interpreter as the library is equivalent to linking.

            The fact that the library's authors have dual-licensed it suggests that they take this harder line, since what's the point of a commercial license othe

            • by tomhudson (43916)

              "Linking", under the gpl, refers to compiled code only.

              The point of the commercial license is because people will want to modify the library, not just access its' functions. At that point, they would have to make the mods available under the gpl ... which means in unobfuscated form.

              If you're going to use a library, and you're going to modify it, why not share the benefits of your mods, and reap the benefits of other people fixing any bugs you may have introduced?

              • by Qubit (100461)

                "Linking", under the gpl, refers to compiled code only.

                Linking, perhaps yes. But as for being a derivative work? Well, I googled around and couldn't find a definite answer on this point. There's a thread on stackoverflow [stackoverflow.com] that provides some commentary, but doesn't give a definite answer as to whether a javascript program that calls into a javascript library is a derivative work. There's also some commentary on Rock Star Apps [rockstarapps.com]. Amusingly, this same question was brought up in an article last year about ExtJS moving to the GPL [slashdot.org].

                The upshot? I wouldn't bet any money ei

                • by tomhudson (43916)
                  You don't need to assign copyright to contribute code you want to GPL. As a matter of fact, it's best if you keep copyright, so that nobody else can monkey around with the licensing terms (remember the dust-ups a few projects have had when copyright assignees tried to restrict later versions over the original authors' objections ?)

                  "This code copyright the author date email yadda yadda yadda. Licensed and distributed solely under the terms of the General Public License (GPL), version $WhateverFloatsYourBo

                  • by Qubit (100461)

                    You don't need to assign copyright to contribute code you want to GPL.

                    Sure.

                    If I want to make some improvements to a GPLv3-licensed copy of ExtJS, then I could just make some patches, throw my name under the copyrights, and distribute them online, say on Gitorious [gitorious.org].

                    What I was saying is that if you want the upstream developers (Ext, LLC.) to merge these patches into the main development trunk, I'd assume that they'd want copyright control so that they could distribute them in both the GPLv3'd version and their proprietary-licensed version. If they didn't require the copyright as

                    • by tomhudson (43916)

                      On a side note, there are a lot of developers who think the FSF is a bit stuck-up/control freakazoids/whatever because they insist on copyright assignment as a precondition for inclusion in the gnu toolchain.

                      As for proprietary vs gpl works:

                      What I was saying is that if you want the upstream developers (Ext, LLC.) to merge these patches into the main development trunk, I'd assume that they'd want copyright control so that they could distribute them in both the GPLv3'd version and their proprietary-licensed

    • 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 ojintoad (1310811) on Monday October 05, 2009 @04:05PM (#29648939)

        Mod parent up.

        The LGPL debacle was a single instance. Many people put way too much weight on it than necessary - if you look at the entire history of the company, they have been extremely responsive and credible. My company's story shares many commonalities with the above. I have worked with extJS back when it was called yui-ext, so named because it was an set of add ons to the Yahoo User Interface libraries. Jack Slocum was a responsive, dedicated developer back then, and remains so to this day. For a long time he developed widgets in his spare time, and once demand was high enough and he wasn't getting compensated for his time enough he decided to monetize it. As with any business, there are growing pains and mistakes that get made, but to describe the licensing change as a stab in the back is hardly accurate.

        • Re: (Score:1, Interesting)

          by Anonymous Coward

          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 b

          • by kobaz (107760)

            We've been developing with Ext for some time now. We came across GXT and it looked interesting. We looked into it some more, and it looked like a bunch of sillyness. Why would you write your web app in Java, using a custom compiler, that outputs Javascript?

            Why use an interface to an interface, if the interface doesn't make it any simpler or easier to code. That's the whole point of an interface isn't it? To abstract complexity so the developer has to do less work?

            What if you find a bug in the Javascrip

    • 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 cripkd (709136)
        I've never used Dojo, so I can't argue regarding code/APIs, but when it comes to widgets and ready made bits that make an app what an app is to a user (a nice consistent interface that he or she uses to get things done) I haven't seen anything that compares to Ext. Dojo has too few widgets and lets admit it, they are ugly, jQueryUI doesn't look as consistent and again, only small cute stuff.
        Aside Ext no one seems to have a vision in terms of what a complete UI needs.
    • Re: (Score:1, Interesting)

      by Anonymous Coward

      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 i

      • "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."

        Unless said companies put pressure on browser makers to somehow re-engineer their javascript engines, who cares?

        Just because I want to use a hammer to do some soldering doesn't mean it's the right tool for the job. If you want business logic to be kept hidden, then javascript isn't the tool for the job. That's what server-side scripting is for. When did peo

      • 3. Web apps can be closed source

        Sure...

        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.

        If you send javascript code (obfuscated or not) to the browser, then users can take a look at the code and might try to reuse it. If the code is not licensed for end user reuse, then it probably won't be used as much, but people might still try.

        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.

        I don't think that anyone ever believed that all JavaScript code was open-licensed. Admittedly, most of the JavaScript in the past was just snippets here and there for various widget tricks, and so people didn't as aggressively defend their proprietary develop

    • Re: (Score:3, Interesting)

      by mgkimsal2 (200677)
      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?
    • by Qubit (100461)

      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.

      As you point out, the LGPL 2.1 [gnu.org] (to pick an older version of the LGPL) states:

      You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

      Wikipedia's blurb on the licensing problem states:

      the authors claimed Ext was available under an LGPL license as long as you "plan to use Ext in a personal, educational or non-profit manner" or "in an open source project that precludes using non-open source software" or "are using Ext in a commercial application that is not a software development library or toolkit".

      Obviously, not everyone believes that this stance is legally defensible. As you state,

      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.

      Next time, toss the question over to the Software Freedom Law Center [softwarefreedom.org]. Even if you personally don't want to go forward with the issue, I feel like the SFLC is great at trying to resolve questions like this so that developers can just write code and leave the legal issues for the lawyers. They're rea [identi.ca]

  • Another Book (Score:5, Informative)

    by KingK (148438) on Monday October 05, 2009 @03:09PM (#29648243)

    I've been using Ext JS for a little while now and when I went looking for books I saw the reviewed book and another one titled "Ext JS in Action" ( http://manning.com/garcia/ [manning.com] ). I ended up choosing the latter. While it is still in the process of being written the publisher has a early access program that allows you to get the chapters as they are written. I would definitely recommend the book to others interested in learning Ext JS.

    • by fzammett (255288)

      And I wouldn't be doing my job if I didn't point out "Practical Ext JS Projects with Gears" from Apress:

      http://apress.com/book/search?searchterm=zammetti&act=search&submit.x=0&submit.y=0 [apress.com]

      Yes, I'm the author... I have kids to feed too :)

    • by mgkimsal2 (200677)
      And both Frank Zammetti (posted a comment below) and Jay Garcia (the one you mentioned) have contributed pieces to JSMag about ExtJS :)
    • by VinylFox (1650699)
      If you the kind of programmer that wants to know every single detail of the ExtJS library up front, Jay's ExtJS in Action book will work very well for you. If you want to get up to speed fast and fill in the details yourself, then my Learning ExtJS book is more suited. Depends what your learning style is. I cant say anything about the other books on ExtJS, as I haven't read them.
  • by VGPowerlord (621254) on Monday October 05, 2009 @03:23PM (#29648411) Homepage

    Having had to work with EXTJS and its controls where I work, here's what I think.

    Some people, when confronted with a problem, think "I know, I'll use EXTJS." Now they have two problems.

    -- R. Bemrose. With apologies to Jamie Zawinski.

  • 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.

  • 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.

    Why not just refuse to use non-standard features, browser sniffing, etc. Accommodating multiple broken browsers just perpetuates the "we don't need no stinking standards but our OWN!" mentality. We've seen

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

      "But my customers want it to work in their browser!" is not an argument when better browsers are freely available.

      Really? When your customers contact you about this or that not working right in IE, all you tell them is to use a different browser? Don't you think that's a bit lazy?

      How "standard" is a "standard" if people aren't following it?

      It's pretty bad when more than half the time ona web project is "fixing" broken IE rendering.

      Oddly enough, the exact reason I don't have to spend a considerable amount of time debugging IE is because I use a library that is cross-browser compatible, because of things like browser sniffing. My time spent debugging problems in IE has dropped significantly since starting with ExtJS.

      • by BenoitRen (998927)

        Browser sniffing doesn't solve the problem. It only moves the problem elsewhere. You can't know and test for all known web browsers, nor can you test in future browsers that don't exist yet. Did you know that JavaScript has feature sniffing that is a perfectly viable alternative?

        • Re: (Score:3, Interesting)

          by amicusNYCL (1538833)

          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 tomhudson (43916)

        "But my customers want it to work in their browser!" is not an argument when better browsers are freely available.

        Really? When your customers contact you about this or that not working right in IE, all you tell them is to use a different browser? Don't you think that's a bit lazy?

        No, it's the mirror image of "This site is best viewed^W^Wonly works in IE." What's sauce for the goose is sauce for the gander. Simply tell the customer to search for "Internet explorer is a steaming pile of crap" and that

        • Simply tell the customer to search for "Internet explorer is a steaming pile of crap" and that, while Microsoft is working towards a version that is standards-compliant (or at least standards-compatible - NOT the same thing), they still have a ways to go.

          In my experience if you tell a customer that you can't/won't fix a problem, they just go to someone who can/will. It doesn't matter to the customer why the problem exists, they just want it fixed. As a developer you should be able to do that for them. If you're not willing to do that, well...

          ... and if you code only to the standard, your time spend debugging problems in IE will be zero. At the very least, dropping support for anything prior to IE8 (and especially ignoring IE6) is sensible.

          I'm sorry, but I just think it's a ridiculous premise for a web developer to block out support for the majority of internet users. Doubly so when the only reason they're blocking support is because of misplaced ide

          • by tomhudson (43916)

            And sometimes idealism pays off. Refusing to waste time accomodating IE6 ended up with me having oone of those "discussions" with the boss. After 2 months, he backed down, because I was right - his customers were dropping IE6. Being a lead means more than just doing what you're told. It means having an overview of the customers, the market, trends, and the needs,

            It also means knowing what to cut. IE6 compatibility was the "what to cut" then. IE7 is the "what to cut" today. Don't even bother testin

            • It also means knowing what to cut. IE6 compatibility was the "what to cut" then. IE7 is the "what to cut" today.

              I just think that's a ridiculous stance to take. Depending on which set of stats you're looking at, either IE6 or IE7 is the current #1 browser. I see IE6 at between 16%-24%, and IE7 at between 20%-25%. So at a minimum that represents 36%, at a maximum nearly 50%. You're saying that you want to eliminate 36%-50% of your potential market, just because you don't want to spend the extra effort. That doesn't make a lot of business sense to me, to willfully cut the number of your potential customers in half

              • by tomhudson (43916)

                You are the victim of a false either-or mindset. Most people have access to multiple browsers nowadays. It's not like it costs anything. How many computer users do YOU know who have only IE?

                If they've got an iPod, they've probably also got Safari.

                If they're at all computer literate, or know someone who is they've also got firefox.

                If they're into trying new things, they've got chrome.

                So while they might still have IE6 or IE7, it's not the whole story, and not supporting the old versions doesn't s

                • It sounds like you're assuming I just came up with all of this stuff. The reason I think this way is because of what I see in reality. We have several major corporate clients who are still using IE6 or IE7, this isn't some edge case scenario that I'm just theorizing about. I'm not going to go to one of our major clients with a "no open-source" policy and tell them to upgrade their entire IT infrastructure, rewrite their internal web applications, and change the way they think just because I want to do le

                  • by tomhudson (43916)

                    just because I want to do less work

                    That's NOT the reason. Talk about missing the point.

                    1. Quality: it's easier to produce quality with code that only has to meet the standards, and not diddle around with obsolete browsers.
                    2. Maintenance: 90% of the cost of software is maintenance. Standards-compatible code is cheaper in the long run.
                    3. Speed: quicker to produce, and quicker at run-time, if you just stick with the standards rather than trying to cover all the bases

                    Then there's the whole ethics question.

                    • Supporting IE6 has exactly zero to do with ethics, this is not a question of what is morally right and wrong. The fact is that I have customers using IE6. So my options are to 1) support IE6, or 2) lose customers. Ethics don't even come into the picture. I can cherry-pick my customers and only take on people who are up to date, but like I've been saying, considering the fact that I do essentially zero extra work to support IE6 at this point, there's not even a question about whether or not to support th

                    • by tomhudson (43916)

                      The fact is that I have customers using IE6. So my options are to 1) support IE6, or 2) lose customers.

                      ...

                      they can choose to migrate if they want to.

                      ... so why is "helping them migrate" not an option?

                      What, you don't want to get paid for providing that sort of useful, and over the long term, money-saving help?

                      Ethics don't even come into the picture.

                      ... only true if you have none.

                      If you acknowledge that exploits that allow for system compromise and exposure of private data are more likely in envi

                    • so why is "helping them migrate" not an option?

                      Let me put things into perspective. I'm a developer working for a small company, less than 20 employees. Several of our clients have tens to hundreds of thousands of employees. These include organizations like Choice Hotels [choicehotels.com], Avnet [avnet.com], and the US Air Force. Now, you expect me, one of two developers at a small company, to approach a client like Avnet or the Air Force, and try to dictate IT policy to them? Like they don't have an IT staff who already knows everything I might tell them? Avnet is a technology

                    • by tomhudson (43916)

                      Now, you expect me, one of two developers at a small company, to approach a client like Avnet or the Air Force, and try to dictate IT policy to them?

                      No, I expect you to see the opportunity, show them the lower costs and better security, make some nice presentations, and use that to enhance your stature in their eyes so that the next time they get p0wned, some PHB has a knee-jerk reaction and says "Call this guy - he warned us about this!"

                      It's called playing politics, and you have to play the game to get

                    • No, I expect you to see the opportunity, show them the lower costs and better security, make some nice presentations

                      Have I mentioned that I'm a developer? I develop software. My job is to design and implement applications. I have zero interest in creating a presentation about the dangers of using IE and flying across the country to deliver the presentation to someone like the Air Force. The company I work for does not implement or manage any type of communications or IT infrastructure. The core business of this company is creating online training courses, and I write the software that makes them run. It is my job t

      • by ignavus (213578)

        "But my customers want it to work in their browser!" is not an argument when better browsers are freely available.

        Really? When your customers contact you about this or that not working right in IE, all you tell them is to use a different browser? Don't you think that's a bit lazy?

        Many users have no choice about the browser they use. Corporations lock down desktops and prevent users from upgrading or installing any software. I know organisations that haven't upgraded from IE6, leaving their employees stuck with poor quality browsers. The organisation is lazy - especially as they have locked their employees into browsers with inferior security - but that is not the employees' fault.

        So it is not just lazy to tell your users to use a different browser - it is very unfair: it is often bl

        • That's correct, that's why it makes a lot of sense to use a Javascript library that does browser-checking automatically. If I use ExtJS to create a draggable, resizable window layer, I know that it will work in all (relatively modern) browsers.

    • Why not just refuse to use non-standard features, browser sniffing, etc. Accommodating multiple broken browsers just perpetuates the "we don't need no stinking standards but our OWN!" mentality.

      the existence of dynamic framework compilers such as Google Web Toolkit [google.com] and Pyjamas [pyjs.org] makes it perfectly possible to accommodate "multiple broken browsers".

      in the pyjamas case, the result of the compilation command is no less than FIVE completely separate applications: one for each (wildly incompatible) browser. user-agent string detection then redirects at run-time to the correct application.

      this is just a "merging" trick that is applied at compile-time, by taking two ASTs (python abstract syntax trees), wa

      • Re: (Score:3, Insightful)

        by BenoitRen (998927)

        in the pyjamas case, the result of the compilation command is no less than FIVE completely separate applications: one for each (wildly incompatible) browser. user-agent string detection then redirects at run-time to the correct application.

        And this is the problem. Web browser sniffing is bad, because it duplicates code and breaks lesser-known web browsers because you can never test in all of them (including future browsers). It's the new version of "Best viewed in My Favourite Browser(TM)". While there is

    • Re: (Score:3, Insightful)

      by Dhalka226 (559740)

      Why not just refuse to use non-standard features, browser sniffing, etc.

      A good developer uses them for the same reason they use anything else that isn't technically essential: To improve the experience. Granted, a lot of people do things for a lot of bad reasons, but that's another issue.

      Accommodating multiple broken browsers just perpetuates the "we don't need no stinking standards but our OWN!" mentality.

      A web browser is a tool, both for the user of the websites in question and the developers. As a pr

      • by tomhudson (43916)

        All your points are based on a faulty premise - that requiring people to use a standards-compliant browser is somehow denying them access.

        It's not. They're free to make the choice. There's no financial cost involved, and this decade, the people who have switched have also benefited from better security, so no downside, and a decent upside. But if people don;t want to use a particular browser, that's their choice - and one that I don't have to waste time accomodating.

        The browser is just a tool - anyo

  • Does anyone know if this book has a chapter on the feasibility of software testing with Ext JS? I'm a RoR developer and make heavy use of cucumber and rspec and wouldn't have problems switching to most of my non-spec tests as sellenium tests instead if it isn't too much of a PITA.

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

    One of the editors of the RIA wikipedia [wikipedia.org] 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 diodeus (96408)

      The same argument could be made for server-side languages.

      Who cares, just use the one you like.

  • But but.. silverlight will solve all these problems and more, no?

    NOT!

    • But but.. silverlight will solve all these problems and more, no?

      Since you tongue-in-cheekily asked, just some of them. :)

      It's a hell of a lot easier/faster to make a good/responsive/pretty web UI in Silverlight than by dicking around with JavaScript libraries. Obviously, that approach also has other downsides. Depending on what you're doing they may or may not matter.

  • and I think it's fantastic. It is an excellent platform for putting together a web application. The support forums are great, and on the rare occasions when I need to use my purchased support, the ExtJS guys are very prompt and helpful.

    • by Yosho (135835)

      For what it's worth, I agree. I've been working on an enterprise project that's deploying a web-based application, and around a year ago we switched our project from using home-grown widgets to using Ext. The library is fantastic; it's honestly one of the best GUI toolkits I've ever used (and off the top of my head, I've used at least MFC, Swing, Qt, Carbon, and wxWidgets).

      On top of that, I hate Javascript. It's one of my least favorite scripting languages; the only thing I can think of offhand that I li

  • I, like the original poster enjoyed the book, but I might be biased. Lets keep it on topic, if you want to discuss licensing, there are better places for that.
  • Our entire front end is ExtJS. This means MUCH EASIER porting a whole web app based (SIGH) on Grails to something less craptastic like Rails, Django, or anything else that is good at emitting JSON. It's not as easy to get started with... because you're starting with high-level widgets like controls, panels, and similar.

  • FWIW I was planning on using ExtJS in the beginning and got hurt too. They sounded insane the way they were changing the liscense. I spent a lot of hours trying to figure it out and wrestling with do I want to do it or not, and it would have been a nice demo for a small but quite useful site and they could have used to promote their project.

    In the end when it all settled out my conclusions were:
    - If willing to give up the front end to them, then fine
    - Not at all willing to accept any idea of "tightly bundle

The sooner you fall behind, the more time you have to catch up.

Working...