Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 11 to 20 of 21 total |
Update on EWB 3.x - April 2019 |
Mon, Apr 29 2019 8:13 AM | Permanent Link |
Matthew Jones | Perhaps it could be in an Enterprise version then, with a few thousand dollars price to justify the work. 8-)
-- Matthew Jones |
Mon, Apr 29 2019 8:43 AM | Permanent Link |
ooptimum | "Matthew Jones" wrote:
<< Perhaps it could be in an Enterprise version then, with a few thousand dollars price to justify the work. 8-) >> I understand your irony. But being an experienced developer, I realize that sptlitting code apart is not actually a very difficult thing. It's not much harder than intersection and conjunction of sets. So, I just wouldn't buy it then. Especially since I don't focus just on Delphi-like solutions. We have to admit that these are niche products today. |
Mon, Apr 29 2019 11:36 AM | Permanent Link |
Matthew Jones | ooptimum wrote:
> But being an experienced developer, I realize that sptlitting code apart is not actually a very difficult thing. Presumably that experience tells you that writing the code to manage multiple projects at the same time and doing a large scale multiple compile and tree evaluation will not be so easy. Like I say, its a nice idea, but the cost in development time would be way higher than the benefits to most customers. -- Matthew Jones |
Mon, Apr 29 2019 12:28 PM | Permanent Link |
ooptimum | Matthew, I've already understood your position. But let Tim speak for himself. Maybe it won't seem so difficult for a person who independently develops DBMS systems with compilers and interpreters?
|
Mon, Apr 29 2019 4:10 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << In my opinion, EWB is a great product with great potential, but it still has some disadvantages. One of its downsides is the very large size of the resulting code. I have not found anything in your message that says that the new version will somehow change the situation.>>
The large size of the code is just the price for all of the functionality being emitted as JS code, and it isn't any worse/better than any other JS code. It's just how it is, and changing some basic constructs here and there won't put a dent in the size of the emitted code. The only thing that really works is identifier compression and dead code elimination, and the new compiler *does* to a little better job in that area, so we'll have to see how that improves the situation for your application(s). << I have a few ideas if you don't mind, how this can be compensated at least partially. >> Thanks for the input. I don't have time to go into all of this in any detail right now, but here are my notes: 1) Re: comparisons - the point of EWB's JS output is to be as compatible with Object Pascal as possible, so as to make it as easy as possible to port existing code (or as much as can be done). Also, I'm trying as hard as possible to mask the underlying implementation of any given feature in the language runtime, and this is necessary because sometimes you're running JS underneath, and other times you're not. This doesn't mean that such an intrinsic isn't possible, just that it won't necessarily be able to reflect JS semantics. 2) Yes, and IIF() function would be useful, for sure. My top priorities for the compiler are getting sets and interfaces completed first, but this type of intrinsic is fairly easy to implement in the compiler. I added an intrinsic procedure today, and it takes about 5 minutes for straightforward functions/procedures. 3) I understand how arrays work in JS, and I'm not sure why you keep assuming that I don't know fundamental things about JS...do you think that I've only ever used Object Pascal and that's it ? I gave an hour-long presentation in Buffalo, NY in February on multi-threading/multi-processing in Python - does that help convince you ? The reason why they work like in Delphi is because the code is *supposed* to be compatible with Delphi/Object Pascal code as much as possible. 4) Sorry, but you won't be able to access invalid array indexes in EWB's Object Pascal implementation, just like you cannot do in Delphi's Object Pascal implementation (at least not without the risk of an AV, depending upon the memory allocation underlying the array instance). 5) Code-splitting is definitely something that I have planned, as it's necessary for web sites that are a collection of EWB applications, as opposed to a single EWB application. The key here, though, is that you will have to "build" the entire site at one time in the IDE, so that EWB's JS compression still works correctly across all individual applications. As for other suggestions, please hold off until EWB 3 is out and you can try the new compiler/runtime, and then we'll discuss what can be done moving forward. Just keep in mind one thing: my primary goal with EWB's language is to *not* turn it into a "kitchen sink" language like C# or Java. Rather, I just want to make sure that there is a minimal viable set of language constructs that satisfy most needs (for example, interfaces for aspect-oriented development), and keep it at that. For example, EWB's new interpreter (and the old one) uses manual memory management, so closures are not really something that works well in such an environment without making it harder for the developer to reason about what the code is doing at any given time, especially with regard to memory management. Tim Young Elevate Software www.elevatesoft.com |
Mon, Apr 29 2019 4:13 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << The problem is that the code is not so small. All my initial message is dedicated to this fact. My unfinished mid-sized project generates code with the total size of 3 Mbytes already. >>
This is *with* compression turned on for the project in the compiler options ? Tim Young Elevate Software www.elevatesoft.com |
Thu, May 2 2019 8:54 PM | Permanent Link |
erickengelke | Congratulations on making so much progress on the EWB ecosystem and sharing your progress with us.
I'm looking forward to the beta or even an alpha at this time or any documentation you have. The sync keyword sounds like something I need for existing projects. Are there any performance improvements on existing objects. I ask because complicated massive EWB projects can sometimes be a bit sluggish parsing data and placing visual objects on the screen. Not that EWB is particularly slow, but any improvements will be a godsend. How compatible will EWB 3 be existing EWB projects, is it mostly backward compatible? Thanks. Erick EWB Programming Books and Component Library http://www.erickengelke.com |
Thu, May 2 2019 9:02 PM | Permanent Link |
erickengelke | Congratulations on making so much progress on the EWB ecosystem and sharing your progress with us.
I'm looking forward to the beta or even an alpha at this time or any documentation you have. The sync keyword sounds like something I need for existing projects. Are there any performance improvements on existing objects. I ask because complicated massive EWB projects can sometimes be a bit sluggish parsing data and placing visual objects on the screen. Not that EWB is particularly slow, but any improvements will be a godsend. How compatible will EWB 3 be existing EWB projects, is it mostly backward compatible? Thanks. Erick EWB Programming Books and Component Library http://www.erickengelke.com |
Mon, May 6 2019 12:36 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Erick,
<< The sync keyword sounds like something I need for existing projects. >> I didn't mention that keyword - are you referring to an older conversation ? << Are there any performance improvements on existing objects. I ask because complicated massive EWB projects can sometimes be a bit sluggish parsing data and placing visual objects on the screen. Not that EWB is particularly slow, but any improvements will be a godsend. >> Are you referring to in the IDE, or in the browser ? The browser JS is primarily a function of the JS engine used by the browser, and there's not much I can do in that respect. The EWB code is about as efficient as one can get in terms of delaying any DOM object updates, etc. during loading. << How compatible will EWB 3 be existing EWB projects, is it mostly backward compatible? >> Yes, it will be backward-compatible for the client applications and you shouldn't need to do anything other than deal with the changes on the server-side. Thanks. Erick EWB Programming Books and Component Library http://www.erickengelke.com Tim Young Elevate Software www.elevatesoft.com |
Mon, May 6 2019 11:30 PM | Permanent Link |
erickengelke | Tim Young [Elevate Software] wrote:
Erick, << The sync keyword sounds like something I need for existing projects. >> >I didn't mention that keyword - are you referring to an older conversation ? Perhaps. My apologies. << How compatible will EWB 3 be existing EWB projects, is it mostly backward compatible? >> >Yes, it will be backward-compatible for the client applications and you shouldn't need to do anything other >than deal with the changes on the server-side. Thanks. Looking forward to it. Erick EWB Programming Books and Component Library http://www.erickengelke.com |
« Previous Page | Page 2 of 3 | Next Page » |
Jump to Page: 1 2 3 |
This web page was last updated on Monday, April 29, 2024 at 05:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |