[Isomorphic]

The correct ordering (Core, Foundation, Containers, Grids, Forms, DataBinding) is shown in the SmartClient QuickStart Guide. That's basically the level you're working at - the underlying SmartClient engine.

.cache.html is a core GWT thing - see the docs provided by Google for background.

[scott_rides_again@yahoo.com]

It was the container file that was causing the problem. I put them in the order you suggested and the javascript error is gone, in the SmartGWT files and the GWT files.

Thanks.

[scott_rides_again@yahoo.com]

Well, in reality all of the default files are required even for a basic site that uses Canvas, VLayout and Img, except Grid, Forms, Editor and Calendar. Such tight coupling. I never would have expected that.

You mentioned a mobile version in development? I'd expect this to be a new design? It would have to be. Is this a released product yet? I can't seem to find information on it.

I think I might take your advice and go to a simpler, smaller framework. Maybe just GWT, I'll have to check it out.

I'll alpha or beta your mobile version for a few if it's ready?

[Isomorphic]

??? you certainly have a tendency to criticize quickly, don't you?

It's not clear what you mean by "core files" or what specific dependency you don't like, but as an example, ListGrid uses Layout for it's header, and Layout uses Canvas for correct auto-sizing. This is re-use, not "tight coupling". The last thing that is going to make a final, delivered application smaller is many parallel implementations of the same thing.

There are many scenarios where eliminating some of the default modules provides big reductions, and fine-grained trimming can save more (removing, eg, everything related to Trees for an application that doesn't have them).

But again, if you're looking to build a site that involves nothing more than a couple of images in a layout, SmartGWT is absurd overkill, even GWT is overkill.

Finally, you should take a step back and consider the actual drivers for your application's performance. Right now, you're extremely focused on download size. SmartGWT targets enterprise applications, and in such applications, download size is often irrelevant.

[scott_rides_again@yahoo.com]

??? you certainly have a tendency to criticize quickly, don't you?

My intent was not to criticize, but to express disappointment at my misconception.

It's not clear what you mean by "core files" or what specific dependency you don't like, but as an example, ListGrid uses Layout for it's header, and Layout uses Canvas for correct auto-sizing. This is re-use, not "tight coupling". The last thing that is going to make a final, delivered application smaller is many parallel implementations of the same thing.

You are quite the advocate... :)

Code re-use is a given. One thing that makes a deliverable smaller and faster is compiler optimization.

Core files. I should have said all the files. All code compiled and shipped all the time.

The Fire Hose anti-pattern. All I wanted was a drink of water...

GWT does compiler optimization. I assumed SmartGWT would to. I also assumed tight coupling was the reason it does not, but now I think it's just a part of the project that has not been addressed yet, since entire unused files like ISC_Forms.js, if not used, are still delivered to the client.

For example, I ported my application to GWT and GWT compiles only the source code I need. The same application code(just SmartGWT, not mine) that is 2.6mb in SmartGWT is 20k in GWT.

FYI, I'm not just referring to removing unused files from the deliverables.

GWT will compile

List<String> list;

with all possible List types.

I can specify

ArrayList<String> list;

and only get the code associated with ArrayList. (Or so I am told...)

Are there plans to do this kind of optimizations?

There are many scenarios where eliminating some of the default modules provides big reductions, and fine-grained trimming can save more (removing, eg, everything related to Trees for an application that doesn't have them).

So, if I understand correctly, by default SmartGWT does not eliminate default modules or do the fine grain tuning? It would seem that even a few tweaks to the configuration would get you a long way?

Any plans to? I can't offer any money, but I can offer time?

But again, if you're looking to build a site that involves nothing more than a couple of images in a layout, SmartGWT is absurd overkill, even GWT is overkill.

Finally, you should take a step back and consider the actual drivers for your application's performance. Right now, you're extremely focused on download size. SmartGWT targets enterprise applications, and in such applications, download size is often irrelevant.

GWT isn't overkill even for small applications, since it does optimizations. SmartGWT wouldn't be either, if it did.

IMHO, response times for the end user, if greater than instantaneous has room for improvement, especially in the enterprise environment making download size relevant.


GWT/SmartGWT is a game changing framework. Programming/debugging in Java yet delivering javascript is a great model, for all applications. That is why I use it.


Thank you for your help and the, er, lively exchange?

[Isomorphic]

For something like 95%+ of the applications that SmartGWT targets, reducing initial download time would have no appreciable impact on performance, because the framework is cached on the first use.

We haven't gotten around to trimming because other means of optimization (more intelligent data re-use for example) have a much, much larger impact on actual performance. Remember, the framework downloads once ever - that's one response. Thereafter, the user will have anywhere from 100 to 100,000 occasions where the user is waiting for a response from the application - we focus on tuning those (see eg, Adapter Filtering).

As far as GWT not being overkill for tiny applications, that is precisely because it cannot do any of the things SmartGWT can do. GWT-based frameworks that begin to implement partial subsets of SmartGWT functionality show an irreducible core size as soon as a few widgets are introduced (specifically, ExtGWT, approximately 600k).

This is again because the compiler optimization is just static analysis. It cannot tease apart complex inter-dependencies, such as how inline editing is affected by grouping.

In theory, something like a grid component could be written as independent modules communicating over an event bus, and in such an organization, static analysis could tease it apart. But this would make the size of delivered code much larger when most modules are in use, and turn the developer-exposed API into a nightmare - a blizzard of different objects with overlapping settings.

If you're particularly excited about trimming and you really want to help, take the Packager calls in the JS source and turn then into a dependency tree, build a tool that displays that as a TreeGrid with cascading selection enabled so that users can pick what widgets they are using, and then can click a button to obtain a FileAssembler manifest for the needed files.

Then, for further trimming, add markers to files so that code involved in particular features can be stripped out (you can see such markers in the source already, like //>IE6). For example, large chunks of the inline editing subsystem could be removed this way - far more than static analysis would be able to trim.

It's a straightforward process but certainly couldn't be considered "low hanging fruit", and this is why we pursue other optimizations that have more of an effect on actual user experience. But feel free to tackle this, and if you're seriously committed to the work, we'll help.

[scott_rides_again@yahoo.com]

Great explanation. I'll stop spending your time on this dead horse.

I understand that SmartGWT has a target audience and you can't please all the people all the time. I fell outside that target and was just a little miffed. (For no good reason, as it turns out.) My apologies.

Now that I have spent so much of your time I should put my time where my mouth is and help out.

Let me consider what you suggest and see if I can do something about it.