These are backwards, I forgot that HN posts the latest comment first. :-)

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

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