I've read the comments and thought about it some more. I don't think a New Project Type is the right approach.

The goal is fast initial load and not have a limit on application size.

Currently a Form is "Auto-Created" or not "Auto-Created". How about 3 options for a form: "Auto-Created", "Loaded" and "Dynamically Loaded"? Loaded would be like the current not "Auto-Created".

When an application is compiled, each of the "Dynamically Loaded" forms would be compiled to a separate javascript file. When a "Dynamically Loaded" form is instantiated and its code isn't in memory, the code would be dynamically retrieved. TForm could have an "Unload" method. If called on a non "Dynamically Loaded" form, it would generate an Exception. When called on an instance of a "Dynamically Loaded" form, it would close all instances of the form and remove the code from memory.

On 10/28/2015 6:11 PM, David Westbrook wrote:
> I'm wondering how large of an application can be built with EWB before the download size, startup time and memory usage becomes intolerable.

I don't think anybody has really tested but as Tim pointed out in
another thread there is the initial cost of getting the framework and
components included (absolute minimum overhead).

Based on my simplistic testing I'm seeing minimum app to be 310K JS file
but then one that's non-trivial (using web requests datasets, grid and
some 10 forms) is only 440K - both compressed.

So it would take a fairly large app it looks to get anywhere where this
is a problem - and you need to look into desktop vs mobile as well
(desktop browser seems to be multiple times faster than mobile - clearly
the desktop CPU is king)

Raul

On 10/28/2015 9:02 PM, David Westbrook wrote:
> Currently a Form is "Auto-Created" or not "Auto-Created". How about 3 options for a form: "Auto-Created", "Loaded" and "Dynamically Loaded"? Loaded would be like the current not "Auto-Created".

I'm guessing there are few aspects here:

1. Actual JS file itself and the need for JS engine to load it and
access it. I don't enough here to really comment (in terms of if this is
in ram or cached out to temp files) but note that even with dynamic
forms at some point this would result in same usage (once the dynamic
form is loaded in). And i don't think there would be any way to "unload"
these JS files (never heard of such ability in js engines).

2. Actual ram consumed runtime - i believe even today once you Free the
form the garbage collector will clean it up so it's not consuming
anything extra (other than whatever point 1 above consumes). Hence if
you create 100 forms and then free them at some point the ram should
return to what it was prior.

I do see that long term ability to partition app into multiple JS files
and do some controlled load would be useful - kind of like DLL on windows.

Raul

Just my 5 cents..... Web server static compression is your friend!

I also considered creating a separate login project due to the html and js file size and the fact that my clients use the apps on very slow satellite internet connections. I did a test and the EWB compressed output of the login project was 312 kb for the js file and 119 kb for the html file. Then I turned on static compression on my IIS server and they ended up being only 70 kb for the js file and 55 kb for the html file!! Then I started to think a bit and tried the same on my 43 forms project. EWB compressed it was 732 kb for the js file and 533 kb for the  html file. Then with static compression on my IIS it ended up with only 146 kb for the js file and 136 kb on the html file. So yea, a fairly large project with 43 forms now is only about 280 kb total. Based on that, I scraped my plan for the login project as my main project load fairly quick even over slow internet connections.

I do have to point out that I do all image loading at run time as storing them as base64 in the html file grew the file large. The only form that is auto created is the login form making the project load super fast.

So yea, after I learned not to include images in the project and use web server compression, I can't really complain with a 280 kb output. I'm very satisfied with that result

Eivind

Eivind wrote:

> So yea, a fairly large project with 43 forms now is only about 280 kb
> total. Based on that, I scraped my plan for the login project as my
> main project load fairly quick even over slow internet connections.

Thanks for that post - most interesting. I shall have to check on my
server doing compression - I think the Indy option has that enabled,
will check.

I think the key here though is that the discussion is solving a problem
that doesn't actually exist yet. If you are so restrained that every
byte counts for a second, then sure, you need to be taking desperate
measures, but that pretty much doesn't actually exist. Once you have
loaded it once, the browser will have it cached. The power that you get
from this single file is quite amazing, and the cost is one-off, with
no loading of another 15 libraries before it can start. The only worry
I have is when in a few years time we are writing mega-applications
using EWB and this does become an issue, but Tim will have solved it in
EWB5 by then. Or the browsers and internet will have solved it with
faster connections.

--

Matthew Jones

I've researched and agree that unloading JavaScript isn't possible. So, infinite application size can't be achieved.

Rather than a JavaScript file per "Dynamic Loaded" Form, one or more up to a configurable byte size limit could be grouped together into a singe JavaScript file. For example, when the size of a JavaScript file goes above 64kb, the compiler could stop building the current JavaScript file and start building a new one. A "Dynamically Loaded" Form would be wholly contained within a single JavaScript file.

When a "Dynamically Loaded" Form is instantiated and its code hasn't been loaded, then the application would load the JavaScript file associated to the Form. The file that is loaded may contain code for other "Dynamically Loaded" Forms.

David Westbrook wrote:

> For example, when the size of a JavaScript file goes above 64kb

What problem are you trying to solve though? If the application needs
those forms, then there will be no saving in the download, as it will
have to download them and it will actually take longer due to two
requests. Plus you may start the single-page-application, and then
leave connectivity, and then need the form. What then?

If you have an application that has a different set of forms for
different purposes or users, then have two applications. My web shop
for example has a load of common things, but some are admin forms so I
have another application for that. (As it happens, I completely split
them in the re-write for EWB2, as it seemed logically better.)


--

Matthew Jones

Matthew Jones wrote:

> What problem are you trying to solve though?

Since you ask..

I found myself re-clicking the link for my little app because nothing
seemed to be happening.
My site is mostly serving information, all the hard work being done
server-side, so I and my users are accustomed to an immediate response.
Then I click for my EWB app and it takes at least 2 whole seconds
over a fast broadband line to my gigabit LAN before I see anything.

Since the 'show load progress' does not cover that delay(!) I am
considering launching some 'I am working really hard on your request'
glyph/sprite/message on my web page before starting the download.  If
that indicator ran for 10 seconds or so it would cover the likely 'gap'
before the load progress bar (if needed) popped up and/or the EWB app
took over.

So that's what I want - some sort of server-side, visual
acknowledgement.  

Malcolm

On 10/29/2015 11:10 AM, Malcolm wrote:
> Matthew Jones wrote:
> My site is mostly serving information, all the hard work being done
> server-side, so I and my users are accustomed to an immediate response.
> Then I click for my EWB app and it takes at least 2 whole seconds
> over a fast broadband line to my gigabit LAN before I see anything.

Simple loader page should help in this case - for example something like
this :

https://s3.amazonaws.com/connexall.raul/3/loader.html

This one is a from testing i did while ago and not prettified and
currently waits 3 seconds before redirect but can be used to provide
some loading feedback.

Raul

Hi Raul

Yes, that was the sort of thing I was thinking of.
Except I don't think I have to redirect - just let it run for <long
enough> then close.
The EWB app will get the browser focus when it Shows.

Malcolm