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!"
Can you give an example of such a "proper" website? Something with a .gov extension perhaps?
Bah. I already use EXT3 (and I am planning to migrate to EXT4). What could this EXTJS have more?
My first program:
Hell Segmentation fault
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.
And tell me what I want for lunch today please!
Oh, that's too easy. McDonald's, Mr. mcbutterbuns. ;)
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.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
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
We don't want rich internet applications
Who do you think you're speaking for?
even if they're rich, the quality is poor
Really? All web applications are poor quality?
The 1% have functions that no one wants
Maybe that's what your AC wisdom is telling you, but here in reality I've got customers paying good money for those functions "that no one wants".
You can keep designing and selling your "pure HTML" web sites, as long as that makes you happy keep doing it. I'm happy making attractive and functional web applications, so that's what I'll continue doing.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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
It's BIG
They also have Ext Core available, which is all of the DOM/Ajax/Data components and none of the GUI components.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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?"
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 IE being forced to move towards standards compliance because of the growing market share of Firefox, which was closer to the standard.
"But my customers want it to work in their browser!" is not an argument when better browsers are freely available. What next - make a version that works for IE3 or Mosaic because someone is still running WFW3.1?
We benefit from standards for everything else - electricity, water, sanitation, food, health, ram, tires, gasoline, soda pop containers, air quality, asbestos, drugs, alcohol, etc. - and yet in this one area, we tolerate immaturity. Why? Because too many devs don't want to have to learn the standards, and too many project managers don't have the guts to tell their bosses that compatibility with an incompatible browser is not the most effective allocation of resources.
It's pretty bad when more than half the time ona web project is "fixing" broken IE rendering. That time could be better spent making a better product, rather than making the existing product bloated and more bug-prone.
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
"Be prepared, son. That's my motto. Be prepared." --Joe Hallenbeck
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.
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?
We're actually working on one at [I'll omit company name]. The only problem is that the browser the users will be using will be IE6 (not by our choice)... It's a pain in the ass coding for that thing! Naturally, our app still runs well on all browsers, but IE6 was just a pain to code for!! :(
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).
I suspect the post author didn't name his account "stoolpigeon" for nothing. Packt have a history of publishing crap books on every new technology, presumably to make money on the burgeoning interest asap. They've approached me numerous times, trying to get me to review their books, simply because I have a popular blog and can get them extra publicity for their wares.
But but.. silverlight will solve all these problems and more, no?
NOT!
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.
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.
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...
Businesses want those cool functions to be cool like everyone else. That doesn't mean that the actual end-users that end up using the site think they're neat.
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.
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?
Maybe so, but I'm referring to features in web applications here, not "sites" with "neat" things. The corporations who buy my software most certainly do want those features, or else they wouldn't pay me to write them.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
Slashdot, for instance?
Is that a fault of javascript/general asynchronous model or a fault of the particular Slashdot implementation, though?
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
Agreed, they can be annoying. On the other hand, I've seen some fairly well-done thumbnail scripts where hovering them makes the thumbnail blow up a little bit, but clicking it functions like you would normally think (opens in a new window or tab or whatever you want, just a normal link). Again, this seems to be an implementation specific issue... albeit a big one... heh. One pet peeve of mine are all-flash sites which tend to be very common amongst artists and composers. Flash is pretty handy for playing compositions in the page, but when the entire page is flash, it's sooo slow to use. Implementation is bad; technology/possible functionality isn't necessarily.
Pretty much anything that makes something like AJAX the main focus of the site overdoes it and ends up making it horrible to use.
If the focus is "AJAX Bling, yes. If the focus is functionality, it can be really great. One example I was just using is being able to edit comments on real estate properties inline with the listing of "favorites." Saves having to open each one in a new window, edit comment, click save, etc.
On the other hand, I very much appreciate AJAX trees. It's nice being able to update the a tree of items that might have gotten edited by another user without having to hit refresh and lose the work I was doing. The newer version of TestLink uses an AJAX tree for testcases. First off, the expanding tree version is incredibly nice when you have hundreds or thousands of testcases to sift through. Secondly, the AJAX bit makes the page load way faster when you have the aforementioned Large Number (tm) of testcases.
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.
People are following web standards. It's Microsoft that doesn't.
Exactly which standards are the -moz-opacity and -khtml-opacity CSS properties defined in? If I want to support opacity in IE, Firefox, Safari, and Opera, why is it that I need to use 4 CSS properties? Is that Microsoft's fault also?
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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
No bro, using SharePoint is a bit more crazy... lovely viewstate + core.css + shit lots of postbacks for any click...
Depending for what kind of use. If you want to make apps on it, indeed it did. But I don't want apps, so the current one sucks more for me.
Actually I vastly prefer a map implemented as an application.
Google Maps works in an emergency, but it's annoying. Sometimes a square won't load for some weird reason. It never loads the squares beyond the borders fast enough to scroll comfortably. It definitely never loads images for any zoom level other than the one you're at. On a slow connection, it's unberable to use.
Even crappy GPS phone applications are vastly more responsive than google maps. Give me a desktop application that caches the whole map on disk, and I'll never go to maps.google.com again.
You don't really need to use JS to show images. Just make a big, page-wide grid of image thumbnails. A lot easier, and much more comfortable to find things in than by clicking "next" 20 times.
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
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, 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.
People ARE following them - then having to rewrite/bloat/break their code for ONE browser. The standards are listed at w3.org.
Also, there's the dual issues of bloat and customization: bloat because these libraries are BIG, and customization, because now any custom js extensions you write are dependent on interactions with both the browser and the library, which just adds another potential set of corner cases to test for.
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 bundled" somehow giving them GPL access to my server code
- Figured it didn't make much difference for a small site, so didn't impact the project much
- But probably best to be a commercial customer and I might want to tell my client and recommend buying it.
- I lost a lot of time but the final product they provide looks to be of high quality.
I ended up not using them but might consider it again. It looks nice. They were total idiots and might still be but it looks on the surface at least like the technology works / is sexy.
I would consider it a commercial thing to buy. I am quite uneasy about their claims about what GPL means even now and hesitate to wade into that again.If anybody has success using it as GPL please describe your experience and how you understand it now.
"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 blaming the victim.
I am anarch of all I survey.
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 developments, but the licensing options have remained roughly the same.
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.
With software patents, perhaps. Yes, it's quite unfortunate.
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.
Individual companies are free to write code and license it as they please, however as I noted in a previous comment, all companies need to respect FOSS licenses, such as the version of Ext JS licensed under the GPLv3. If a company uses a copy of the Ext JS library and links their code against it, then they'll need to be prepared to give un-obfuscated copies of their source code to any user who downloads an obfuscated version.
coding is life
It is actually quite common to have IE6 support as a requirement for new intranet applications in enterprises. This is the reason why frameworks must still support IE6. (even though it is really really painful).
BTW: If browser-side programming is not your thing, take a look of Vaadin framework that combines GWT and server-side programming model.
Vaadin - the best open source framework for building web applications in Java - no plug
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.
Yeah, but you could as well recommend pure unadulterated GWT
Once you're familiar with the concepts and philosophy of GWT, you'll be able to decide if you want to use a framework that builds upon it (there are tons of them and some are really crappy, like ext-gwt)
I'm a frequent contributor in the user forums and I find that GWT beginners only get more confused when they try to use a framework on top of GWT without knowing the basics.
There are some wrapper libraries for ExtJS and GWT which will allow programmers with no JS experience to build ExtJS front ends with Java.
Check out http://www.extjs.com/products/gxt/ or http://www.gwt-ext.com/
I've been using gwt-ext for some time now with great success.
Un/fortunately this is a .Net project (C#)... not that I'm opposed to Java, just how it is worked out.
Michael J. Ryan - tracker1.info
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 idealism.
bloat because these libraries are BIG
Big deal man, my applications are bigger than the libraries. I've got an application using ExtJS with over 1MB of minified Javascript code that I wrote for it. Any given user doesn't need to download all of that code to run their section of the application, but there's a lot of code there, it's a big application. The library itself is only about 500KB, and they only need to download that once at the loading page (then it should be cached).
I guess our priorities are just different. I'm trying to create large web applications that work everywhere, and it sounds like you're trying to create minimal "standard" sites and you don't really care what they may or may not work in.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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 - anyone who won't upgrade out of stupidity is also a tool, and simply not my market.
When my former boss kept complaining about compatibility problems with IE6, I told him to upgrade. He refused - "lots of our customers use IE6." I told him that, while I *could* fix it in IE6, it would break every other browser, and it wasn't worth it - plus it would delay release. And that if he wasn't happy, let someone else add the IE6 compatibility. In the end, pretty much everyone upgraded their browser anyway, so the "issue" of my refusing to do something stupd that would have delayed us by a few months was only an issue for a few months. Problem is, most devs don't have enough confidence in themselves to tell their boss when they're wrong, so we get these stupid hacks, written mostly by hacks with no sense of the long term implications.
Which is why we still have stupidity like active-x.
We are NOT here to continue to enable people in their bad decisions. Doing so is simply unethical.
And yes, ethics matter. So no soup for those who refuse to adhere to standards.
That's only a short-term patch on a long-term problem. Not all applications are updated. Not all web browsers are tested and accounted for. Users with minority web browsers still suffer.
I have to say that I've been very disappointed with the documentation/APIs/examples on the webs, but fairly happy with the mailing-list support.
As things go, a well-supported mailing-list is nice, but I still would prefer better docs.
My main complains have been:
* Sparse documentation on significant portions of the recent API (especially trees/grids and data stores)
* A lot of major changes over the last few years, with not-so-good forward documentation (replacements for functions/methods)
* Features that have been removed or seem to be broken in newer versions (stylesheet application to widgets, etc)
In the good things:
* Powerful and versatile templating engine
* Useful debugging tools
* Helpful people on the mailing list (no "RTFM stupid noob!" types)
* Strong AJAX tools
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 testing against it - it's time that won't be paid back.
Heck, the stuff I'm writing now, I refuse to even look at it in Windows until it's complete. It'll probably work fine under IE8 with a few tweaks, but I'm not going to waste any time accommodating anything older. People who won't upgrade simply aren't the target market, any more than people who are using a 486.
Then you should check out http://coolite.com/ It's a .Net wrapper around ExtJS. I haven't used it personally because I mainly do Java, but a colleague of mine swears by Coolite for .Net rich client work.
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, just because you don't want to make the effort.
People who won't upgrade simply aren't the target market, any more than people who are using a 486.
You're comparing a 20 year old processor with a fractional percentage of usage to the most popular browser, which will be 3 years old this month (IE7). Yes, there will come a time when support for IE6 and IE7 is no longer needed, but that time is not now, and it's not even in the near future. Clearly we aren't agreeing here, so I'll just leave you to it.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
The problem is that the good old Internet kind of sucked.
Depending for what kind of use. If you want to make apps on it, indeed it did. But I don't want apps, so the current one sucks more for me.
I don't always want apps... well, at least, that's not what I think I want. I want to do this search:
http://books.google.com/books?q=flywheel%20braking&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&um=1&ie=UTF-8&sa=N&hl=en&tab=wp and find this: http://books.google.com/books?id=VWTF3my04Q0C&pg=PA70&dq=flywheel+braking&ei=FinMSrGHB5OMzgSXtcneBw&client=firefox-a#v=onepage&q=flywheel%20braking&f=false
It's just the Web serving up text and images like the old days, but because of the unusual source (physical media, yikes!) it requires some special UI elements to read conveniently. Sure, they could have just given you an HTML page with an image from the book, but then your search terms wouldn't be highlighted, making it easier to find what you were looking for, nor would you have the same kinds of control over page layout and pagination.
Now, I'll admit: I'm cheating. I'm pointing to Google and they've been working quite hard to make Web apps as usable as possible. There are thousands of examples of BAD Web apps out there, and you're right that there are some serious usability problems out there right now. That needs to change, but it's not the Web app that's the problem, it's the fact that the interaction between the user, the browser, the traditional Web and Web apps is still being figured out.
Google Maps works in an emergency, but it's annoying. Sometimes a square won't load for some weird reason.
Well, that's always going to be a problem unless you have all umteen terabytes of data on your local system. You're not describing the difference between a native app and a Web app, you're describing the difference between local and remote storage (keep in mind that Web apps now have the capability to take advantage of local storage for caching or even full datasets where that makes sense, so it's not even a fair distinction in many cases).
It definitely never loads images for any zoom level other than the one you're at.
I think that's actually not true. I believe that Google Maps does try to do some predictive downloading if it has a chance, and may cache some relatively small images like the map of the globe, even when you don't need them.
On a slow connection, it's unberable to use.
How would that change if you used a non-Web mapping program with as much image and vector data as Google Maps?
Even crappy GPS phone applications are vastly more responsive than google maps.
And if that's all you want, you're good to go. I prefer having much more data at my fingertips. Try downloading satellite, vector map and terrain data for the entire world at several scales onto your phone and let me know how that works out.
You don't really need to use JS to show images. Just make a big, page-wide grid of image thumbnails. A lot easier, and much more comfortable to find things in than by clicking "next" 20 times.
There are times that works well (Wikipedia comes to mind), and other times when it works very, very poorly (any image gallery where the user wants to look at many or every image at full size). There are always problem domains to consider and a good UI does so.
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 shut out nearly as many people as you think. Realistically, you MIGHT be eliminating 5% of the market by ignoring older versions - the people who never update - but their computers are already p0wned anyway, so you're not missing anything except bot traffic.
We want our APPLICATIONS back. start/save/load/undo/redo/import/export/exit - QUICKLY.. that kind.
I find all of those operations vastly faster and easier to use on, e.g. Google docs than in Office (Open or Microsoft), but again, I'm talking about Google and to be fair, most of the Web isn't as good as Google at developing clean, easy to use UIs in HTML/JavaScript.
We want the application features that were common BEFORE the Internet, that we occasionally still have in SPITE OF the Internet.
How did the Internet take away your apps? Or are you confusing the Internet and the World Wide Web? And for that matter, how did the Web take away your apps? I can't think of a single app I used to use pre-Web that I don't have now as a stand-alone app if I want it. The fact that I sometimes prefer the Web app variant is just a matter of using the right tool for the job.
We expect a web browser to be a fucking web browser.
No, we don't. You might, but I like using UIs from dozens of companies without having to install apps for each one. I enjoy the fact that I can load up one set of tools that enforce a uniform experience regardless of whose service I'm interacting with (e.g. Flashblock, AdBlock, GreaseMonkey, etc.)
Go back to the drawing board and invent a new client/server framework, and use MODERN UI standards. A dynamic web is useful, but application platform it is not.
I await your contribution to the field with anticipation.
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 less work. Instead I'll just charge them extra and tell them why, and they can upgrade whenever they want to reduce our charges.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
But all that can be done server-side. This discussion is about JS, and what you pointed at can be done by sending plain HTML with nothing else to the browser.
It doesn't take terabytes. It may take terabytes for Google because they serve it as an image, but the information can be encoded in a much more compact manner.
The full set of maps for the entire planet available for both GPS units I have fits in 4GB or so.
And yes, browser can cache images, but none I know has anything like "Give google maps 4GB", and the default limit is way too small. Even if that was fixed, the browser's cache is stationary, and I can't for instance download the data for New York on my computer and copy it to my phone.
It may be doing something, but probably not enough. I understand it's a hard problem. Most people don't have enough bandwidth to download images for all sides, plus higher and lower zoom levels fast enough to keep up with anything the user might do.
In such cases, the concern isn't to be able to zoom in until you see ants on the sidewalk, but to get any data at all. So far I've not really had any problems with the amount of mapping data my phone contains.
But it doesn't need to be in several scales. Vector maps are inherently scalable. And a modern phone isn't limited to what a browser can do, so it doesn't need to do things like having everything as an image. That leaves satellite data, which while very nice is highly optional, and will probably eventually fit on a phone as well.
My phone can actually download satellite data if it has a connection, as well as the map for anything it doesn't have on the SD card, but if I happen to be stuck somewhere without an usable 3G connection, it'll still be able to find the way to where I'm going.
Actually what I'd really like is a gallery tag, which the browser could render in whatever way the user prefers
That's NOT the reason. Talk about missing the point.
Then there's the whole ethics question. Just as a car mechanic (car analogy time, folks) is prohibited by law from taking an unsafe vehicle, and "patching it" so that you can continue to operate it in an unsafe manner, we have a similar responsibility wrt IE6. I discussed this with a mechanical engineer last night, and when he was doing rail transportation safety, it was SOP that rail cars were not to leave the yards if both the car AND the load were not certified safe. If there was a question, they'd do a crash test. In one case the customer specified a certain type of car because it would be cheaper for them, but he refused to certify, because he believed the load would not be stable, despite being tied down. Sure enough. because this was a big order, and the customer was the government, he insisted on a crash test. The load arrived at the test site with the tie-downs already having worked themselves loose. The customer was told "you're not getting the cars you want, because our tests show it's not safe."
We already know that IE6 is a mess. We have a similar ethical responsibility to not continue to enable a bad situation. If their IT department doesn't want to do their jobs properly and ensure the use of better browsers, that's their problem, not yours.
We whine and bitch about software liability, and how the vendors don't even pay lip service to it. I'm in favour of software liability - at ALL levels. That includes both the big boys and independent devs and everyone in between. Why should this be the only industry where everyone shirks responsibility>
That sort of attitude is neither ethical, nor professional.
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 those customers. Support is automatic. When I use ExtJS, the one application I write already works in all browsers, I don't need to rummage through things trying to hack it together to support any single browser. I'm not really sure why you would think there's some sort of ethical or professional breach with that scenario.
The vast majority of IE bugs I do have to work around are also present in IE8, so again, whether or not to support IE6 or IE7 isn't even a question, once I get it working for IE8 it works for IE6 also. Surely you're not going to advocate dropping all support for IE entirely.
Here's one example of an issue I had to work around: when you are using IE7 or IE8 (IE6 is unaffected), and you have a web page that has an iframe or regular frame, and the frame contains a Flash movie, and you also have MS Office installed, and the Flash movie sends out a post request that results in an Office file being downloaded, IE will trash the file, it won't give an opportunity to either open or save. If the Flash movie isn't in a frame, or if Office isn't installed, or if it's not an Office file, the issue doesn't appear.
Now, I can whine about IE to the customer and how terrible it is and tell them to use another browser, and their response will be to cancel the contract and find another developer, one that will find a solution without complaining about the environment. There's a perfectly reasonable workaround to that bug which keeps the client happy, allows people to use IE, and allows me to get paid. The customer ends up paying for the workaround, they are aware of what the issue is and that it's caused by IE, and they can choose to migrate if they want to. They are aware of the problem. If they choose not to migrate, they're still my customer.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
What, you don't want to get paid for providing that sort of useful, and over the long term, money-saving help?
If you acknowledge that exploits that allow for system compromise and exposure of private data are more likely in environments where IE6 is still the "standard", then supporting IE6 is enabling such events. You become part of the problem, and nobody' going to be thanking you for it when it happens. Saying "I just did what the customer asked" is no more a defense, from an ethics point of view, than "I was just following orders."
It's because of the attitude of people like you that there's less pressure to fix non-standards-compliant systems. You are part of the problem, not part of the solution.
Maybe one day, when we finally get the question of liability sorted out once and for all in the software field, such attitudes will be seen for what they are - reckless, negligent, unprofessional, and lazy.
If Microsoft (remember the image buffer overflow bug a while back that affected ALL versions of IE and was remotely exploitable?) and the DoD can come out and say "Don't use IE", why not?
That's pretty sweet, may bring it up...
Michael J. Ryan - tracker1.info
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, Avnet, 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 company! Like I said, these people are aware of their problems, they understand the security implications and they understand the development difficulties. I'm sure that all of them have migration away from IE on their schedules, but I'm not going to refuse to write quality software for them just because they have a deficient browser.
If you feel so strongly about this, then perhaps you can contact Choice, Avnet, and the Air Force and let them know that you think they should migrate away from IE. I'm sure they'll value your opinion.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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 ahead. Read a couple of Dilbert books to put you in the right frame of mind (if it doesn't just depress the hell out of you that people are so stupid).
Yeah, right ... most of the "IT staff" are monkeys, same as anywhere else, and the ones who aren't, aren't going to waste their time with such low-level considerations as web browsers - they're working with data, not some boss who can't get rid of the p0rn pop-ups.
And those who are in between support monkey and the real IT staff are mostly just there to keep doing what they're doing. They couldn't effect change if their life depended on it.
Also, "technology company" doesn't mean they necessarily know shit about how to migrate from IE. For example, Avnet (stock symbol AVT sells electronic components and non-pc servers. That's why they go outside for software development - they don't have the expertise in-house for pc-related problems.
So why not recognize an opportunity when you see one? You don't have to replace IE - just offer to help them supplant it with safer, peer-reviewed technology that has a faster update cycle and will SAVE THEM MONEY!!!
Those last 3 words are magic in this economy.
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 to make sure that anything we produce is able to run inside any environment that we are asked to support. If Videotron wants to design and implement IT infrastructure, fine, go nuts. If you're looking for award-winning online training courses, we're the people to call.
It's called playing politics
Again, zero interest.
you have to play the game to get ahead
Oddly enough, "doing my job well" is working just fine for me, thanks.
they're working with data, not some boss who can't get rid of the p0rn pop-ups
That sounds a lot like me. My job is not to install people's printers, fix their computers, scan for malware, remove porn, or whatever else. I am a developer.
That's why they go outside for software development - they don't have the expertise in-house for pc-related problems.
They have quite a large IT staff, actually. They just don't develop their own online training courses themselves. I don't know about their other applications, I'm not familiar with them. All I know is their environment that our training runs in.
So why not recognize an opportunity when you see one? You don't have to replace IE - just offer to help them supplant it with safer, peer-reviewed technology that has a faster update cycle and will SAVE THEM MONEY!!!
Because, truth be told, I absolutely hate IT. When I started at this company I was one of the de-facto IT folks because I was the most knowledgeable. I made it pretty clear to the boss that I don't want to support everyone's computers, that's not what I have my degree in, that's not what I want to spend my days doing, and if he wanted me to continue doing it then I would look elsewhere for employment. Now he does that stuff, and I develop the software.
I could not care any less what any of our customers uses in their own environments. If they want to keep chugging along with IE, fine, I don't care, my software will work. If they want to migrate to something like Firefox, fine, I don't care, my software will work. If they want to open everything up and let everyone install whatever browser they want, fine, I don't care, my software will work. If they want to require that everyone use AOL's IE browser, fine, I don't care, I'll stifle my laughter and my software will work.
Am I getting through to you? I do. not. care. what my users are using, as long as my software is able to run on it. If the Air Force wants to require IE for their training portal, then my job is to make sure that our products are useful for them. We're not going to get any contracts if we say that our products are not compatible with their environment, and it really doesn't matter what suggestions we make for them to improve their environment, they're still going to go to a vendor that will support whatever they choose to use. In the interest of getting back on topic, it is the presence of a professional, stable Javascript library that plays a major role in allowing this compatibility to be so easy.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black