> While somewhat unintuitive, I have indeed learned that fewer bigger requests can load quicker than many small requests - which does makes sense, I guess obsessing about caching isn't everything. (https://news.ycombinator.com/item?id=13601451 / https://danluu.com/web-bloat/ - particularly the 3G bits, since lots of people tether)

There are some valid points to be made about bloat, and Elevate Web Builder's monolithic applications do tend to be on the larger side. However, the big issue is always perceived load time, and that's what we always work on improving first. The size of the application itself only really matters on the first load after a change/re-compile/re-deploy, provided that you don't have a bug in your web server that complete negates this performance improvement. ;-)

> Ah, I see, that's the app server.

Yeah, and it's going to be getting some attention before summer, specifically with GZip and SSL support. The general idea is that (eventually) we're going to be adding the Object Pascal run-time engine that is currently used in the IDE at design-time to the web server, thus offering the same language for the entire stack. When you work with controls/components in the designers in the IDE, the run-time actually executes code from the component library, which is why scrollbars work and you can click on buttons in controls to add new sub-controls, etc. It's nice for a control/component developer because they only need to set a simple flag that indicates that they want design-time events for a given control, and the IDE/component library takes care of the rest.

> Now I'm wondering whether your UI architecture is abstracted enough that end-users could build UI components out of JS... hmm, that probably wouldn't work, the UI designer wouldn't be able to control them. (I'm guessing you can design your own controls in Pascal?)

That's a very astute observation, and 100% correct. :-) The easiest way to use external JS controls in Elevate Web Builder is to use a TBrowser control, which is simply an iframe control that will isolate the control from the "normal" UI controls. However, it's also very easy to just create a wrapper control in Object Pascal that interfaces with the JS, which is what we did with the TMap control for Google Maps support.

The whole IDE is designed around the idea of creating and installing your own controls/components, just like in Delphi. And, more importantly, it is a lot easier because there are simple UI element building blocks (in the virtual DOM) to use for building up controls, with the UI elements doing all of the heavy lifting and modifications being simple property changes/method calls.

> That's a great development model, and one I've considered myself (providing source to a large portion of the codebase to accelerate urgent fixes).

It's pretty much been the "Delphi" way of doing things since it was first created and sold by Borland, so we can't really take credit for it. It' funny, though, because it pre-dates open source. I never used Turbo Pascal, but I think it did something similar, and it really pre-dates open source.

> I was wondering how the Pascal bit worked for a while there. I'm curious if you pulled in another language implementation or built your own; I'm guessing you went full crazy and made your own implementation, considering you compile to JavaScript? :) (not sure though, Wikipedia mentions that Smart Mobile Studio have a JS-targeting implementation)

We had some experience doing an interpreter in our SQL implementations for our database engine products, so it was a natural move for us. The most difficult portion was building the run-time execution engine, mentioned above.

(continued below)