5 ms·

> While somewhat unintuitive, I have indeed learned that fewer bigger requests can load quicker than many small requests - which does makes sense, I guess obses

> 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://news.ycombinator.com/item?id=13601451 / https://danluu.com/web-bloat/ 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)

i336_ 10y ago
>> While somewhat unintuitive, I have indeed learned that fewer bigger requests can load quicker (...) > 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. Totally makes sense. Taking bandwidth into account too is important, but yeah, user perception... :) > 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. ;-) Cool view :) There's also the fact that browser caching can be terribly broken: I unfortunately can't find it right now but I read somewhere of how a dev found Safari on their iPhone was only caching a few KB (!!!!) of Web content. Obviously something was broken somewhere (maybe Safari used a disasterously incorrect percentage-of-free-space calculation) but yeah. I have to admit that I'm considering hand-rolled ServiceWorker-backed caching systems myself; the only infuriating question is where to actually store the data (ref http://stackoverflow.com/q/42288596/3229684 http://stackoverflow.com/q/42288596/3229684). >> 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. Nice! > 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. Oh coool. > 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. I noticed that from the video! Really cool feature. >> 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. Oh, of course.... > 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. It might be a very interesting idea to create wrappers for popular libraries. I'm not quite sure which libraries to support, but "look at this island written in Pascal" is suddenly very interesting when you go "and here's the dead-simple interop to this bunch of other things you already know". > 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. I have to admit that I really like the visual design way of doing things. I played with Visual Basic just under a decade ago but I'm glad I moved on from it as it didn't impose enough architectural structure. I poked Lazarus recentlyish; it's on the todo list. :P (especially considering its Linux support) >> (...) (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. Ah, interesting! > 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. "Shared source"? >> I was wondering how the Pascal bit worked for a while there. (...) > 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.* I think you're referring to WebUI.wbs...? 13k LOC (5448 without {...} blocks, 6076 with {$IF}s, apparently) is pretty crazy, yeah.

i336_ 10y ago

>> While somewhat unintuitive, I have indeed learned that fewer bigger requests can load quicker (...) > 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. Totally makes sense. Taking bandwidth into account too is important, but yeah, user perception... :) > 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. ;-) Cool view :) There's also the fact that browser caching can be terribly broken: I unfortunately can't find it right now but I read somewhere of how a dev found Safari on their iPhone was only caching a few KB (!!!!) of Web content. Obviously something was broken somewhere (maybe Safari used a disasterously incorrect percentage-of-free-space calculation) but yeah. I have to admit that I'm considering hand-rolled ServiceWorker-backed caching systems myself; the only infuriating question is where to actually store the data (ref http://stackoverflow.com/q/42288596/3229684 http://stackoverflow.com/q/42288596/3229684). >> 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. Nice! > 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. Oh coool. > 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. I noticed that from the video! Really cool feature. >> 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. Oh, of course.... > 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. It might be a very interesting idea to create wrappers for popular libraries. I'm not quite sure which libraries to support, but "look at this island written in Pascal" is suddenly very interesting when you go "and here's the dead-simple interop to this bunch of other things you already know". > 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. I have to admit that I really like the visual design way of doing things. I played with Visual Basic just under a decade ago but I'm glad I moved on from it as it didn't impose enough architectural structure. I poked Lazarus recentlyish; it's on the todo list. :P (especially considering its Linux support) >> (...) (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. Ah, interesting! > 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. "Shared source"? >> I was wondering how the Pascal bit worked for a while there. (...) > 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.* I think you're referring to WebUI.wbs...? 13k LOC (5448 without {...} blocks, 6076 with {$IF}s, apparently) is pretty crazy, yeah.