I posted a new blog update on EWB 3 here:

https://www.elevatesoft.com/blog?action=view&id=elevate_web_builder_3_progress_update_for_april_2019

Feel free to comment or ask any questions here or on the blog.

Thanks !

Tim Young
Elevate Software
www.elevatesoft.com

Hello Tim,

It's great that the product will be ready by mid-May. Although my subscription is likely to be over, I am happy for everyone who has been waiting for this new release.

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. I have a few ideas if you don't mind, how this can be compensated at least partially.

First of all, comparison that some variable is not equal to 0 or nil generates syntactically correct but long code like "if (yourvar != 0)" or "if (somevar != null)". In JavaScript, you don't have to do these equality checks all the time, because you may use any value in a Boolean context. All values are truthy unless they are defined as falsy (i.e., except for false, 0, "", null, undefined, and NaN). That's why you could implement this feature in the form of pseudo-functions (like writeln() in pascal), not breaking compatibility with Delphi, namely Truthy(): boolean and Falsy(): boolean, which could be translated directly into such code: "(somevar)" (or "(!!somevar)", if the output must be boolean) and "(!somevar)", respectively. Or let us use any variables in the boolean context, as in JavaScript, which will be incompatible with Delphi, but programmers will have to write less code, and compiler will emit less code too. Thus we will be able to write in the same way as before, i.e. "if somevar <> 0 then", while a shorter form: "if somevar then" will be available too.

Secondly, you can implement a similar pseudo-function iif(condition, if_true, if_false): variant, familiar to many programmers in other programming languages, which could be directly translated into a JavaScript ternary operator, ie in "condition ? if_true : if_false". It's actually a very useful feature, and it shortens code too. I wrote it myself and use it often, but I'd prefer to have inline version.

Third, I noticed that you continue to work with arrays, as you do in Delphi. For example, you change the size of an array before inserting a value at its end. But you don't have to do that in JavaScript. The fact is that in JavaScript arrays, unlike Delphi, are sparse, and in fact, they are almost ordinary objects, only with numbers as field names. That is if you execute such a code: "array[0] = 1; array[1000] = 1001", then there will be no allocation of 1001 cells in memory, but an object with only 2 fields will be created. So I'm a little worried about your phrase: "all array/string indexes are checked for validity", as any integer non-negative index is acceptable in JavaScript. I often use this feature. Let's imagine that I need to find an empty cell in an array and assign it some value. I do the following:

for i := 0 to Length(some_array) do
 if some_array[i] = nil then
   some_array[i] := value;

Note that I use Length(some_array) instead of Length(some_array)-1, because in JavaScript arrays, unlike Delphi, it is impossible to go beyond the array's bounds - it actually has no implied bounds. You are limited only by a JavaScript implementation in what can be a max index of an array. Thus, if the array does not contain empty cells, I simultaneously increase the array and assign the value to the new last cell of the array. I don't need to manually resize the array beforehand.

I would also like to be able to split the project into subprojects with both common and own code. For example, you make a site designed for 3 types of visitors, let it be a site of a recruiting agency. On this site can be as ordinary casual visitors, and employers and job seekers. They can have both common pages, which can see all, and pages available only to employers or only to applicants. Therefore, it makes no sense to upload additional code, unique only for some group of users, to visitors of another group. Now it is almost impossible without painstaking manual work.

I have a number of other considerations and suggestions, as well as a list of what I am missing from the language, in addition to the closures that we have already discussed. I will not write them here now, but I can write to you later if you are interested and would like to discuss them.

ooptimum wrote:

> ... because in JavaScript ... unlike Delphi...

There are some interesting ideas there, but one of the things I like about EWB is it is all type safe and pretty robust - if I made a mistake, I get to know about it. The "truthy" thing presumably means that it would accept a whole load of things other than '0' as a value, and I'm not sure that would be a good thing. It sort of comes down to what the language should be. I think that extending it to have things like the ternary operator make sense, but losing the Delphi side and making it practically Javascript would be a big change.


As for different projects and different selections, that can be done today, with some work as you say. Not sure that it will ever be possible with no work, but full conditional compilation would be the best step forward for this. I forget where that got to... But I did make multiple versions from a common code base in one project, so it can be done.

--

Matthew Jones

Hi Matthew,

"Matthew Jones" wrote:

<< "The "truthy" thing presumably means that it would accept a whole load of things other than '0' as a value, and I'm not sure that would be a good thing. It sort of comes down to what the language should be." >>

I think you probably forgot about the assigned() function which performs exactly the same thing as the proposed Truthy() function. Look at the code:

function assigned($0)
{
  return $0?true:false;
};

The only problem is that this is a regular function with overheads on its call. I'm proposing an inline version of it with a different name. You can use one wherever you can use the other, but without the overhead on calls. I'm ready to eat my hat if it's not a Delphi-sh way.


<< but losing the Delphi side and making it practically Javascript would be a big change. >>

Not losing compatibility, but expanding the language capabilities. Now it's far from covering all the useful features provided by JavaScript.

Anyway, even though I started with TP 5.0 and still use Delphi, I'm not afraid to lose any part of Delphi in this language. Just as the one who created Delphi wasn't afraid of doing so, when he created C# and TypeScript. We've already lost something, for instance, sets and records. Although I'm not afraid of that, I still don't call for anything to be lost. I encourage you to obtain something new, useful and modern.

<< As for different projects and different selections, that can be done today, with some work as you say. ... But I did make multiple versions from a common code base in one project, so it can be done. >>

No any doubt you can do it. I can do it too. But still there will be a common code in these different projects, for example, the runtime library code. I want this common code to be in a separate js file instead of being duplicated in all the projects.

ooptimum wrote:

> But still there will be a common code in these different projects, for example, the runtime library code. I want this common code to be in a separate js file instead of being duplicated in all the projects.

Ah, right, you mean the output code for the Browser. Tim's already shown that the "all in one" is actually better overall because it is optimised to only have that which you need. Nothing more, nothing less. So that common code then just ends up being half full of unused code. It would also end up being incompatible with something unless you built it as a whole. And it doesn't help anyone really does it? Each end user currently gets exactly what they need, no more no less. Additional common files would just add to your workload for no gain.

--

Matthew Jones

First, I'd like to add about Truthy(), and then I will get back to "all-in-one" concept.

I will try to explain it by an example where Truthy() can be very useful. Let's imagine that you get a JSON object 'obj' containing a 'msg' field that you want to assign to a label in your form. Your code will likely be as this:

if obj.msg <> '' then
 Label1.Caption := obj.msg;

You will get an exception if msg wasn't passed to you, i.e. if it's value is 'undefined'. You will get an exception a bit later if obj.msg = nil, as nil not equal to empty string (''), and runtime lib doesn't expect to receive nil there.

However, if you redo the code in this way:

if Truthy(obj.msg) then
 Label1.Caption := obj.msg;

the value will be assigned only if msg is defined (not 'undefined', nor nil) and it has a value different from an empty string. Isn't it simpler, shorter and neat overall?


"Matthew Jones" wrote:

<< Ah, right, you mean the output code for the Browser. >>

Yes. Sure I had to describe it clearer in the begining.

<<  Tim's already shown that the "all in one" is actually better overall because it is optimised to only have that which you need. Nothing more, nothing less. So that common code then just ends up being half full of unused code. It would also end up being incompatible with something unless you built it as a whole. >>

The compiler is lightning fast and will be even faster, as Tim promises. So there's no problem compiling all the projects together. All the more so if obfuscation and packing are to be used.

<< And it doesn't help anyone really does it? Each end user currently gets exactly what they need, no more no less. Additional common files would just add to your workload for no gain. >>

Less code = less time to load it + less bandwidth usage ("green" Internet), and there are still many places, where one should pay his traffic.

ooptimum wrote:

> if obj.msg <> '' then
>   Label1.Caption := obj.msg;
>
> You will get an exception if msg wasn't passed to you, i.e. if it's value is 'undefined'.

That might be what I want though. But sure, a Truthy function might be nice - presumably you can write that now as JavaScript.

We agree that a "mega project" option would be needed to make the separate files work. But I still don't see the benefit to anyone, only the cost to Tim. Instead of one 50k file you now have two trips to get a 40k and a 20k file. And you can't cache the common file. Now, you might argue that having a big one-off everything included file that the others reference might be worth it, as it doesn't change ever (like the big frameworks do), but then you lose the optimisation to remove the unused aspects so I have to have all the grid code even when I don't use it. And then the obfuscation can't work either, unless it generates the common file each time, and that just defeated the cache.

Like I say, I can't see what the end user benefit is. And I can see the additional complexity on the compiler/IDE side (remember command line compile needed too!) that is effort I think we'd rather all went to better editor facilities etc.

--

Matthew Jones

"Matthew Jones" wrote:

<< And you can't cache the common file. >>

But why is that? If an unauthenticated user logs on to the site, the common code is loaded and only then, when he or she is authenticated, will the code specific to his or her role be loaded. There is no need to load the common code again, as it should be cached by browser already.

<< Now, you might argue that having a big one-off everything included file that the others reference might be worth it, as it doesn't change ever (like the big frameworks do), but then you lose the optimisation to remove the unused aspects so >>

No, I won't. I'm not gonna forego optimization.

ooptimum wrote:

> << And you can't cache the common file. >>
>
> But why is that? If an unauthenticated user logs on to the site, the common code is loaded and only then, when he or she is authenticated, will the code specific to his or her role be loaded. There is no need to load the common code again, as it should be cached by browser already.

I mean that when you do a new build, the file needs to be downloaded again. Obviously from day to day when you are not developing it can be cached. But so can the smaller all-in-one file, which doesn't have dependencies on anything else.

--

Matthew Jones

"Matthew Jones" wrote:

<< I mean that when you do a new build, the file needs to be downloaded again. Obviously from day to day when you are not developing it can be cached. >>

Yes, this is the main point. You rebuild a project much less frequently than users download it.

<< But so can the smaller all-in-one file, which doesn't have dependencies on anything else. >>

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. I'm afraid to imagine what size it'll be when I finish it. Because I only did about a quarter of what I was planning.