Slashdot Mirror
Learning Ext JS
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.
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.
I suppose it all depends on what their licensing terms are today at this given moment.
"My God...it's full of trolls!"
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!
Yes, 99% of websites "on the Internet" could perform their current functions without javascript. You're right.
The question is: of those websites, how many of them do their current functions better than if they didn't have javascript?
This is not a question of whether or not it "can work" without javascript; it's a question of whether or not the user interface, user experience, functionality, etc., is enhanced through javascript.
The argument that "it was working without javascript!" is a very poor one. Operating systems worked without GUI's. Typewriters worked without "edit" mode(s). Transcribers worked without word processors. For that matter, computers worked without monitors!
The question is, again ... is it better (or worse) with javascript/ajax/whatever. If it's better, then why not? If not, then you have a point.
Arguing that it "could" do it without is silly. In my experience, there are some site functions that are vastly improved with something like ajax... for example, being able to upload a file while filling out a form and and not having to wait for the upload to finish before pushing Submit on the form. Or making sure you do the form first and then the upload. Or having to do the upload at hte same time as the form. It can improve efficiency by allowing you to do two things at once. Multitasking on a site without javascript or some scripting thing would be more difficult. Unless, of course, you use frames, or something like that. But 99% of the websites on the Internet could perform their current functions without frames.
Meh. 99% of the websites on the Internet don't need to exist. ;)
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/ ). 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.
Having had to work with EXTJS and its controls where I work, here's what I think.
-- R. Bemrose. With apologies to Jamie Zawinski.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Alongside websites, there are lot of Enterprise applications (frontends) moving to JavaScript, simply because deployment (including upgrades) to thousands of clients is so easy.
839*929
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.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
I'm waiting for EXT3.11 for workgroups before upgrading.
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".
"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.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Too many JS toolkits!
Will it ever settle down?
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 and Pyjamas 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), walking the top-level looking for classes and functions of the same name, and merging them. the resultant "munged" AST is then passed to the compiler, and used to spew forth javascript. the process is repeated for each of the five platforms.
this "trick" is actually something that even the developers can take advantage of. see browserdetect for the absolute most basic example (source code 2 levels below).
Slashdot, for instance?
I much prefer the old interface.
In my experience, most sites don't enhace anything, they rather make it more annoying.
For instance, various sites with images now do this annoying thing where clicking an image makes a sort of modal window appear in the middle of the page, expand and show the photo. Yeah, fairly cool looking for about 5 seconds. Then it becomes very annoying because the effect wastes time, and it typically breaks the "open in new tab" middle click function, which makes it hard to show the image to somebody else.
I actually changed the place I shop for computer stuff at because of issues like that. The shop I use displays all the products in a category in a plain table, which can be sorted by any column.
IMO, the functionality can be used well, but rarely is. Pretty much anything that makes something like AJAX the main focus of the site overdoes it and ends up making it horrible to use.
Though I'll admit I don't like the whole concept of web applications in the first place and generally avoid using anything that looks like one.
The argument for many companies to need IE6 is that existing intranet applications would break if they moved to another web browser (version). Now I'm reading that you're making a new intranet application for IE6?!
We'll never get rid of this pest at this rate. Though I guess it's a good thing that you're keeping other web browsers in mind, too...
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 a perfectly viable alternative that's called feature sniffing.
Slashdot, for instance?
I much prefer the old interface.
This is the rallying cry of the anti-Web-app crowd. "I liked the good old Internet."
The problem is that the good old Internet kind of sucked.
Look at the original MapQuest vs. Google Maps. I spent large amounts of time trying to find things on MQ back in the day. When Google Maps came out, it changed the way mapping worked. Dragging the map around to pan alone was worth having to suffer slow (now much better) JavaScript interpreters. Now, of course, MQ uses a Google Maps-like JavaScript UI for that very reason.
The issues you raise are valid, and I think we're about to exit the age of one-off JavaScript UIs for that very reason. Some standardization needs to take place in order to bring back the sense that knowing how to use "the Web" means that you know how to use any given Web page, even if the domain-specific information on that page might not be comprehensible to you. Things like opening a link in a new tab (Gmail, I'm looking at you) are very important, and should be well supported. On the other hand, as a publisher, I want things like the image-popup you mentioned because it allows me to publish images in a way that maintains my site's flow (e.g. the ability to navigate to the next image in a set, comment on an image, and so on). These features need to be revised, smoothed and made more friendly to the kinds of browsing that people do and the way they expect their browser to behave, I agree, but throwing away the JavaScript UI isn't the way to do that.
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.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
I'm currently working as a contractor at a large company on a project that has three different web front ends for portions of the application. One is written in ExtJS, the other two are mainly straight HTML with some MS-Ajax controls. To be honest the ExtJS one is probably the most well-liked, it's slick and works well. The down side is too few of the other developers have the skill or inclination to come up to speed on using JS well enough to be proficient in the front end development of this application.
It's pretty sad, but the more advance web front ends get, the fewer people that are proficient in both the front end scripting as well as the backend, at least the communications layer. In this case it's using a WCF webservice backend, and the generic MS JSON Serializer. I've been about the only person working on this part of the set of applications since I started as a result.
Michael J. Ryan - tracker1.info
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.
A web browser is a tool, both for the user of the websites in question and the developers. As a professional web developer, I would prefer everybody perfectly and identically implemented all standards. That's my mentality; it would make things much easier for me. That said, while it's a shame that things are implemented so differently in different browsers, it won't prevent me from supporting them in reasonably up-to-date browsers if it's feasible to do so. "Reasonably up-to-date" at this point means IE6 or better to me. If somebody really, reeeeally wanted IE 5.5 support I would probably agree to it -- but they're going to pay for every last extra minute it takes, and that's probably going to be a lot of money.
Why? Because "I don't give a crap as long as it works in MY browser" is so much more reasonable?
We're web developers. Our job (and in my case, my passion) is to create things that help people get things done, not to change the world. It would be awesome if some things were easier and/or more consistent across browsers, but to give people an inferior product because it takes extra work doesn't help anybody and doesn't progress anything.
Life isn't a fairy tale where everybody does the Bestest Thing Evar(tm) all the time. It's hard enough to keep an income stream when you're competing with people from India working for fractions of what you do without outright refusing work because they won't let you play to your pet projects. SOMEBODY is going to be doing the work, that's the reality of the world and of the capitalist system in general. So long as an employer/client can simply replace me by going to the next guy in the list, I have no power to change how fast outside organizations develop and implement standards. Wishing doesn't make it so.
Like pretty much everything else in life, it's a trade-off. Or to steal one of those evil business terms, a cost-benefit analysis. Two years ago, refusing to support IE6 would have shut out 34% of potential customers. One year ago it would have been about 20%, and today it would be around 12%. Two years ago it's a no-brainer to support it, pretty much regardless of how much time it takes. Simply turning away one in every three potential customers that come to you isn't going to get you anywhere. Today, it's not as clear.
Why do you feel this incredible need to consistently resort to hyperbole as if there aren't reasonable intermediary steps? Nobody is going to develop for IE3 or Mosaic; the differences (and thus costs) are too great and the benefit too small. These days, pretty much no client I've come across even cares about IE 5.5. They do care about IE6, for now. Maybe not next year. What's unreasonable about that? Particularly if there are enough people out there who care that they develop things like, oh I don't know, JavaScript libraries that abstract away the differences for me?
For starters, most of these comparisons are pretty lame.