I've been watching the newsgroup postings of new EWB versions, have checked out a couple of demos, and browsed through the forums here.  We are a small shop using Delphi to create applications.  We have a relatively simple web front end to our application built in Asp.net by contractors.

We chose ASP.net because there wasn't a Delphi alternative at the time, but we keep it because of the availability of contractors.  One of the downsides is that we don't make changes to the site often, but when we do the prior contractor may not be available, so we have to look for a new one, going through the vetting process, and paying for the ramp up as they learn the application.

What are the reasons that justify the move to EWB - or even starting a new project altogether?  Has the product reached critical mass such that there are enough experts to satisfy contracting requirements?  I presume that as a Delphi developer, the maintenance of the project would be a bit easier than using Visual Studio, is that correct?

Thanks,

Bob M..

Bob,

Thanks for your interest in EWB.

<< What are the reasons that justify the move to EWB - or even starting a
new project altogether? >>

If you want to send me a private email with a link to the existing ASP.NET
application, I can at least go over it and make sure that EWB 2 will fit
your requirements, or at least where there may be issues.

<< Has the product reached critical mass such that there are enough experts
to satisfy contracting requirements? >>

We're still working on the critical mass part, but EWB 2 is a good step
forward and we're seeing a lot of interest.

<< I presume that as a Delphi developer, the maintenance of the project
would be a bit easier than using Visual Studio, is that correct? >>

That is a definite yes.  EWB's strong point is ease-of-use, and its ability
to re-use existing native Delphi code on the back-end.

Tim Young
Elevate Software
www.elevatesoft.com

On 6/25/2015 2:11 PM, Bob Murdoch wrote:
> What are the reasons that justify the move to EWB - or even starting a new project altogether?  Has the product reached critical mass such that there are enough experts to satisfy contracting requirements?  I presume that as a Delphi developer, the maintenance of the project would be a bit easier than using Visual Studio, is that correct?

Our reasons why we really like EWB :

- RAD and WYSIWYG designer part really works - you can be incredible
productive very quickly. In fact i was using it for prototyping the
other day and others were able to use the URL and interact with the UI
in real-time.

- If you have Delphi/Obj Pascal experience then learning curve is very
short. I personally find switching between delphi and EWB projects is
way easier for me than switching to some other language where i might
need more time to figure out how things worked again if it's been a
while (especially things like Objective-C but even pure javascript (when
its unfamiliar to me) can take a while to figure out what heck is going
on sometimes).

- I strongly believe long term code maintenance will be way easier. This
is partially since your EWB code will either similar to your Delphi code
or at least its logically similar things (forms, components, events,
etc). Also any delphi developer can take a look and get going quickly -
i showed my co-worker an EWB2 app and he was able to make sense of the
the UI and code right away.

I believe EWB2 is already quite powerful and continues to evolve but you
still need to make sure it does what you need so do a deeper dive with a
smaller but real app or such.

I would look at EWB as an opportunity to bring the web development back
in-house myself since you can use your already existing (delphi) dev
skillset.

Raul

Raul wrote:

>  I strongly believe long term code maintenance will be way easier.
> This is partially since your EWB code will either similar to your
> Delphi code or at least its logically similar things (forms,
> components, events, etc).

I very much agree. One of the nice things developing my web shop was
the ability to literally copy and paste my object definitions, and big
chunks of code, between the server and the client. I had nothing to
relearn in switching between the two. And I'll put in a good word for
the RemObjects SDK here too, in that the javascript interfaces made it
all just look like ordinary Delphi too when calling back to the server
and responding to the messages (See my earlier posts and web blog for
details).

I will also though respond to the "Why use EWB?" in a more direct way.
To me, Delphi is not going in a direction that works for me and my
business. Or indeed, my contract customer's businesses. I'll not go
into details - I'm not hear to talk down Delphi - but I realised that
the browser is where things are going long term. With Javascript code I
can target any desktop, browser, smartphone. But I watched some videos
like the Crockford Javascript Good parts video (
https://www.youtube.com/watch?v=hQVTIJBZook ) and realised that there
were a heck of a lot of pitfalls for me to worry about in learning
that. And listening to DotNetRocks and the Tablet Show podcasts where
they talked about the syntax checkers, and a team of 5 people had done
a quality check on their Javascript, and when they then ran a static
checker it found hundreds of errors that they'd missed. What hope do I
have? But with EWB I can write code that is 100% good Javascript. Of
course it can still have bugs, but the object-oriented code is high
level, understandable, and fully syntax checked before the browser gets
a sniff of it. I was amazed at how precise the display system is - all
pixel perfect and obvious to use. I literally just use it as a RAD
system and don't worry about the details. If something does go wrong,
you can use Chrome's debug tools to see where in the code things are,
and breakpoint it. It is familiar enough to the original that you can
work it out.

Anyway, since starting, I've done a load of projects with it, some
small, some big. My main business now depends on it for the web shop,
and I am starting to use it in my contracting too. (One of my projects
is basically a Delphi EXE, using the Chromium component, which then self
hosts a web site that the EWB code in the window calls to do stuff - I
aim to do most of my UI stuff this way in future...)

Anyway, have fun with it. It isn't perfect, but it is darned good.

--

Matthew Jones

I concur with your thoughts around where EMB is headed with Delphi.  I'm
building stuff with firemonkey and i'm thinking "this isnt any easier
than doing web development".  What ROI am i really getting from using
Firemonkey?  The VCL in a 2 tier setting with databound controls was
amazingly productive.  I don't really care what the purists have to say
about it.  It worked.  It was fast.  It was not difficult to maintain.
Livebindings suck and they decided to get rid of database bound controls
altogether which blows my mind.  Then you have the 3 tier requirement
and you arrive at the conclusion that you may as well just build
everything with web tech.

The only place web really does fall flat on its face is mobile.  Phones
more specifically.  The latest gen ipads can handle it.  Native is the
only game in town and delphi isn't even a consideration for me there.
They keep breaking things and  cant seem to keep up with XCode and SDK
changes.

I'm probably walking away from Delphi and pascal altogether other than
to maintain existing apps.  That's not slight at all to EWB which looks
like an excellent product.  ES6/7 and typescript have made javascript a
reasonable language and tool kits like Aurelia are actually *more*
productive than Firemonkey will ever be with a much better separation of
concerns and real working two way bindings.

Webassembly looks like the beginnings of a CLR for the web.  I could see
Tim doing some pretty neat things with this.

Michael Margerum wrote:

> The only place web really does fall flat on its face is mobile.
> Phones more specifically.  The latest gen ipads can handle it.
> Native is the only game in town and delphi isn't even a consideration
> for me there.

I don't agree, for most appliaction purposes. You can do a lot of good
stuff in Javascript using PhoneGap, or just the browser. I had an EWB
v1 app running quite acceptably on both Android and iPhone devices.
Sure, it wasn't all whizzy graphics, but it wasn't slow. For most
business class applications, it is a good solution. If you want to be
the next Instagram or something, then spend your money on native, but
for most businesses you want to hit all targets with as little effort
as possible, and EWB does that nicely.

--

Matthew Jones

> I don't agree, for most appliaction purposes. You can do a lot of good
> stuff in Javascript using PhoneGap, or just the browser. I had an EWB
> v1 app running quite acceptably on both Android and iPhone devices.
> Sure, it wasn't all whizzy graphics, but it wasn't slow. For most
> business class applications, it is a good solution. If you want to be
> the next Instagram or something, then spend your money on native, but
> for most businesses you want to hit all targets with as little effort
> as possible, and EWB does that nicely.
>

It's not just speed but that is an issue.

It's also being able to run offline ,large datasets, and  persistence.
 Your app can killed off any time in mobile and coverage/latency is a
huge issue.  Web works great when you have 300ms latency.  Key/value
stores are not a suitable replacement for something like core data.  I
also use background fetch to refresh data in the background.  I use
mapkit, core location, notifications.


Sure you can build plugins with phonegap but then you end up doing just
as much work as if you had just coded it natively.  I don't have an
android requirement so it might be worth doing if you have to target
both iOS and Android.

I'm well informed all of the options and have tried them all.  For
phones, web isn't there yet.

Michael Margerum wrote:

> It's also being able to run offline ,large datasets, and
> persistence.   Your app can killed off any time in mobile and
> coverage/latency is a huge issue.  Web works great when you have
> 300ms latency.  Key/value stores are not a suitable replacement for
> something like core data.  I also use background fetch to refresh
> data in the background.  I use mapkit, core location, notifications.

You can do a heck of a lot though - background operation is standard,
you have local storage to keep stuff (most operations don't need to go
to the web at all). Of course it isn't suitable for every operation,
but many applications for business purposes (and others actually)
aren't that demanding.

Obviously anyone should do their own evaluation, but EWB can satisfy a
lot of demands.

--

Matthew Jones

> Obviously anyone should do their own evaluation, but EWB can satisfy a
> lot of demands.
>

I agree.  EWB is a great product and gives Delphi coders a quick way to
ramp up to web stuff.  I wouldn't be here if I didn't think it had
potential for me :D

The new component model will also help a lot in filling in some of the
holes.

"Matthew Jones" wrote:


>With Javascript code I
>can target any desktop, browser, smartphone. But I watched some videos
>like the Crockford Javascript Good parts video (
>https://www.youtube.com/watch?v=hQVTIJBZook ) and realised that there
>were a heck of a lot of pitfalls for me to worry about in learning
>that. And listening to DotNetRocks and the Tablet Show podcasts where
>they talked about the syntax checkers, and a team of 5 people had done
>a quality check on their Javascript, and when they then ran a static
>checker it found hundreds of errors that they'd missed. What hope do I
>have? But with EWB I can write code that is 100% good Javascript.

But somebody somewhere is writing the translation from Delphi events to Javascript, right?  I assume this is ElevateSoft, but do you know how it is done?  100% is quite a claim, and I would love to believe it.


Bob M..