Hi Jason,
That actually is a common complaint, and it's something we are actually investing quite a bit into resource-wise, into finding the best way to handle the user experience for Javascript based components, and for everyday users.
A quick question, are you guys taking advantage of the barebones javascript setting? This is something you guys can set in your portal.properties, and overwrite to limit the Javascript to just what you guys wish to use.
Right now, as of 5.1, the barebones JS is about 48k gzipped. It's not huge, but it's not trivial either.
So, the issue for us is that there is a tension between waiting for one large file to download and cache, and having multiple http requests for each component.
Now, I'll be the first to admit I'm not the smartest guy in the world, so if anyone has any cool ideas for solving this problem I am all ears, and would love to hear it, but I'll first list off a few of the ideas we've had, and some of the concerns.
One idea we've had is to lazy load the javascript, either via DOM insertion into the head, or ajax. With ajax, the issue is a matter of caching. We could manage this on the server side, and it's something we're actually going to look into over the next couple of weeks.
I know a lot of ajax heavy sites do this, and I think it works for them more because they usually have one product they're managing, whereas we are a framework and a product.
I'm not saying it can't work for us, but that there are a lot of considerations.
Another concern I have is that browsers don't do cache "chunking", meaning, if you download file1.js and it contains Module A, Module B, and Module C, and then you download file2.js, and it contains Module A, Module D, and Module E, you still have to redownload Module A all over again.
And since different portlets use different modules (and in varying combinations) the user would have to redownload the possible combinations (even if only 1 line of Javascript is different), meaning that the entire user experience degrades, though theoretically on paper, the Javascript is smaller.
There's also the issue of Javascript dependency and waiting for the Javascript to download asynchronously, even though the HTML that depends on the Javascript has already been rendered. This means the users will either think the elements are broken, or have to wait for the data to transfer over the pipe.
There are ways we can get around this, and we are working hard to make the portal use unobtrusive javascript as much as possible, but they aren't minor changes that need to be made, so it is taking a bit of time.
But hopefully that answers yours (and others) question about Javascript size, some of the considerations we're having to take into account, some of the challenges, and what our plans are.
I don't want to hijack this thread though, so if you have any more questions related to this, a new thread would probably be best
Answer