Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Learning Ext JS

samzenpus posted more than 4 years ago | from the read-all-about-it dept.

Books 133

stoolpigeon writes "Rich Internet Applications (RIA) have often been associated with some type of sandbox or virtual machine environment to make desktop features available via the web. Many applications though, have left behind the restrictions and demands of those technologies, implementing RIAs as pure web interfaces. One key technology in this area is JavaScript. It's been well documented that working with JavaScript can be problematic across various browsers. In response a number of JavaScript libraries have been created to alleviate the issues in dealing with different browsers, allowing developers to focus on application logic rather than platform concerns. One such library, focused on providing tools for building RIAs is Ext JS. For the aspiring developer looking to use Ext JS, Packt provides a guide to the library in the form of Learning Ext JS." Read on for the rest of JR's review.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.

cancel ×

133 comments

HERE I AM ROCK ME LIKE A HURRICAN E !! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29647903)

Rock me !!

Boo (0, Troll)

Anonymous Coward | more than 4 years ago | (#29647945)

Stop perpetuating this Web 2.0 crap. We don't want rich internet applications, because even if they're rich, the quality is poor. Why don't you write a book about how to design a proper website that doesn't use any javascript? About 99% of websites on the Internet could perform their current functions without javascript. The 1% have functions that no one wants.

Re:Boo (1, Interesting)

Anonymous Coward | more than 4 years ago | (#29647985)

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

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

Re:Boo (4, Insightful)

CannonballHead (842625) | more than 4 years ago | (#29648167)

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. ;)

Re:Boo (2, Insightful)

should_be_linear (779431) | more than 4 years ago | (#29648429)

Alongside websites, there are lot of Enterprise applications (frontends) moving to JavaScript, simply because deployment (including upgrades) to thousands of clients is so easy.

Re:Boo (1)

Vetruvet (1639267) | more than 4 years ago | (#29648813)

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!! :(

Re:Boo (3, Insightful)

BenoitRen (998927) | more than 4 years ago | (#29649829)

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

Re:Boo (1)

jole (4348) | more than 4 years ago | (#29653917)

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 [vaadin.com] that combines GWT and server-side programming model.

Re:Boo (1)

darkvad0r (1331303) | more than 4 years ago | (#29654539)

Yeah, but you could as well recommend pure unadulterated GWT [google.com]

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.

Re:Boo (2, Insightful)

aztracker1 (702135) | more than 4 years ago | (#29651769)

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.

Re:Boo (2, Insightful)

vadim_t (324782) | more than 4 years ago | (#29649359)

The question is: of those websites, how many of them do their current functions better than if they didn't have javascript?

Slashdot, for instance?

I much prefer the old interface.

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.

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.

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.

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.

Re:Boo (1)

CannonballHead (842625) | more than 4 years ago | (#29650437)

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.

Re:Boo (2, Insightful)

ajs (35943) | more than 4 years ago | (#29650467)

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.

Re:Boo (1)

vadim_t (324782) | more than 4 years ago | (#29651317)

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.

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.

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.

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.

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

Mixed up (0)

Anonymous Coward | more than 4 years ago | (#29651445)

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.

Nobody wants the old Internet back, you couldn't do much more than research with it.

We want our APPLICATIONS back. start/save/load/undo/redo/import/export/exit - QUICKLY.. that kind.

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.

No.

We want the application features that were common BEFORE the Internet, that we occasionally still have in SPITE OF the Internet. We expect a web browser to be a fucking web browser. Throwing away JavaScript UI is a great way of doing that.

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.

Re:Boo (0)

Anonymous Coward | more than 4 years ago | (#29649873)

Yeah! Before javascript image links didn't change colour! So what if you can no longer navigate the website without javascript?

Re:Boo (0, Flamebait)

mcbutterbuns (1005301) | more than 4 years ago | (#29648275)

We don't want rich internet applications

Thanks for that helpful comment Mr. I-speak-for-the-entire-Internet.

Tell me, who do you choose for our next president?
And tell me what I want for lunch today please!

Re:Boo (1, Offtopic)

CannonballHead (842625) | more than 4 years ago | (#29648293)

And tell me what I want for lunch today please!

Oh, that's too easy. McDonald's, Mr. mcbutterbuns. ;)

Re:Boo (1)

amicusNYCL (1538833) | more than 4 years ago | (#29648425)

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.

Re:Boo (1)

BenoitRen (998927) | more than 4 years ago | (#29649875)

in reality I've got customers paying good money for those functions "that no one wants"

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.

Re:Boo (1)

amicusNYCL (1538833) | more than 4 years ago | (#29650415)

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.

Yes, this is a troll. But deserved ... (4, Insightful)

Infernal Device (865066) | more than 4 years ago | (#29647953)

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

ExtJS with JSON and AJAX (1)

ground.zero.612 (1563557) | more than 4 years ago | (#29648577)

Is a ridiculously easy way to present your data in a "prettified" form. The ExtJS forums are full of useful advice and code samples. As for the licenses: http://www.extjs.com/products/license.php [extjs.com]

Re:Yes, this is a troll. But deserved ... (1)

aztracker1 (702135) | more than 4 years ago | (#29651831)

They've pretty much gone down the path of GPL + Commercial split that a lot of tools have. I really think mySQL was the first widely used one to follow this path, and ExtJS kind of has the same viewpoint. I know there's a lot of criticism here, but it's a pretty fair set of options imho. I think I was much more critical of the mySQL view of their database drivers. Though I don't have any plans of using ExtJS in a commercial app for redistribution that wouldn't be GPL in nature.

Uhhh (0)

Anonymous Coward | more than 4 years ago | (#29647993)

What a obvious plug. EXTJS is ok, not great. It's BIG if you going for a light/fast sight keep away from any library or do your research.

Re:Uhhh (0)

Anonymous Coward | more than 4 years ago | (#29648175)

It's a book review. What do you mean, it's a plug?

Re:Uhhh (1)

amicusNYCL (1538833) | more than 4 years ago | (#29648435)

It's BIG

They also have Ext Core available, which is all of the DOM/Ajax/Data components and none of the GUI components.

Packt marketing (1)

CarpetShark (865376) | more than 4 years ago | (#29648933)

What a obvious plug. EXTJS is ok, not great.

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.

lern 2 (0)

Anonymous Coward | more than 4 years ago | (#29647999)

jQuery.

Bah (1, Funny)

fph il quozientatore (971015) | more than 4 years ago | (#29648009)

Bah. I already use EXT3 (and I am planning to migrate to EXT4). What could this EXTJS have more?

Re:Bah (2, Funny)

Shikaku (1129753) | more than 4 years ago | (#29648757)

I'm waiting for EXT3.11 for workgroups before upgrading.

The guys behind EXTJS are terrible (5, Interesting)

Anonymous Coward | more than 4 years ago | (#29648035)

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

Re:The guys behind EXTJS are terrible (2, Interesting)

cliveholloway (132299) | more than 4 years ago | (#29648151)

I have no mod points right now, but hopefully you'll get modded up - great insights - thanks

Re:The guys behind EXTJS are terrible (2)

tukang (1209392) | more than 4 years ago | (#29648235)

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

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

Re:The guys behind EXTJS are terrible (3, Insightful)

Anonymous Coward | more than 4 years ago | (#29648279)

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

Re:The guys behind EXTJS are terrible (1)

ASBands (1087159) | more than 4 years ago | (#29648579)

I believe this is relevant:

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

Re:The guys behind EXTJS are terrible (3, Informative)

AlXtreme (223728) | more than 4 years ago | (#29648803)

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

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

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

Re:The guys behind EXTJS are terrible (0)

Anonymous Coward | more than 4 years ago | (#29650245)

He said, "the people who use it," so yeah.

Javascript by definition is used by the clientq (1)

SmallFurryCreature (593017) | more than 4 years ago | (#29648297)

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.

Re:Javascript by definition is used by the clientq (0)

Anonymous Coward | more than 4 years ago | (#29648543)

Absolutely correct, but it's worth noting that that line of thought may not sit well with the boss, legal dept, etc.

Re:Javascript by definition is used by the clientq (1)

hobo sapiens (893427) | more than 4 years ago | (#29652809)

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

I think as we see more logic embedded within javascript, and thus more time spent writing javascript, you'll start to see organizations grow more protective of their javascript. Of course, unless browser makers ruin the whole thing and somehow figure out a way to make it protected on the client, they'll be grasping at sand, but it won't stop them from trying. If fact, that's what'll kill javascript if anything does.

Re:The guys behind EXTJS are terrible (2, Interesting)

Cyberax (705495) | more than 4 years ago | (#29649485)

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

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

Re:The guys behind EXTJS are terrible (0)

Kenja (541830) | more than 4 years ago | (#29648547)

(shrug)

I paid for a license. I use extjs to write software that I expect to be paid for, so I have no problem paying for extjs.

Re:The guys behind EXTJS are terrible (1)

Lussarn (105276) | more than 4 years ago | (#29654643)

That's not the point. Do you think it's an ethical move to lure developers to your library using LGPL, and then when you have a customer base declare it never was LGPL to begin with?

Stinks pretty bad to me.

Re:The guys behind EXTJS are terrible (2, Insightful)

tomhudson (43916) | more than 4 years ago | (#29648671)

A lot of people may think, it's web client code, who cares, but for some of us web client code is becoming more and more like any other application code.

There's one important difference.

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

Sure, stick your copyright notice on it, but don't classify it the same as "any other application code". It's out there in the open. The real meatballs and gravy will always be on the server side in any data-driven web app.

Re:The guys behind EXTJS are terrible (0, Redundant)

BenoitRen (998927) | more than 4 years ago | (#29650021)

its'

Please don't abuse the apostrophe.

Re:The guys behind EXTJS are terrible (1)

Qubit (100461) | more than 4 years ago | (#29653823)

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

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

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

If a user U loads one of your web pages and in the process downloads a local copy of A, then not only do you need to provide a way for them to get a copy of the original source code to Ext JS, but you would also need to provide the regular, non-compressed, non-obfuscated source code to whatever parts of A you have served up online to the user.

The reason why the non-obfuscated code must be provided to the user is that the GPLv3 [gnu.org] clearly states how the source code for a piece of work should be conveyed:

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

The right to source code in this "preferred form" is granted the moment that code is downloaded to the user's browser.

Re:The guys behind EXTJS are terrible (1)

tomhudson (43916) | more than 4 years ago | (#29653841)

Good point wrt the gpl and obfuscating code.

Two points:

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

That being said, I think the whole idea of trying to obfuscate javascript is self-defeating. The real gravy and meatballs, crown jewels, etc., is the stuff (data and apps) on the server, not the interface to it that javascripted web pages show the end user.

Oh, and I like your current sig.

Re:The guys behind EXTJS are terrible (1)

Haeleth (414428) | more than 4 years ago | (#29654403)

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

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

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

So failing to give away unobfuscated copies of your client-side JS under the GPL could still land you in court. And even if there's a good chance you'd win, I can see why most companies might want to avoid taking the risk when there are so many alternative libraries with less ambiguous licensing.

Re:The guys behind EXTJS are terrible (5, Interesting)

amicusNYCL (1538833) | more than 4 years ago | (#29648695)

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

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

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

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

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

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

Re:The guys behind EXTJS are terrible (4, Informative)

ojintoad (1310811) | more than 4 years ago | (#29648939)

Mod parent up.

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

Re:The guys behind EXTJS are terrible (1, Interesting)

Anonymous Coward | more than 4 years ago | (#29650375)

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

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

Re:The guys behind EXTJS are terrible (0)

Anonymous Coward | more than 4 years ago | (#29653951)

In other words, ExtJS is not free or Open Source for you, or for most of the users. Instead - it is a good commercial product.

IMO ExtJS should be marketed as commercial product with GPL license available as a added bonus. Now when they market it as an Open Source product and it turns out to be commercial for most users, it builds up disappointment for most evaluators.

Re:The guys behind EXTJS are terrible (3, Interesting)

obender (546976) | more than 4 years ago | (#29649371)

Why did you switch from Dojo to ExtJS? Does the criteria still apply today?

Re:The guys behind EXTJS are terrible (1)

cripkd (709136) | more than 4 years ago | (#29654911)

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

Re:The guys behind EXTJS are terrible (1, Interesting)

Anonymous Coward | more than 4 years ago | (#29650559)

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

1. Why we switched from Dojo

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

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

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

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

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

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

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

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

Re:The guys behind EXTJS are terrible (1)

hobo sapiens (893427) | more than 4 years ago | (#29652841)

"There will even be algorithms in the JS that they want to protect. They may be limited to obsfucation as a technique, but that can be pretty decent."

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

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

You can do PLENTY of stuff in javascript that isn't business logic. Save business logic for the back end.

Now, in principle I agree...even though we all know this, some business somewhere will try to lawyer up and protect their Javacscript. We'll see how well that turns out...the record industry could probably tell them how well that works, though.

Re:The guys behind EXTJS are terrible (0)

Anonymous Coward | more than 4 years ago | (#29654119)

This isn't about business logic. This is about application code. You can implement real applications in JS and as HTML5 comes forward and performance keeps improving we are going to see more of it. The application can be anything. It could be a game, a presentation maker, or a scientific program. You might think that JS isn't the right place for this, but that is irrelevant. Even though I do it professionally, I'd for the most part agree with you. What is right isn't going to matter though. As these things become possible people are going to do them. If competitor X has feature Y and we don't we lose out. So if competitor X decides to be "stupid" and write a giant JS application with tons of features and we know better, we lose out. It may be a terrible choice technically, but from a business perspective it could be a great choice.

As for the obsfucation/protection stuff, it doesn't matter. Obsfucation is good enough. We could obsfucate and prohibit reverse engineering the same way that companies do with executable code. You may have your technical ideas of what a compiled language/interpreted language is, and a great understanding of how we are sending you the actual code, but it doesn't matter. That's all nice, but from a business perspective the code is ours and we will protect it and prohibit you from reverse engineering, and the law will likely be on our side. I'm not saying I agree with that, but that's how it is.

As you see more and more real apps you are going to see a lot more time invested, a lot of brilliant optimizations, and a lot of complicated code. I agree, in browser-JS is not the right place for it, but I don't believe that is a choice we are going to be able to make.

Following the rules... (1)

Qubit (100461) | more than 4 years ago | (#29653905)

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.

Re:The guys behind EXTJS are terrible (2, Interesting)

mgkimsal2 (200677) | more than 4 years ago | (#29652165)

Why the switch away from Dojo to ExtJS in the first place, if you don't mind my asking? And why not move back to Dojo instead of YUI?

Re:The guys behind EXTJS are terrible (0)

Anonymous Coward | more than 4 years ago | (#29652537)

The answer:
http://books.slashdot.org/comments.pl?sid=1384583&cid=29650559

Re:The guys behind EXTJS are terrible (1)

Qubit (100461) | more than 4 years ago | (#29653767)

they claimed that it never was released under the LGPL. They tried some silly technicality where they said it was only released under the LGPL under some other terms. The LGPL itself clearly says any added terms can be removed, but they insisted it couldn't.

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

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

Wikipedia's blurb on the licensing problem states:

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

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

I strongly believe they are wrong about the "never being under LGPL" thing, but we weren't going to be wasting time dealing with lawyers and fighting them.

Next time, toss the question over to the Software Freedom Law Center [softwarefreedom.org] . Even if you personally don't want to go forward with the issue, I feel like the SFLC is great at trying to resolve questions like this so that developers can just write code and leave the legal issues for the lawyers. They're really gung-ho [identi.ca] about dealing with license violators and are dedicated to helping clear up licensing issues [softwarefreedom.org] .

NO (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29648095)

There are far better options available, particularly ones that aren't as ugly and have friendlier (and stable!) licenses.

Give me jQuery or give me death! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29648215)

And also kill Ext JS while you're at it.

Another Book (5, Informative)

KingK (148438) | more than 4 years ago | (#29648243)

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

Re:Another Book (1)

mgkimsal2 (200677) | more than 4 years ago | (#29652213)

And both Frank Zammetti (posted a comment below) and Jay Garcia (the one you mentioned) have contributed pieces to JSMag about ExtJS :)

Re:Another Book (1)

VinylFox (1650699) | more than 4 years ago | (#29652443)

If you the kind of programmer that wants to know every single detail of the ExtJS library up front, Jay's ExtJS in Action book will work very well for you. If you want to get up to speed fast and fill in the details yourself, then my Learning ExtJS book is more suited. Depends what your learning style is. I cant say anything about the other books on ExtJS, as I haven't read them.

Re:Another Book (1)

mfearby (1653) | more than 4 years ago | (#29655177)

I bought this e-book just the other day. I got sick of trying to piece together various out-of-date tutorials and following the API docs online. Whilst you can't say the API docs aren't all there, I think it's probably too much. The hide inheritance members button at the top is a must!

However, the learning curve for Ext JS is HUGE and an approach such as "Learning Ext JS" is what's called for, even for competent programmers. I found the Apress "Practical Ext JS Projects With Gears" to be far too centred around the example scenarios, whereas, "Learning Ext JS" is perfect for somebody with a use in mind but just wants to know how all the widgets work. The Gears book would be ideal for somebody with no real idea in mind and plenty of time on their hands to "see what this Gears/Ext JS caper is all about" but if you want to just get to the point of how a grid works, or any other widget, then you're going to have to read through a lot of verbiage to answer your question.

I've also got no problem with the licensing. I use Ubuntu and prefer open source software, and if you're FOSS too, then there's no problem with Ext JS. If you're commercial, then the rather meagre licensing fee for Ext JS is hardly going to make you ditch it and piece together all that cross-browser-Ajaxy-goodness yourself! Whilst jQuery is nice and I prefer it's leaner syntax, its plugin repository is getting tad messy these days and jQuery UI only has six widgets. Can't beat Ext JS if you're not a FOSS license zealot and you just want something to take the pain out of RIA development. Life's too short to get hung up on things that don't matter.

EXTJS Opinion (2, Funny)

VGPowerlord (621254) | more than 4 years ago | (#29648411)

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

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

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

Good tool kit for web apps, not web pages. (2, Interesting)

Kenja (541830) | more than 4 years ago | (#29648437)

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

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

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

Crossbrowser libraries just perpetuate the problem (1)

tomhudson (43916) | more than 4 years ago | (#29648477)

It's been well documented that working with JavaScript can be problematic across various browsers. In response a number of JavaScript libraries have been created to alleviate the issues in dealing with different browsers, allowing developers to focus on application logic rather than platform concerns.

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

Re:Crossbrowser libraries just perpetuate the prob (4, Informative)

amicusNYCL (1538833) | more than 4 years ago | (#29648771)

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

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

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

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

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

Re:Crossbrowser libraries just perpetuate the prob (0)

Anonymous Coward | more than 4 years ago | (#29648911)

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

People are following web standards. It's Microsoft that doesn't.

Re:Crossbrowser libraries just perpetuate the prob (1)

amicusNYCL (1538833) | more than 4 years ago | (#29650477)

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?

Re:Crossbrowser libraries just perpetuate the prob (0)

Anonymous Coward | more than 4 years ago | (#29653711)

They did honor the standard by naming their proprietary CSS extensions according to the -vendor-attribute pattern, so they're making it clear they are nonstandard, and they're not polluting the global namespace. I don't remember why exactly they chose to do so in the case of opacity, but maybe the spec wasn't stable yet. Arguably it's better to not support a standard property at all than to pretend to support it, but implement it inconsistently, or support a syntax that is still subject to change.

Btw, Firefox, Webkit and Opera have been supporting the standard opacity property for quite some time now. IE is the only browser that doesn't implement it.

It's clearer in the case of border-radius: the spec is a moving target, and browsers are implementing nonstandard extensions to it (slash and percentages in Firefox [mozilla.org] ), but the goal is to support the standard once it's final. To test a new property in the wild, browsers have to implement it when the spec is still a moving target. This actually helps the standard design procedure.

Re:Crossbrowser libraries just perpetuate the prob (1)

BenoitRen (998927) | more than 4 years ago | (#29650221)

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

Re:Crossbrowser libraries just perpetuate the prob (2, Interesting)

amicusNYCL (1538833) | more than 4 years ago | (#29650497)

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

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

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

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

Re:Crossbrowser libraries just perpetuate the prob (1)

tomhudson (43916) | more than 4 years ago | (#29651849)

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

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

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

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

People ARE following them - then having to rewrite/bloat/break their code for ONE browser. The standards are listed at w3.org [w3.org] .

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.

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

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.

Re:Crossbrowser libraries just perpetuate the prob (1)

ignavus (213578) | more than 4 years ago | (#29653801)

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

Re:Crossbrowser libraries just perpetuate the prob (2, Insightful)

lkcl (517947) | more than 4 years ago | (#29648859)

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

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

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

this is just a "merging" trick that is applied at compile-time, by taking two ASTs (python abstract syntax trees), 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 [pyjs.org] for the absolute most basic example (source code 2 levels below).

Re:Crossbrowser libraries just perpetuate the prob (3, Insightful)

BenoitRen (998927) | more than 4 years ago | (#29650161)

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

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

Re:Crossbrowser libraries just perpetuate the prob (2, Insightful)

Dhalka226 (559740) | more than 4 years ago | (#29654075)

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

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

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

A web browser is a tool, both for the user of the websites in question and the developers. As a 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.

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

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.

What next - make a version that works for IE3 or Mosaic because someone is still running WFW3.1?

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?

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?

For starters, most of these comparisons are pretty lame. Standards for food, water and sanitation are great, and they probably save a great many lives each year. But the differences in the severities aside, nobody was going without food or water or without expressing their biological needs before they existed. What you're suggesting is a "NO SOUP FOR YOU!" approach, forcing people to do without if they don't care about what you care about.

Why don't they care? Because the people who need to care for change to occur more quickly are not the people who need to deal with it. Companies are the ones who pay developers' salaries, and developers are the ones who need to worry about whether or not X, Y and Z are standards-compliant or whether they need to make changes for a particular browser. The users see none of this, they just see the product. The companies are, by and large, not going to force change on unwilling consumers to their own detriment. Developers can scream all they want, but the reality is that if they want to continue to get those paychecks they do what the companies want. The users? They don't know or care. That's why change is so slow.

The reality is, they probably shouldn't care. I can sit down and show them the difference between IE 3 and IE 8 (or Firefox or Opera or Safari). I can show them what that browser is preventing them from experiencing, and they would care. There's not a ton that can't be done (yes, often with hacks) in IE6 that can be done in more modern browsers. All I could sit a user down and show them is... I don't know. A clock that says it took me longer because they don't quite work the same way but I still managed the same effect? Hardly compelling. Especially when one of the major solutions is to use one of the many libraries that handle it for you.

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.

With due respect, any developer who cares enough to check their work in multiple browsers is going to be fairly well-versed in the standards. Those who don't don't particularly factor into a discussion about whether or not we should spend time accomodating browser differences, do they?

As far as the managers, whether it is or isn't the most effective allocation of resources varies by the situation. Like I said before, it's a cost-benefit analysis. Turning away 20% of visitors is a really bad thing. You'd best have something else that is way better to offset it before you go around saying you're not allocating your resources properly. If you don't, then "compatibility with an incompatible browser" (by which I assume you mean spending time to make two browser who implement things different both work well, because if it's truly incompatible then there will never be compatibility by definition) probably is the most effective allocation of resources for living in the real world. Evaluating the decision against some hypothetical, potential future world is... not exactly the sign of a good manager or developer.

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

A pretty bad developer, in most cases. Yes, managing all the browser differences for JavaScript manually is a really time-consuming and stupid thing to do; luckily, projects like Ext JS* exist to do it for you. Yes, managing the CSS differences is annoying, but the more development you do the more you just mentally fix the differences in your initial run-through. You'd be shocked how many times an extra DIV makes all the problems go away, and you just sort of mentally start putting them there. When it comes time to actually check it out in different browsers, the changes are usually minimal and quick. It's really just an experience thing.

That time could be better spent making a better product, rather than making the existing product bloated and more bug-prone.

I agree, I would rather spend the time doing something else, but that doesn't mean that in the world that exists today it is a bad use of time to get IE working. Also, I disagree with "bloated and more bug-prone." More lines of code doesn't make something bloated by any definition I've heard for the term. As far as more bug prone, it's probably true for things like JavaScript that ultimately impart functionality by integrating with backend systems, but I think it's mitigated by the fact that there are teams of developers for things like Ext JS and other frameworks working on their code, and thousands of developers like yourself to stumble into and hopefully report and fix the bugs. As far as display aspects, yeah, I suppose it is more bug prone. Then again there are very seldom hidden display issues that only arise in certain circumstances, so once you spend whatever extra time was necessary to get it right in the first place it's rare to find a bug crop up.

My entire long-winded post can essentially be boiled down to this: I would love for things to be different than they are, but part of being a professional developer is being paid to operate with things the way, not the way I wish they were. I can hope and push for changes in the future through different avenues than refusal to get the job done. To imply anything else should be the behavior of a professional is disingenuous.

* I have never used Ext JS, for the record.

Software testing suites? (1)

Dishwasha (125561) | more than 4 years ago | (#29648593)

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.

Re:Software testing suites? (0)

Anonymous Coward | more than 4 years ago | (#29652521)

Selenium is more of an integration test tool and isn't as good for unit testing pure JavaScript code. There's a new project from Google [google.com] that looks promising. Like Selenium, it relies on actual browsers to run the tests, however the test runner isn't managing the actual browser process and there's no HTML rendering happening so it should be significantly faster than Selenium. And it integrates cleanly with IDEs, so tests can be run without leaving the coding environment.

Please now can we update the wikipedia RIA page? (3, Interesting)

lkcl (517947) | more than 4 years ago | (#29648761)

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

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

jQuery, dojo, prototype, ExtJS, ... oh my (2, Interesting)

hey (83763) | more than 4 years ago | (#29648785)

Too many JS toolkits!
Will it ever settle down?

Re:jQuery, dojo, prototype, ExtJS, ... oh my (1)

diodeus (96408) | more than 4 years ago | (#29649055)

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

Who cares, just use the one you like.

Silverlight (1)

emailandthings (844006) | more than 4 years ago | (#29649031)

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

NOT!

Re:Silverlight (1)

Mongoose Disciple (722373) | more than 4 years ago | (#29653235)

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

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

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

All these librairies (0)

Anonymous Coward | more than 4 years ago | (#29649339)

Are way too big, you people are crazy. I'm not adding 80KB+ of download weight to a website just for a fucking library. I coded my own with only the things I needed and it's under 10K.

Re:All these librairies (1)

emailandthings (844006) | more than 4 years ago | (#29650643)

No bro, using SharePoint is a bit more crazy... lovely viewstate + core.css + shit lots of postbacks for any click...

I use ExtJS extensively... (1)

PinchDuck (199974) | more than 4 years ago | (#29649767)

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.

Re:I use ExtJS extensively... (1)

Yosho (135835) | more than 4 years ago | (#29652349)

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

On top of that, I hate Javascript. It's one of my least favorite scripting languages; the only thing I can think of offhand that I like less is Visual Basic 6. Using ExtJS, however, makes Javascript much, much more enjoyable.

Not the place for licensing discussion (1)

VinylFox (1650699) | more than 4 years ago | (#29652291)

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.

Ext JS good to learn and use (1)

./ (13859) | more than 4 years ago | (#29653531)

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 hurt then came to an understanding (1)

mattr (78516) | more than 4 years ago | (#29653771)

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.

Vaadin - free framework with free book (0)

Anonymous Coward | more than 4 years ago | (#29653987)

Anyone considering ExtJS should also evaluate Vaadin [vaadin.com] :
- It is free with Apache 2.0 license to all (while as ExtJS requires commercial license for most)
- It comes with a free book [vaadin.com] - no need to buy one
- It is build completely in Google Web Toolkit in client side (while as ExtJS GWT wrapper is just a wrapper)
- Programming is done in real Java language on the server-side. This makes integration to backend trivial. No more JavaScript debugging, protocol design, keeping client and server code in sync, worrying about browser compatibility issues, ...

Take a look of demo [vaadin.com] and start coding [vaadin.com] ...

Re:Vaadin - free framework with free book (0)

Anonymous Coward | more than 4 years ago | (#29654049)

Hey - this post was about Ext JS - not about competing frameworks! But, took a look of Vaadin anyways...

Wow! Looks great - will definitely try it out :)

Re: (1)

clint999 (1277046) | more than 4 years ago | (#29655495)

in reality I've got customers paying good money for those functions "that no one wants"
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...