Whoa momma that's some hefty js!

[audiopleb]

I've just added a form to a page and then looked at the page size.

Woweee!

I make that 168kb in js just for fabrik!

My page has doubled in size (and it was too big in the first place)!

Is there anyway to reduce the size of the javascript fabrik requires?

[cheesegrits]

Well, first off, it's all cached after the first page load. Check Firebug under the NET tab. Select JS on the top row, then load the page again. Down at the bottom it'll tell you "xx Kb (yy Kb from cache)". Mine tells me "166Kb (166Kb from cache)".

If you really need to shave a few Kb off the initial page load, you could always use one of the various JS packers, and pack the table and form JS. Mootools should already be packed.

The calendar and overlib stuff will usually already be cached from other Joomla pages.

And remember that about half of that is Mootools, which in Joomla 1.5 becomes a standard part of Joomla, so it'll no longer be a Fabrik specific overhead. We're basically in a transition phase, getting ready for The Brave New World of J!1.5.

Bottom line is, you pay a price for the generic abilities of Fabrik. Because we don't know what you will be doing, we have to have a lot of code to handle every eventuality, and build and execute complex on-the-fly structures on the page. If you were building a custom app from scratch and knew exactly the feature set you needed, you wouldn't need a lot of that JS. It's a trade off.

But really, I don't think 166Kb is a huge problem unless you are targeting low bandwidth dialup holdouts. Most sites I see these days have banner images bigger than that! And especially as we use 'onload' events to set everything up, so we're not holding up page loading waiting for the JS. The visible page loads, and the JS triggers when the underlying DOM load is complete.

-- hugh

[rob]

one thought is that we could check for the need for the slimbox code? - its always loaded even if its not used.
Thats more your baby Hugh, do you have any thoughts?

Rob

[audiopleb]

Yes i know it's cached, but i have only got one form so a new visitor is only going to use the page once in theory.

The calendar and overlib stuff is not present on any other part of the front end of my site.

But anyway, i see your point. My site is all about b2b traffic so size shouldn't matter too much. I think perhaps i'm stuck in the past, anything over 60kb is too much to my mind.

[cheesegrits]

I did look at only including the slimbox code only if it is used, but I was trying to be a good boy and put the CSS and JS includes into the head section, and of course there's the catch 22 of not being able to modify the head beyond a certain point in the code, where that point is a moving goalpost depending on whether we're running as a component or a module or a mambot.

And I can only tell if the code is needed once we get into the guts of the table or the form, to see if there are any image elements we need to display. By which time it's too late, even if I start including the JS and CSS in the body rather than the head.

It got sufficiently complex that I just gave up and threw it in the header regardless.

It's just one of those tradeoffs with a generic app builder like Fabrik, which can't make any assumptions ahead of time about what it is being asked to do. IMHO, if people are worried enough about 30Kb of JavaScript on an initial page load, or other resource issues like that, they need to be building their stuff as custom apps in the first place, not using something like Fabrik.

-- hugh

[audiopleb]

Alright Hugh, point taken.

[cheesegrits]

Sorry, I didn't mean to sound so aggressive. Was just trying to explain my reasoning.

I totally understand that those of us who grew up building sites mostly targeted at dialup users have a natural aversion to "page bloat". But in this Brave New World of ubiquitous broadband, we just have to adjust our sites a little.

-- hugh