Slashdot Mirror

Apprently. I find this line interesting: the reason browser back buttons work in Gmail is an invisible, seamless use of iframes that create browser history. Isn't this actually due to the use of # in the URL when you click things?

Actually it is a bit more complex than that. A Hash is just an link to an anchor on the current page. I am not sure how gmail works exactly, but I use extjs at work and it manages the history with an iframe as well. It needs a way to keep track of all the history tokens so it uses an iframe. Check out its source code if you are interested. http://www.extjs.com/deploy/dev/docs/source/History.html

Try GWT and an associated GUI designer like Instantiations. I have used GWT but not the gui designers myself. GWT works pretty well for certain things. The Google Closure JS libraries can provide nice GUI (the stuff used to build google apps) if you want to work purely in JavaScript. As for Delphi/VB esque components like data grids, try ExtGWT, a rich gui library for GWT. Though I question the wisdom of trying to build a desktop style GUI on the web as I suspect one reason people like web apps is their typically simpler UI paradigms.

why can't something a little more like that be done with the web?

There are several attempts at that: see Comparison of remote desktop software on Wikipedia. I believe that everything sums up to "dealing with network latencies is hard".

OTOH, did you have a look at Ext GWT?

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.

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

I didn't say the GPL doesn't work, just that it doesn't work for business.

http://extjs.com/company

Any more overly-broad, sweeping generalizations that you want to make?

For a recent application, I wanted to use the ExtJS framework because of how awesome it is. This is a commercial product I'm developing. So our choices were to use the GPL license for ExtJS, and release all of our code also, or pay ExtJS for a proprietary license and have the right to do whatever we want to do with our code. We chose the option where we pay ExtJS for their work.

You may not realize this, but in this example, the GPL worked exactly the way the ExtJS developers intended it to.

It's about the freedom to use the code that I write the way that I want to use it without having another license tell me what I can and can't do with my own code.

This is exactly what you got in this example. You paid them for a different license to get the freedom that you wanted. You got your freedom, they get to keep their freedom, so what exactly are you complaining about?

Are you complaining that the ExtJS devs *also* released under the GPL so that anyone willing to abide by its terms could use their stuff without paying? Is that not their *own* freedom to do so? Are you placing your own freedom over theirs? Is that fair?

then you're missing the point and you don't understand business.

If you put yourself in the shoes of the ExtJS devs and thought about it from their perspective, maybe you'd begin to understand why some people use/prefer the GPL

Besides, judging from the ExtJS website, and the fact they made a nice chunk of change out of their transaction with your company, they also seem to understand business... yet they obviously aren't afraid of the GPL.

I'm sorry but I think you need to polish your anti-GPL argument some more, and FYI, next time don't use as an example GPL software that has been successfully commercialized by a for-profit company.

That completely breaks the OSS model, though. That is: Sometimes, I see a project I like, but it needs a little work. If it's a tiny patch, I'll just do it all locally and send it in. But if my patch is rejected, or it's likely to be a bigger contribution, I'll create a public fork -- easy to do with something like Github -- and publish my changes there.

This also has the nice side effect of simplifying the problem of finding a new maintainer, for a smaller project -- you've already got at least one fork, probably several that might even be sharing patches, so if the original developer goes AWOL, the project is still alive.

All of these work whether I'm doing purely open source stuff, or whether I'm working on a proprietary project and contributing back.

If it's MIT, BSD, GPL, etc, all of this is possible. If I've had to license it commercially, then I can no longer share my changes -- we're now back to the bottleneck of the original creator, in this case, of exactly one person. And adding money to the equation makes it even less likely that these changes will make it back in.

In fact, I'll give an example: extjs was under a more permissive license. It switched to GPL, and tried to claim that the GPL applied to the server, and not just to the JavaScript client. Although we had paid for a commercial license before the GPL switch, we dropped that thing in a matter of weeks -- we just didn't need the uncertainty of a framework tightly under the control of an asshole. Instead, we use jQuery, which is dual-licensed under MIT and GPL, isn't going anywhere, and ended up being closer to what we needed anyway.

And while I don't know of any patches we've sent back to core, we did publish one or two extjs plugins, and there was a fair chance of publishing jQuery stuff.

I haven't needed to use anything that heavy to build a site, most of what I've done lately I've been using ExtJS for the frontend. The learning curve is a little steep with their object model, but it's a really powerful framework, for both interface stuff and data management. About the only thing you really need something like Java or Flash for would be a web-based game with decent graphics. I've got some pretty beefy ExtJS-based applications I'm hosting on Apache though, I guess it depends what you need your sites to do.

Most of the apps I seen really don't have that much Javascript when you compare it to the amount of code that is in your typical desktop app or server side application. And ultimately many of the functions are small.

That's true, people aren't taking full advantage of what Javascript can do at this point.

What I've noticed is instead their is a difference in the rendering engine itself. Javascript might be a single line to change the CSS of an element or change the visibility attribute, but then the browser takes forever to collapse the item.

That's also true. I'm using a Javascript framework called ExtJS to develop a relatively large application. It's got about 750KB of minified Javascript code (not including Ext), about 550KB of backend PHP code, and about 5KB of HTML markup. All browsers load some of the screens quickly, even with IE there's not a significant delay to display much of the application. The delays I see with IE come mostly in two places - grids and trees. If I have an Ext grid that has 10 columns and 30 rows, where the grid is able to be sorted, filtered, show/hide columns, drag and drop rows, etc, Chrome or Opera will get the records from the server and update the grid pretty quickly, a matter of 1 to 2 seconds where the browser has frozen waiting for the UI to update. IE can take a good 10 seconds to do the same thing, it gets the JSON data from the server and I can see the little progress indicator freeze as soon as the data comes back and it starts the UI update, that indicator is frozen for 10 or so seconds before it updates the UI. The same thing with trees, if it loads a tree that has 100 parent nodes each with several child nodes, IE will sit and chew on that for a while before it updates the UI. Again, Opera and Chrome are much more responsive. Firefox also performs better than IE, but I'm sure Firefox is hampered a little because I'm using Firebug, I haven't done much testing of the application using Firefox without Firebug enabled.

The demos for Ext are here if you want to see for yourself, although most of the demos are made to be lightweight and fast on all, they don't stress the browser much. The web desktop might be one of the better performance tests.

http://extjs.com/deploy/dev/examples/

Ever since GWT, I hardly touch any JS, but due to lack of skins and custom widget, I vote to use GXT currently.

http://extjs.com/products/gxt/

That was my feeling too until I learned about how he licenses the code, and his views on what the GPL3 means for web applications.

http://extjs.com/products/license.php

If you are writing an open source app then that's great but if you are going to use it at your company for a closed source project make sure they understand they need to buy a commercial license from the author.

I can't help but think that all of these JavaScript/AJAX libraries keep reinventing the wheel over and over again. How many grid widgets written in JavaScript do we really need? How many toolkits for a progress bar or a div-based dialog box have to be developed? Is one of them really that compelling over the others. Consider:

http://dojotoolkit.org/ - DoJo Toolkit
http://www.activewidgets.com/ - ActiveWidgets
http://www.prototypejs.org/ - Prototype
http://script.aculo.us/ - Scriptaculous
http://jquery.com/ - jQuery
http://extjs.com/ - Ext JS
http://developer.yahoo.com/yui/ - YUI
http://code.google.com/webtoolkit/ - Google Web Toolkit (GWT)
http://www.sproutcore.com/ - SproutCore

Those are just the ones I have used personally. It's getting ridiculous. Personally, I like the approach GWT has, but of course that's only relevant to the java developers of the world. I'd love to see all of these "widgets" be compatible with one another.

I'm pretty surprised no one has mentioned ExtJS, another VERY full-featured JS interface library. SproutCore is super young in comparison, it looks like, but it will be interesting to see how it advances. ExtJS has kind of a clinical look to it, and customizing the widgets looks like a pain, but the framework is definitely robust.

I think we're soon going to find that this has all been loudly blown out of proportion:

"Open Source License Exception for Extensions
Draft .26, April 28th, 2008"
http://extjs.com/products/ux-exception.php

Ext on Rails http://www.extonrails.com/

From http://extjs.com/company/dual.php :

"""
we require that you do one of the following:

- Contribute to the continued development of the product by purchasing commercial licenses from Ext. This option secures you the right to distribute your application under the license terms of your choice.

- Contribute to the Open Source community by placing your application under an Open Source license (e.g. GPL v3). This option secures all users the rights to obtain the application's full source code, modify it, and redistribute it.

"""

So, all that someone needs to do if they use this lib without paying for it is distributing it under an open source license. Please note that the BSD, X/MIT, Artistic, etc licenses are ALL open source licenses and ARE legitimate licenses to use under these terms NOT only the [l]gpl's.

Appears that maybe Ext's forums are /.'d already. I've been actively participating in one of the licensing threads started on Ext's forums. Try http://extjs.com/forum/showthread.php?t=33096 a little later, once the database recovers... Since discussing licenses seems to be nothing new on Slashdot, maybe some "experts" from here can bring some light into the above thread.

It's their software so they have every right to release it under whatever license they want (and I've never heard of it or them before, so it makes no difference to me), but I find it... interesting... that one of their products (Ext GWT) is based on a product that uses the Apache License (the Google Web Toolkit), while the Ext product uses GPL.

Don't worry -- I'm sure the ExtJS boys are working on that one as we speak. They've done just about everything else for my job in web development, as far as I'm concerned.

ExtJS appears to have interesting license requirements.

It is released under a commercial license and LGPL 3, but only for certain uses.

Check out the Ext library if you ARE looking for user interface PLUS data constructs. It has a JQuery adapter that let's them work in tandem and I've had lots of luck integrating the two in mixed code, cross-browser clean.

I'm not too impressed with JQuery UI Interface library OTOH. seems bloated and buggy last time I tried it out.

Why isn't anyone mentioning the ext JavaScript library? jQuery is so last year!

-- For Shizzle

The route these libraries/frameworks are taking is allowing you to build and thus include only the js you need for your particular use case. For instance, the best JS lib IMO is Ext http://extjs.com/ which has a dependency builder where you specify the framework you want to use (YUI, JQuery, or Prototype) and the capabilities you need (e.g just Core, DD, or choose from umpteen UI components).

At any rate the Dr Dobbs article was pretty poor, seriously outdated and lacking much in the way of details.
Dojo is nice, but I found it to be too slow and recently I think they realized they needed to re evaluate some design decision and set a clearer path on where they are taking dojo in the future. They have not released much in the last 6 months (a minor dot release to 4.1 I believe). It does have the great feature of graceful degradation cause it can take existing markup and convert to supa nice UI widgets, but this requires it to traverse the whole DOM and look for 'dojo' widgets. There are workarounds, e.g specifying the element ids for your widgets to be dojo-ized though. Still though, pages (really when using UI JS frameworks they are not pages anymore but applications) with a lot of dojo widgets can be very slow to render. In addition dojo has some rough edges such as poor docs, too many grids that make it feel like there is a lack of direction etc. I look forward to the next major release though, Dojo certainly has a ton of potential.

But the kick ass JS library right now is Ext http://extjs.com/. Its well documented, very polished, has just about any widget you need, a super nice data abstraction for the grid/editable grid/combo box, and simplifies DOM manipulation and XHR. All the while being written in very nice OO JS style (yes I said OO and JS, for those you are ignorant of JS capabilities take a look at http://www.litotes.demon.co.uk/js_info/private_sta tic.html and http://phrogz.net/JS/Classes/OOPinJS.html

The route these libraries/frameworks are taking is allowing you to build and thus include only the js you need for your particular use case. For instance, the best JS lib IMO is Ext http://extjs.com/ which has a dependency builder where you specify the framework you want to use (YUI, JQuery, or Prototype) and the capabilities you need (e.g just Core, DD, or choose from umpteen UI components).

At any rate the Dr Dobbs article was pretty poor, seriously outdated and lacking much in the way of details.
Dojo is nice, but I found it to be too slow and recently I think they realized they needed to re evaluate some design decision and set a clearer path on where they are taking dojo in the future. They have not released much in the last 6 months (a minor dot release to 4.1 I believe). It does have the great feature of graceful degradation cause it can take existing markup and convert to supa nice UI widgets, but this requires it to traverse the whole DOM and look for 'dojo' widgets. There are workarounds, e.g specifying the element ids for your widgets to be dojo-ized though. Still though, pages (really when using UI JS frameworks they are not pages anymore but applications) with a lot of dojo widgets can be very slow to render. In addition dojo has some rough edges such as poor docs, too many grids that make it feel like there is a lack of direction etc. I look forward to the next major release though, Dojo certainly has a ton of potential.

But the kick ass JS library right now is Ext http://extjs.com/. Its well documented, very polished, has just about any widget you need, a super nice data abstraction for the grid/editable grid/combo box, and simplifies DOM manipulation and XHR. All the while being written in very nice OO JS style (yes I said OO and JS, for those you are ignorant of JS capabilities take a look at http://www.litotes.demon.co.uk/js_info/private_sta tic.html and http://phrogz.net/JS/Classes/OOPinJS.html