SmartGWT core file size

[scott_rides_again@yahoo.com]

I've read where one cannot reduce the file size of core SmartGWT files. ISC_Core.js, etc.

It takes 13 second for my app to load(my ISP may have me on a small pipe, that is not the issue, my question is at the end.). My code is only 6k (right now)

Using fiddler, I compared the size of my core files to the ones that get loaded in the SmartGWT Showcase website.

My app compared to the SmartGWT Showcase website.

my ISC_Core.js = 623,000 Showcase = 160,000
my ISC_Grid.js = 615,000 Showcase = 155,000
my ISC_Foundation.js = 171,000 Showcase = 46,000
my ISC_Forms.js = 516,000 Showcase = 125,000

etc

Question:
No offense, but is this just a hack that makes the load time of the SmartGWT Showcase much faster or is there now a way to trim the files?

If it is a hack can you tell us how to do it?

I like the SmartGWT very much but I am afraid the current bloated load time is a show stopper for me. I might be interested in working to enable the trimming, if you guys need some help. I know something about compilers. This must be a known and fairly high profile issue.

I'll try the workarounds you guys have suggested and see what that gets me. I am encouraged by other's results, but I am a little disappointed that this is an issue. I noticed the bloat when I was evaluating SmartGWT, but made the wrong assumption, "They must have a way to trim all the fat, I'll figure that out when I get closer to deployment." Potentially a very bad choice on my part.

Thanks, Again, great product, I like the open source/fee based market strategy so I'm not complaining. Let me know if I can get involved.

[Isomorphic]

It's HTTP compression. It's on by default if you use Pro, otherwise if you choose to do it yourself, start Googling about HTTP compression.

PS. there's no "bloat" or "fat". Look at what the Showcase does and compare to any desktop app's installation footprint. The code delivers 100x functionality per byte as compared to other applications.

[scott_rides_again@yahoo.com]

Ok.

No need to get defensive. I see and accept your bias.

My idea of bloat is when a framework delivers code to the client that is unused.

SmartGWT can deliver all the functionality in the world to build a rocket ship on the client but if I only need to display a couple of canvas and images and maybe a few tables then everything that is unused is worthless bloat.

It just seems odd that SmartGWT does not parse out unused code during the compile. It doesn't seem that the code is so tightly coupled that you can't do that? I'm guessing it's a marketing ploy to get people to buy the Pro? Not a thing wrong with that, I'd just like to know so I can look for another solution. Maybe I'll write a parser.

[Isomorphic]

SmartGWT is not intended for an application that shows a couple of images and tables. It's intended for enterprise applications.

Crude, rough-grained component removal (like not loading the entire ISC_Forms module if you are not using forms) makes sense for certain applications. Beyond that, while the static code analysis that comes with GWT is not being applied to core JavaScript files, it would not make a substantial difference anyway - as can be seen with other large GWT-based frameworks like ExtGWT, introducing just a few components causes an irreducible core of about 600k to be introduced.

Static analysis is too weak of a tool to remove code for individual features like grouping or inline filtering in grids, which are necessarily inter-dependent. For this reason, if you have ultralight requirements and your requirements will continue to be ultralight, seek out a less feature rich component set. We have, for example, a parallel mobile component set in the works.

[scott_rides_again@yahoo.com]

Thanks for the response and all you and your team do here. I have benefited greatly.

Are there any plans for SmartGWT to remove unused files (as in your forms example) during compile time?

Again, thank you.

[Isomorphic]

We plan to put better documentation around manual fine-grained trimming first (you can already do this with Power or better via the FileAssembler). That may eventually be integrated with the GWT compiler. No ETA, but if you are interested in making it happen faster, consider Feature Sponsorship.

[scott_rides_again@yahoo.com]

I would if I could spend someone else's money. I am the CTO of a company of 1.

[Isomorphic]

Search the docs, not the web (docs.smartclient.com).

[scott_rides_again@yahoo.com]

Ok, so I removed the unused javascript files and saved a couple of megabytes of the initial download size.


[modulename].gwt.xml file
<!-- removed default load of all the scripts -->
<!-- <inherits name="com.smartgwt.SmartGwt"/> -->

<!-- Added no default load -->
<inherits name='com.smartgwt.SmartGwtNoScript'/>

[modulename].html file
<!-- include only the individual javascript files that my application uses. -->
<script type="text/javascript" src="[complete modul URI]/sc/modules/ISC_Core.js"></script>
<script type="text/javascript" src="[complete modul URI]/sc/modules/ISC_Foundation.js"></script>
<script type="text/javascript" src="[complete modul URI]/sc/modules/ISC_DataBinding.js"></script>

----> Is there a dependancy graph for for the code base? i.e. Widget A has dependancy ISC_Core.js, ISC_Foundation.js.


That helps, but I would like to get to the file sizes that are downloaded for the Showcase example.

I tried compression, but that only got me 3%.

The showcase files are 25% the size of the default files. One quarter of the default size.

----> Do you use the FileAssembler service to achieve this?

[scott_rides_again@yahoo.com]

Never mind the question above about the FileAssembler. I set Fiddler to apply gzip encoding and I get the 75% reduction in file size like the Showcase has. I must not have my web container Glassfish http-compression set up correctly.

I still would like to know if there is a dependency graph?

Thanks.

[Isomorphic]

In the source there are calls to a Packager class. The declared dependencies are known to be imperfect and need to be shored up with further automated tests (there are already tests in place for the modules boundaries we ship with - Forms, Grids, etc).

[scott_rides_again@yahoo.com]

In the source there are calls to a Packager class. The declared dependencies are known to be imperfect and need to be shored up with further automated tests (there are already tests in place for the modules boundaries we ship with - Forms, Grids, etc).

Thanks, I guess I am going to have to get to that level. I'll contribute if I can.

I found that now my solution above throws a javascript error that I did not see before. I'm hoping you can help because I can't explain what is happening.

PROBLEM:

What works:
*********************************************************
[modulename].gwt.xml
<inherits name="com.smartgwt.SmartGwt"/>

works as expected, Firebug in FireFox does not report any javascript errors.

<Firefox clear cache> run Netbeans project


Change to what throws a javascript error:
*********************************************************
[modulename].gwt.xml
<inherits name='com.smartgwt.SmartGwtNoScript'/>


[modulename].html
[... == type="text/javascript"]

<script ... src="[modulename]MainPage.nocache.js"></script>

<script ... src="[modulename]/sc/modules/ISC_Core.js"></script>
<script ... src="[modulename]/sc/modules/ISC_Foundation.js"></script>
<script ... src="[modulename]/sc/modules/ISC_DataBinding.js"</script>
<script ... src="[modulename]/sc/modules/ISC_Containers.js"></script>
<script ... src="[modulename]/sc/modules/ISC_Grids.js"></script>
<script ... src="[modulename]/sc/modules/ISC_Forms.js"></script>
<script ... src="[modulename]/sc/module/ISC_RichTextEditor.js</script>
<script ... src="[modulename]/sc/modules/ISC_Calendar.js"></script>

*********************************************************

Fiddler says these manually loaded SmartGWT files are the same files (name and size) as the ones loaded with the default loader.

<inherits name="com.smartgwt.SmartGwt"/>


CONCLUSION:
What is strange is that with all SmartGWT files included manually Firebug reports

ISC_DataBinding.js
isc.A is undefined.

I comment out ISC_DataBinding.js and the error moves to a different file and with something else undefined.

I did dozens of iterations like this to try and isolate the error. (BTW isc.A maps to a Java Hash method) Created a new project, added my code, same problem. Back and forth between working and not working. Removed all my code(java) including the [module].nocache.js file, same isc.A undefined.

Now with another new project, default loader works, the first time I use the user loaded SmartGWT files (all of them) I get isc.A undefined. I switch to the default loader, no error. I switch back and guess what? Yes, I bet by now you know the solution, the isc.A undefined error is gone.

PROBLEM DISAPPEARS:
So I am back to loading the files manually without javascript errors.

I've been burned by a browser not REALLY clearing it's cache before, so what I have reported may not be accurate.

Is this possibly a bug in the compiler? I can post my code, but unless I am getting burned by the browser I don't think the problem lies there, since I removed all of it many times and still got the undefined error.

Any thoughts?

Do you have suggestions for me to report more details?

[Isomorphic]

There is a specific order the libraries need to be loaded in. You put DataBinding too early, it goes after both Grids and Forms.

[scott_rides_again@yahoo.com]

FANTASTIC! I should have thought of that. DOH!

I was hoping for an easy solution. Thanks again.

Am I missing some documentation somewhere that says this? I thought I had read everything.

[scott_rides_again@yahoo.com]

I put the ISC_DataBinding.js without the Grid and Forms and after the Grids and Forms and have the same undefined isc.A in ISC_DataBinding.js.

I put ISC_DataBinding.js after ALL of the SmartGWT javascript files and get

$wnd.isc.DateRangeDialog is undefined

Line 334 5365DFWUY343244DAFSR.cache.html

I bet I missed the explanation of those *.cache.html files, so can you point me to the docs? That and the ordering of the files and maybe of some other posts where people successfully removed the uneeded files?

Or would you suggest I just bite the bullet and build and package my own with FileAssembler?