Matthew,

<< The top few lines of the source have functions like date(), dayof(),
doubletostr() and encodedate(). I'm not using anything like that, so that's
what set me wondering. Of course they may be key to the framework, but it
looks like (as usual) you are way ahead on the thinking about all this stuff
and remove things not used.  >>

Those are "built-ins", but they are also reference-counted and should not be
present if they aren't referenced.  However, the "is it referenced" code is
not 100% as picky as it could be right now, and still considers methods
referenced if the containing class is referenced.  I'll probably make this
more picky at some point, but right now it's "good enough".

<< I think that is the key - the expectation was that there would be the
framework separate to the application code. The combination makes it seem
more. >>

Except for JS scripts that are dynamically loaded (not common), you can
normally see what is being loaded for a page right in the HTML file, and
EWB's HTML loader file references one single JS file.  Plus, all browsers
include a Network sniffer as part of their developer panel that allows you
to see exactly what files are loaded by any HTML page/JS application.

<< Or perhaps the code can be split between a library file and the
application specific source? I notice (checking his code) that he includes a
library of 126k. >>

So, at least one of the JS libraries that he is referencing is almost as
large as the entire EWB application and framework combined, and he thinks
*EWB* is too large ?

Tim Young
Elevate Software
www.elevatesoft.com

In my opinion Tim is perfectly right with his optimization approach, to generate few larger files instead of many small files, because network latency throttles the transfer more than the raw network throughput.

And with a small server tweak the files even shrink by factor 3 up to 4:
Just alter the default configuration (example apache): httpd.conf
add: text/x-js text/css
at the end of the existing line, so that it looks like:

<Location />
       AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js text/css
</Location>

The result is a smaller transfer size:
default.css Content-Length: original   90.477  --> 30.872 when deflated
project1.js  Content-Length: original 199.132  --> 44.456 when deflated

continuation from previous post:

Forgot to mention an idea:

To embed the default.css into the html file, that would save just another request/response cycle.

... and the js file could be embedded as well, so that the html file would be self contained.

I must look into this. Chrome says that gzip would be better, but my server code
does have gzip and should be using it. I must work out why not.

/Matthew Jones/

Claudia,

<< To embed the default.css into the html file, that would save just another
request/response cycle. >>

True, but I'm wondering if it's better to have them cached by the browser
separately.  There are still some "gotchas" here in that EWB emits a new
copy of the HTML/CSS files during compilation even when it's not necessary,
so you end up with these files having their modification dates changed,
which will mess up the client-side caching.  But, those can be solved.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com