Tim Young [Elevate Software] wrote:

> Matthew,
>
> << How is this different to "Node" which I hear is all the rage? Being compatible with a Node server would give you a wider facility methinks? >>
>
> 1) It's JavaScript, so you're back to multiple languages.  Or, are you proposing that we put in an external interface for Node.JS ?  If so, then that's a non-starter, for a lot of reasons, but primarily 2).
>
> 2) The Node.JS ecosystem would be a nightmare for Object Pascal developers to navigate.  It's dependency hell.
>
> 3) WASM is going to change the JS landscape significantly, and things like Node.JS are going to become less and less attractive as developers revert to using the languages that they wanted to use instead of JS in the first place.  This means that the primary reason for even using Node.JS in the first place (single source) will be made a moot point.

Ah, right, so this is running the "pascal" code on your server, not the emitted JavaScript. I'd always thought that would be the purpose of the non-visual project - for running outside of a browser.

In which case, hmm, I can see a case. What would be really nice is for people to put forward suggestions to you for the direction to take EWB, and then you to take votes on it. I realise you have two pulling forces on you - existing customers and their needs, and finding new markets. With limited time, I would like you to be working on things that fit most users, not a special few who need a server. There are plenty of other server tools out there - is it a good use of your time? If you can provide a highly scalable or very low cost solution, then yes, otherwise perhaps not (in my opinion of course, and I don't know your market well).

--

Matthew Jones

"Matthew Jones" wrote:

<< There are plenty of other server tools out there - is it a good use of your time? If you can provide a highly scalable or very low cost solution, then yes, otherwise perhaps not (in my opinion of course, and I don't know your market well). >>

Whilst this is true, that means developers must contniue to learn several technologies and apps instead of using this one very powerful EWB system. We have spent too much time doing that. If I don't need to get into Apache and Ngix and whatever else, and can know EWB is a full solotion - the real McCoy that gives me the features and speed I need all in one dimension of my learnings, then I shall only get better and better at OPascal/EWB and focus more on what I need to do - which is pump out apps and solutions, and that equates to more billable time.

A highly functional EWB WS shall clear so many clouds for its developers and even make it very enticing and an easy sell to get even younger developers on board with Pascal as a development language. IMO.

Matthew,

<< Ah, right, so this is running the "pascal" code on your server, not the emitted JavaScript. I'd always thought that would be the purpose of the non-visual project - for running outside of a browser. >>

Nah, EWB-emitted JS has always been targeted for the browser.  JS just lacks too many things to use it for back-end stuff, with the big missing item being RTTI and easy debugging facilities.

<< In which case, hmm, I can see a case. What would be really nice is for people to put forward suggestions to you for the direction to take EWB, and then you to take votes on it. I realise you have two pulling forces on you - existing customers and their needs, and finding new markets. With limited time, I would like you to be working on things that fit most users, not a special few who need a server. >>

That's just it - *most* customers coming to EWB struggle with the server side implementation.  It negates almost all of the productivity brought to the table by the EWB client applications, and is a giant support problem because we end up providing support for other open source software implementations like PHP, but without any ability to manage the amount of support that such implementations require.

<< There are plenty of other server tools out there - is it a good use of your time? If you can provide a highly scalable or very low cost solution, then yes, otherwise perhaps not (in my opinion of course, and I don't know your market well). >>

Our market has always been small-to-medium-sized ISVs that use Object Pascal.  And, no offense, but "highly-scalable" is a completely over-used moniker.  Most ISVs don't need to scale to thousands of concurrent connections for the kind of *web applications* that they are creating (not web sites).  They simply need to handle hundreds of concurrent connections, at most.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Our market has always been small-to-medium-sized ISVs that use Object Pascal.

Well, I have to say it serves that very well. Okay, you two have convinced me. Is it done yet? 8-)

--

Matthew Jones

Matthew,

<< Well, I have to say it serves that very well. Okay, you two have convinced me. Is it done yet? 8-) >>



I also forgot to mention - it is *really* easy to surface native code into the Object Pascal run-time that I've built.  For example, this is all it takes to register all of the native classes so that they act as first-class citizens in the run-time:

(native code)

procedure TEWBVisualDesignEnvironment.RegisterDesignerClasses;
begin
  with FApplication do
     begin
     RegisterExternalClass('Object',TObject);
     RegisterExternalClass('TElementAttribute',TEWBDesignAttribute);
     RegisterExternalClass('TBoundingAttribute',TEWBDesignBoundingAttribute);
     RegisterExternalClass('TAutoSize',TEWBDesignAutoSize);
     RegisterExternalClass('TMargins',TEWBDesignMargins);
     RegisterExternalClass('TBorderSide',TEWBDesignBorderSide);
     RegisterExternalClass('TCorner',TEWBDesignCorner);
     RegisterExternalClass('TBorder',TEWBDesignBorder);
     RegisterExternalClass('TConstraint',TEWBDesignConstraint);
     RegisterExternalClass('TConstraints',TEWBDesignConstraints);
     RegisterExternalClass('TCorners',TEWBDesignCorners);
     RegisterExternalClass('TFormat',TEWBDesignFormat);
     RegisterExternalClass('TFontStyle',TEWBDesignFontStyle);
     RegisterExternalClass('TFont',TEWBDesignFont);
     RegisterExternalClass('TLayout',TEWBDesignLayout);
     RegisterExternalClass('TPadding',TEWBDesignPadding);
     RegisterExternalClass('TGradientColorStop',TEWBDesignGradientColorStop);
     RegisterExternalClass('TGradientColorStops',TEWBDesignGradientColorStops);
     RegisterExternalClass('TGradient',TEWBDesignGradient);
     RegisterExternalClass('TBackgroundImage',TEWBDesignBackgroundImage);
     RegisterExternalClass('TFill',TEWBDesignFill);
     RegisterExternalClass('TBackground',TEWBDesignBackground);
     RegisterExternalClass('TShadow',TEWBDesignShadow);
     RegisterExternalClass('TInsetShadow',TEWBDesignInsetShadow);
     RegisterExternalClass('TOutsetShadow',TEWBDesignOutsetShadow);
     RegisterExternalClass('TAnimation',TEWBDesignAnimation);
     RegisterExternalClass('TLeftAnimation',TEWBDesignLeftAnimation);
     RegisterExternalClass('TTopAnimation',TEWBDesignTopAnimation);
     RegisterExternalClass('TWidthAnimation',TEWBDesignWidthAnimation);
     RegisterExternalClass('THeightAnimation',TEWBDesignHeightAnimation);
     RegisterExternalClass('TOpacityAnimation',TEWBDesignOpacityAnimation);
     RegisterExternalClass('TVisibleAnimation',TEWBDesignVisibleAnimation);
     RegisterExternalClass('TFontSizeAnimation',TEWBDesignFontSizeAnimation);
     RegisterExternalClass('TAnimations',TEWBDesignAnimations);
     RegisterExternalClass('TElements',TEWBDesignElements,True);
     RegisterExternalClass('TElementProperties',TEWBDesignElementProperties);
     RegisterExternalClass('TElement',TEWBVisualDesignElement,True);
     RegisterExternalClass('TDivElement',TEWBDivElement);
     RegisterExternalClass('TBodyElement',TEWBBodyElement);
     RegisterExternalClass('TLinkElement',TEWBLinkElement);
     RegisterExternalClass('TFormElement',TEWBFormElement);
     RegisterExternalClass('TInputElement',TEWBInputElement);
     RegisterExternalClass('THiddenInputElement',TEWBHiddenInputElement);
     RegisterExternalClass('TTextInputElement',TEWBTextInputElement);
     RegisterExternalClass('TPasswordInputElement',TEWBPasswordInputElement);
     RegisterExternalClass('TFileInputElement',TEWBFileInputElement);
     RegisterExternalClass('TTextAreaElement',TEWBTextAreaElement);
     RegisterExternalClass('TWebElement',TEWBWebElement);
     RegisterExternalClass('TImageElement',TEWBImageElement);
     RegisterExternalClass('TObjectElement',TEWBObjectElement);
     RegisterExternalClass('TFrameElement',TEWBFrameElement);
     RegisterExternalClass('TCanvasElement',TEWBCanvasElement);
     RegisterExternalClass('TMediaElement',TEWBMediaElement);
     RegisterExternalClass('TAudioElement',TEWBAudioElement);
     RegisterExternalClass('TVideoElement',TEWBVideoElement);
     RegisterExternalClass('TInterfaceManager',TEWBVisualDesigner);
     RegisterExternalClass(GLOBALS_CLASS_NAME,TEWBVisualDesignEnvironment,False,Self);
     end;
end;

This is why it's so attractive for us to do it this way.  There's very little effort involved, thanks to RTTI, and so the standard library for the run-time can be quite extensive.  The only downside is that, at least initially, it will be limited to what can be compiled directly into the EWB Web Server and shipped with it.  I'll still need to develop something for hooking in external native code in a performant way.

Tim Young
Elevate Software
www.elevatesoft.com