4 ms·

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

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=ewb&question=local_web_server_conflict 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&comp=TControl&method=SlideTo http://www.elevatesoft.com/manual?action=viewmethod&id=ewb2&...

i336_ 10y ago
> These are backwards, I forgot that HN posts the latest comment first. :-) 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 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 <1024. Yup, that fixed it. One question though: I was playing with the stop/start server buttons and couldn't restart the server "because it was already listening". I suspect it might be a missing SO_REUSEADDR: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx 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...)

i336_ 10y ago

> These are backwards, I forgot that HN posts the latest comment first. :-) 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 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 <1024. Yup, that fixed it. One question though: I was playing with the stop/start server buttons and couldn't restart the server "because it was already listening". I suspect it might be a missing SO_REUSEADDR: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx 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...)