Wow, thanks for taking the time to reply!
> 1) The "volume control" (...) used a progress bar instead of an actual draggable horizontal gauge (not available).
Ah, that's the name of what I was looking for. I think HTML5 sliders can be styled similarly to how the volume control looks, but I understand you're targeting a wide variety of Web browsers here.
The reason I mentioned it was because I'm used to being able to drag volume controls directly - I'm not used to them being output-only. I guess I was deliberately looking for cracks in the design, to be honest :)
> 2) (...) [Y]ou also have the option of turning off both embedding of the icon font and whether the icon font is included at all (both are compiler options). In general, Elevate Web Builder always tries to keep the number of requests required to load the application to a minimum, hence the very aggressive in-lining of everything.
Oh, loading as a separate resource is is available as an option. Cool.
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)
> 3) The If-Modified problem is a bug, and a really embarrassing one at that (I'm installing a fixed server this afternoon). There's a millisecond file timestamp comparison issue that is causing the If-Modified to never kick in.
Ah, I see. Comparison between 1488416112 and 1488416112.336420126? Completely understandable.
> The web server that we provide is just a "nice to have" thing because it automatically handles the database JSON API for loading datasets and consuming transactions, so that's how it's typically used, with less usage for static resources.
Ah, I see, that's the app server.
> Larger customers typically implement their own back-end database handling for IIS, Apache, etc. It's pretty easy to implement and the JSON API is very simple.
That makes perfect sense.
> 4) In terms of interoperability with JS, you can include external JS source with any project and it will get deployed with the project. After that, you also need an external interface to the JS code so that the compiler knows how to resolve any of the JS symbols: (...)
Oh, nice! So you do have interop. That makes quite a lot more possible.
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?)
> 5) As for issues and how they are resolved: we're pretty responsive regarding support/bugs, but Elevate Web Builder includes source code to the entire run-time and component library, so you're free to modify most of the product and we're able to give immediate hot fixes for most issues (~90% of issues/bugs are in this code and not in the IDE/compiler). In fact, you could take the command-line compiler that we separately provide and use it to create your own Object Pascal <--> JS IDE/product.
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).
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)
> 6) We've mentioned the product here before and it's received mixed reactions. It is, without a doubt, an odd product for most developers coming from traditional web development. :-)
Yep. I can see the niche for this though. Plus, diverging from the mainstream means you get to neatly sidestep the frenetic insanity associated with the cutting edge, which can be really really nice if you find something that pays well. :) (Still looking for my own one of that)
> There are a lot of design choices that go against what one would recommend when hand-coding an HTML/JS/CSS application, but work beautifully when you're talking about a compiler doing the work for you.
Unfortunately modern Web development has gotten so caught up with layers and layers of tooling and compilation, even hand-coded apps are beginning to resemble sprawling enterprise apps. :/
But you make a good point.
> The main point of the product is to capture the productivity that Delphi provided in the desktop arena and bring it to web applications. This means an intense focus on performance, reducing dependencies and deployment issues, and ensuring that one can concentrate on the business task at hand.
Yeah.
> Here is a "Hello World" in Elevate Web Builder:
> (...)
> Contrast that with the setup/coding involved to get any sort of hand-coded web application up and running. You can see how this works in more detail here: (...)
Before I watched the video I was half-scared this was a slightly more built-out Pascal-based iteration of the old BAT2EXE "batch compilers" that could never do anything. My apologies :)
I can now see this is essentially a GUI builder connected to a Pascal>JS transpiler. That's really cool.
And yeah, this is much quicker than finding a grid display library that actually works, building an efficient data model to load data into it, handling network issues... hides under box
> If you download a trial version, you can get a feel for the technology in the product by looking at the WebUI unit (WebUI.wbs).
With signing up... really like the "Real name" vs "Displayed name" vs "User ID" distinction! Hm, idea: <label>s for the input fields on the new user form... oh, and what's the automatic signup rate with your current captcha?... ahh, consider NOT sending the user password back through failed forms... definitely definitely consider HTTPS for at least the signup form (!!!)... and maybe redirect the user to the page they were on when they clicked the signup link. The site design is very nice though.
(Regarding the captcha system, you have me confused and very curious. Are you hashing the current time, or adding hash codes to a DB...? The PNG URL has no parameters in it! :P)
> It's a ~13k-line UI layer that implements both the design-time external interface and a run-time virtual DOM that allows for very fast performance due to its BeginUpdate..EndUpdate reference-counted update cycle functionality. The run-time avoids interrogating or touching the DOM like it has the plague. ;-)
It could be very fun to pit your virtual DOM against React's. :D
I wouldn't be surprised at all if yours won out - I think React tries to "guess" by itself when to push its virtual DOM to the screen, and it constantly gets it wrong of course. A reference-counted approach with "don't update for a minute" boundaries sounds very simple and elegant. So I'm serious, benchmarking your system against React's could be quite interesting; but the problem would of course be in finding React-based controls to compare against.
Also, Pascal doesn't actually look that bad. I've been meaning to get around to having at least a passing knowledge of it for a while...
> It will also show how the animation primitives work
Ah, the world of HTML4.999999999999
> along with how the control interfaces are implemented. The control interfaces allow you to selectively skin controls on a per-control, per-project basis, with on-demand loading of the customized skins for each project at design-time.
Huh, very nice. That's really cool.
---
I thought I'd mention: the designer itself seems to actually work in Wine (in that it didn't crash on me, and is in fact running in another virtual desktop right now), but I got an error message that the web server failed to bind. Happy to do further digging if you like.
Also, shift+scroll doesn't scroll horizontally in the designer. Something I've gotten used to from Chrome, thought I'd mention it.
---
I was also curious: have you ever considered pitching this for mobile UI development? With a pixel-perfect grid-based system like this (that does admittedly offer some very impressive snapping options) the only way would be to create mobile-specific forms - but such an approach could potentially work quite well. The only other thing I can think of would be (re)designing controls that play nice with primarily touch-based environments, and implementing views with slide animations and such. I don't think this would be a doomed idea, I'm guessing you've already thought about it.