I miss Delphi

> 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: 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.

> 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)

It's doing pretty well, and we're slowly but surely building up a decent customer base. Plus, we're a very small company, so we don't need much revenue.

> With signing up... really like the "Real name" vs "Displayed name" vs "User ID" distinction! Hm, idea: 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.

Yeah, try to ignore the web site issues for now. It's a little dated, and is about a decade old now. We're going to be "dog-fooding" the whole thing with Elevate Web Builder, once the web server is updated to include the Object Pascal run-time and the GZip/SSL support is added. It will make a good example that customers can use to build their own sites, etc. It will be a mix of back-end-generated pages with mini Elevate Web Builder apps for various sections that now use plain HTML forms. Having said that, we're going to move the logins on to HTTPS sooner than that.

> (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)

Yes, it's performing some machinations on the time to generate the code. Essentially the code/PNG is stored and then deleted after it has been used. Again, not our finest work, but we don't have too many people trying that hard to sign up on the web site with robots. :-)

> 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.

I've also wondered the same. Besides what you point out, my concern with React is that it might stress the GC too much, but that's based upon my limited understanding of how its diffing algorithm generates what it needs to update the DOM. In contrast, Elevate Web Builder only needs to track a simple change set per UI element and enforce one simple rule: no UI element will actually apply its DOM updates until all parent elements are no longer being updated. The initial application load results in only one pass of DOM updates because there is a BeginUpdate..EndUpdate block around the application "surface" (body element) during the application load. And, more importantly, elements are created once and stay created.

Elevate Web Builder 2.06 actually adds some more optimizations in this regard, including the concept of "local change blocks" whereby layout and measurement are delayed until the EndUpdate call (where UpdateCount=0) on a per-element basis without taking into account the parent update status. This provides a much-needed reduction in how many calls are necessary to compute the width/height of UI elements that are auto-sized. The measurement functionality touches the DOM (off-screen, but still part of the DOM), hence it's very slow. So, the general design is that local updates control when layout/measurement occurs (there's also a method to force this), and global updates (including parent update status) control when DOM updates are applied.

> 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's actually quite a nice language, although the Elevate Web Builder variant is a little more restricted than Delphi, due to some of the limitations of JS. We've written database engines, ODBC drivers, PHP extensions, web servers, general applications and libraries, and an IDE/compiler using it, so it's pretty versatile. More importantly, it has GUI options on the desktop, which is where a lot of languages fall down. It is often the case that "just use an embedded browser" is not a viable solution for a professional application, and then you're stuck using some tacked-on GUI toolkit that may or may not work particularly well with your language.

> Ah, the world of HTML4.999999999999

:-)

> 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.

It's probably just the binding to port 80, which is a bit naive, but can be changed pretty easily:

http://www.elevatesoft.com/supportfaq?action=view&category=e...

(if you want to follow up on this via email, you can contact us at support@elevatesoft.com)

> Also, shift+scroll doesn't scroll horizontally in the designer. Something I've gotten used to from Chrome, thought I'd mention it.

Thanks, I'll check that out and make sure that it's added.

> 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.

We also target mobile, fully support touch, and there are a lot of responsive flow options in the layout functionality, but yes, it's normally best to create separate mobile/desktop versions simply so that one can take advantage of the unique functionality on each platform. This isn't as bad as it sounds, however, because one can easily share units between projects, including database units that include database model functionality. There are also simple method calls for aggregate animation operations such as sliding:

http://www.elevatesoft.com/manual?action=viewmethod&id=ewb2&...