I can't remember if I already asked this, and can't see it, so is there any plan
(or optional tool set insertion) that would allow the javascript output to have
redundant code removed? The output appears to include a large number of utility
routines, many of which won't be used by a particular set of code. I showed my
application to someone, and the 200k file was a lot larger than he expected. 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.

Anyway, it isn't too important (it all works fine on the devices I've tried), but
it was just more of a wonder. (Which is also why I suggest some sort of tool
insertion, so that during the compiling an external exe is called if it exists,
with the javascript file as parameter, so that something else can run an analysis
and remove parts if appropriate. Then you don't have to worry.

(I see from
http://stackoverflow.com/questions/1167663/is-there-a-tool-to-remove-unused-methods-
in-javascript that it may not be easy, but then there are tools even so
http://stackoverflow.com/questions/1169889/find-unused-javascript-functions )

/Matthew Jones/

On 2/28/2013 10:38 AM, (Matthew Jones) wrote:
> I can't remember if I already asked this, and can't see it, so is there any plan
> (or optional tool set insertion) that would allow the javascript output to have
> redundant code removed? The output appears to include a large number of utility
> routines, many of which won't be used by a particular set of code. I showed my
> application to someone, and the 200k file was a lot larger than he expected. 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.

EWB does this already - code emitted is referenced in the application.
Number of the function you see might be something that framework itself
calls so they get included due to them being on a possible code path.

There is an option in Project Options -> Compilation -> Compress Output
that should reduce the JS size at the cost of readability. You can also
use this to do basic obfuscation since it replaces variables and
function with short versions and removes whitespace etc.  Last time i
tried it it reduced size to approx 50% of original but that varies.

Raul

Matthew,

<< I can't remember if I already asked this, and can't see it, so is there
any plan (or optional tool set insertion) that would allow the javascript
output to have redundant code removed? The output appears to include a large
number of utility routines, many of which won't be used by a particular set
of code. >>

As Raul indicated, EWB's compiler does reference checks and includes only
the code that is actually referenced by other code.  Do you have an example
of something that is being included that you don't think should be included
?

<< I showed my application to someone, and the 200k file was a lot larger
than he expected. >>

What did he expect ?  EWB is including its entire framework (again, only the
parts that are referenced) in the output, and 200k is nothing for such a
framework.  ExtJS is 700kb, minified (compressed).  Also, remember that the
application is going to be cached in the browser, so if it doesn't change,
then it will only get downloaded once.

<< 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. >>

I'm not sure what you mean here - is he including a 3rd party JS library, or
EWB/Object Pascal code ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Indeed, the the compression is significantly smaller. Thanks for the response - I
guess a lot of the magic of the system is using what is there.

/Matthew Jones/

> As Raul indicated, EWB's compiler does reference checks and
> includes only the code that is actually referenced by other code.  
> Do you have an example of something that is being included that you
> don't think should be included ?

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.


> << I showed my application to someone, and the 200k file was a lot
> larger than he expected. >>
>
> What did he expect ?  EWB is including its entire framework (again,
> only the parts that are referenced) in the output, and 200k is
> nothing for such a framework.  ExtJS is 700kb, minified
> (compressed).  Also, remember that the application is going to be
> cached in the browser, so if it doesn't change, then it will only
> get downloaded once.

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.


> << 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. >>
> I'm not sure what you mean here - is he including a 3rd party JS
> library, or EWB/Object Pascal code ?

He has used "pure" javascript, and references at least one third party library in
his code. As I said above, I suspect that's the key difference - his own code is
smaller, but the combined application is of similar size. Appearances can be
deceptive!


/Matthew Jones/

<< 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. >>

Personally, IMHO, I don't see any benefit in separating them.  Having them combined avoids deployment headaches.

On 2/28/2013 3:39 PM, Steve Gill wrote:
> << 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. >>
>
> Personally, IMHO, I don't see any benefit in separating them.  Having them combined avoids deployment headaches.
>

Not to mention that if there was a separate framework file it would have
to include the whole framework in it so overall size would be up.

Raul

There could be cache benefits to a single file, but I suspect that the likelihood
of anyone using it having a CDN to make it worth doing is low. I'd rather have EWB
have the total flexibility that a single file provides.

/Matthew Jones/

Raul,

<< Not to mention that if there was a separate framework file it would have
to include the whole framework in it so overall size would be up. >>

More importantly, it cannot be compressed as efficiently.

Tim Young
Elevate Software
www.elevatesoft.com

Matthew,

<< There could be cache benefits to a single file, but I suspect that the
likelihood of anyone using it having a CDN to make it worth doing is low.
I'd rather have EWB have the total flexibility that a single file provides.
>>

The issue isn't size as much as it is the number of requests, although very
large files will take longer, of course.  The lower the number of requests
during app loading, the faster the loading.  This is why the theme css files
have all images embedded in them.

Tim Young
Elevate Software
www.elevatesoft.com