Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 11 to 20 of 31 total |
Suggestion: New Project Type - Form Library |
Wed, Oct 28 2015 9:02 PM | Permanent Link |
David Westbrook | 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. |
Wed, Oct 28 2015 9:15 PM | Permanent Link |
Raul Team Elevate | 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 |
Wed, Oct 28 2015 9:21 PM | Permanent Link |
Raul Team Elevate | 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 |
Thu, Oct 29 2015 3:54 AM | Permanent Link |
Eivind | 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 |
Thu, Oct 29 2015 5:39 AM | Permanent Link |
Matthew Jones | 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 |
Thu, Oct 29 2015 7:07 AM | Permanent Link |
David Westbrook | 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. |
Thu, Oct 29 2015 8:48 AM | Permanent Link |
Matthew Jones | 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 |
Thu, Oct 29 2015 11:10 AM | Permanent Link |
Malcolm Taylor | 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 |
Thu, Oct 29 2015 11:31 AM | Permanent Link |
Raul Team Elevate | 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 |
Thu, Oct 29 2015 1:38 PM | Permanent Link |
Malcolm Taylor | 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 |
« Previous Page | Page 2 of 4 | Next Page » |
Jump to Page: 1 2 3 4 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |