Earlier quoted context omitted.
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…
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…
Ah, the 10k character limit. Heheh. Thanks again for replying!
In HN's case, it's because Arc sorts all comments with the same score chronologically... so I upvoted your first post. :)
Incidentally, Reddit's PM system happens to produce the same results too. Unfortunately due to post weight fuzzing the only way to keep things in consistent order is to make a tree of replies, or clearly mark "i of n" etc. Anyway.
> 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.
(Very) small companies FTW.
> 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.
Nice! I see.
>> (Regarding the captcha system, (...))
> 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. :-)
Oooh, I see. That's a nice and simple approach! I must admit my own thinking with captchas was something along the lines of "probably needs to be a Rube Goldberg machine, preferably one built out of kitchen sinks - that should make it secure enough"... I must admit I didn't quite think through simpler approaches like this (probably due to all the captcha fails I've come across, although I can't relocate the one I was thinking of right now).
>> I wouldn't be surprised at all if yours won out (...)
> 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.
FWIW, imgur is nigh unusable on my old ThinkPad T43 (if not for the Imagus image preview extension I {c,w}ouldn't use it). So yeah.
> 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.
Oh that's what you mean by reference counted... yup, that's a far simpler approach.
> 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.
Nice :D
> And, more importantly, elements are created once and stay created.
I've noticed that modifying large chunks of HTML can cause rather large glitches, whereas isolating changes to the elements in question is ridiculously fast, yeah.
> Elevate Web Builder 2.06 actually adds some more optimizations in this regard (...)
That is really cool. I wish more application frameworks focused this much on efficiency :(
>> Also, Pascal doesn't actually look that bad. (...)
> 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.
I see (wow). So it _is_ a transpiler. Now I'm wondering if it'll ever have options to optimize for ES2015, or obsessing over JS generation (ref https://news.ycombinator.com/item?id=13762787), or even compiling directly to WebAssembly...
(FWIW, wasm's interpreter architecture and bytecode set are already locked in and both Firefox and Chrome already have (disabled by default) support - everyone's just tossing up how (hopefully not "if"!) to talk to the DOM.)
> 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.
Yep, and this gets you Pascal->HTML. Makes a lot of sense.
>> Ah, the world of HTML4.999999999999
> :-)
The day HTML interpreters reach parity will likely be the day we're all using something else :(
>> (...) the web server failed to bind.
> It's probably just the binding to port 80 (...)
OH, of course, you can't bind to ports https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
It's okay though, I just picked a different port.
And now I have a new problem: I'm seeing "Emitted C:\users\i336\My Documents\Elevate Web Builder 2\Projects\D:\project1.js (total size is 965998 bytes - not compressed)", which presumably isn't working. (Previous "is this what you wanted?"s included "C:\users\i336\My Documents\Elevate Web Builder 2\Projects\..\..\..\..\..\project1.js"!). I've emailed you in case you're interested :) (full disclosure: I'm just playing around with this, and I don't know any Delphi people, although EWB is of course filed away)
>> Also, shift+scroll doesn't scroll horizontally (...)
> Thanks, I'll check that out and make sure that it's added.
* 1024x768 sort-of-masterrace *
>> I was also curious: have you ever considered pitching this for mobile UI development? (...)
(PS. By "snapping options" I was trying to describe dynamic flow/resize, yep)
> 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. (...)
Oh okay! Nice. (Although not targeting mobile is kind of crazy, so it makes sense...)