![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General Discussion » View Thread |
Messages 1 to 10 of 16 total |
![]() |
Thu, Jun 25 2015 2:11 PM | Permanent Link |
Bob Murdoch | 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.. |
Thu, Jun 25 2015 5:19 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Thu, Jun 25 2015 9:20 PM | Permanent Link |
Raul ![]() | 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 |
Fri, Jun 26 2015 10:04 AM | Permanent Link |
Matthew Jones | 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 |
Fri, Jun 26 2015 10:30 AM | Permanent Link |
Mike consultant | 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. |
Fri, Jun 26 2015 10:42 AM | Permanent Link |
Matthew Jones | 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 |
Fri, Jun 26 2015 11:01 AM | Permanent Link |
Mike consultant | > 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. |
Fri, Jun 26 2015 11:10 AM | Permanent Link |
Matthew Jones | 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 |
Fri, Jun 26 2015 11:16 AM | Permanent Link |
Mike consultant | > 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. |
Fri, Jun 26 2015 1:18 PM | Permanent Link |
Bob Murdoch | "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.. |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |