I'm well into my first real EWB project and have even put out a beta for testing purposes. I'm getting only positive feedback from users. I love working with EWB

The project as for now consists of 15 forms where all are created dynamically and destroyed when not in use.
I'm using the EWB-Server with custom modules.
As the project moves on I see the need of many more forms 15-20 and also more data sets.

Should I be concerned about the size of the project (and correspondingly the size of the java script file) in terms of loading time and performance for the site?
If so, what would the best way to "modularize" things?
Are there some best practice advices?  

I have tried searching the forum, but have not found any discussions on this matter.

Br
Petter

+1 from me on this question.

I have asked a related one here (http://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&msg=7548&page=1) regarding profiling.

Coming from a PHP background, I'm used to a light client and a heavy server, with regular page refreshes to flush out the DOM and all it's detritus. Maintaining the DOM for the life cycle of the user's session is a bit alien to me and I am concerned that I am unwittingly eating up resources.

squiffy wrote:

> Coming from a PHP background, I'm used to a light client and a heavy
> server, with regular page refreshes to flush out the DOM and all it's
> detritus. Maintaining the DOM for the life cycle of the user's
> session is a bit alien to me and I am concerned that I am unwittingly
> eating up resources.

From what I've heard on podcasts, a lot of javascript is indeed written
with the idea that it will last minutes and then be flushed. SPA
javascript on the other hand needs to be aware of memory management.
EWB uses the same memory management as a Delphi programmer will be used
to, with try/finally to allow you to dispose of objects with .Free. So
long as you are generally aware of destroying the objects or otherwise
managing their memory, I think you will be fine. If you keep creating a
form and assigning it to the same variable, I suspect you will be
leaking lots.

You can track your resource use with the Chrome tools, and so far I've
not had any problem with this sort of thing.

--

Matthew Jones

On 10/2/2015 1:39 AM, Petter Topp wrote:
> Should I be concerned about the size of the project (and correspondingly the size of the java script file) in terms of loading time and performance for the site?
> If so, what would the best way to "modularize" things?

One of the strengths of the EWB is that everything is in a single JS
file - so that there is only 1 download by the browser (thus saving on
multiple requests and latency associated) and once it's downloaded it's
"all" there.

> Are there some best practice advices?

Javascript does do garbage collection so if you free the objects you
should be ok. Anything else not dynamically allocated (like long
strings) you should be able to "release" by clearing the value to
empty/nil string (if it's global variable and lives app lifetime).

Matthew's advice on using browser tools is a good one as well.

Raul

On 10/2/2015 8:59 AM, Raul wrote:
> One of the strengths of the EWB is that everything is in a single JS
> file - so that there is only 1 download by the browser (thus saving on
> multiple requests and latency associated) and once it's downloaded it's
> "all" there.

And of course make sure "compress output" option is on. In addition
depending on the server you serve from you can enable compression as
well to reduce download size even more.

How big is the js file now ?

Raul

Hi Raul.

The size of the js file is so far 1.5MB...

Given the answers, I guess that i boils down to the size of the JS-file.
A daft question; given different devices and browsers, at what point/size will loading the JavaScript be an issue in terms of lag/performance?
Does anyone have experience with this?

Petter

Petter,

<< The size of the js file is so far 1.5MB... >>

Is that with, or without, compression turned on ?

<< Given the answers, I guess that i boils down to the size of the JS-file.  A daft question; given different devices and browsers, at what point/size will loading the JavaScript be an issue in terms of lag/performance? >>

It's only a drag the first time it's loaded.  After that it's cached by the browser, and its size becomes irrelevant until the next time it's updated.  IOW, for 99% of the time that the user uses your application, the primary drivers for UI responsiveness will have nothing to do with the code size, and everything to do with things like how the application treats the GC in terms of allocations/de-allocations, how often the application interacts with/updates the DOM, etc.  And EWB is *very good* in these areas.  Many JS-only applications abuse the heck out of the GC, which is why they slow to a crawl and start consuming memory like crazy (+1GB) after even a minimal amount of usage.

Tim Young
Elevate Software
www.elevatesoft.com

Tim, the size is without compression.

So what you are saying is that I really should not worry about adding to my project.
A rough estimate will be a JS-file that is approximately 2-3 times the size it has now...

Great work Tim.

Petter

Petter,

<< Tim, the size is without compression. >>

With compression that JS file will be about 1/3 that size, and the same goes for the HTML loader file, which is also compressed extensively (especially the control interface/form JSON files).

<< So what you are saying is that I really should not worry about adding to my project.  A rough estimate will be a JS-file that is approximately 2-3 times the size it has now... >>

Well, there are of course reasonable limits, but I wouldn't start to worry too much until the compressed size gets to be around 1.5-2 MB.  At that point you *may* want to consider splitting things up by using a frame (TBrowser) with an "outer application" that loads the "parts" of your application, which are simply other EWB applications.  Frames can communicate back and forth with the parent application (something that I need to surface better in the TBrowser control), so that's an option when things get that big.

Tim Young
Elevate Software
www.elevatesoft.com

<<
Tim, the size is without compression.
>>

You'll then be able to reduce the size even more by enabling the option (it also doubles as type of obfuscation and makes it harder for people who are curious to poke around "under the hood")

<<
So what you are saying is that I really should not worry about adding to my project.
A rough estimate will be a JS-file that is approximately 2-3 times the size it has now...
>>

I like to quote Donald Knuth here : "Premature optimization is the root of all evil"

Implement the features and then worry about optimization later (this of course does not mean you should not architect it right

<<
Great work Tim.
>>

EWB keeps blowing me away - in terms of what Tim has been able to write

Raul