Live data from Hacker News

Delphi still exists and is actively developed

embarcadero.com

161–170 of 250 posts

Re: Delphi still exists and is actively developed

#161
post #144

We use Delphi at work. We've gotten a lot of pressure from customers to move to the web. However the lack of ways to design non-trivial UIs quickly does not make it seen feasible at the moment. Then there's the fact that Win32 is like bedrock in terms of stability. We've got forms that's been designed and coded over 15 years ago which still works just as fine as they did back then. We've got input-heavy UIs, the one…

We've got input-heavy UIs, the one I'm working on right now is a single window with >150 input fields including multiple child tables up to levels 3 deep with their own grids. I went through this transition in the late 2000’s, moving grid and form heavy delphi windows screens to webpages, using ExtJS, the only framework at the time which kind of sort of could do this. The process made me realise two things: 1. if you…

> in most cases information-dense UI like that is bad design and should be avoided.

We do auto-expand a lot of groups, ie for company name and address fields we might just show name and org. number until you enter the company name field, at which point we show with the full name and address set. Once you leave the group it collapses again.

Still, the information-dense UI is what our users like, as far as I can determine. They want to take one look at an order or invoice and get the info they need, not having to flip through several tabs or pages.

Part of this is also driven by gov't requirements. That is, users are officially responsible for the data they submit, so they must be able to see all the data they submit.

Re: Delphi still exists and is actively developed

#162

Earlier quoted context omitted.

I know nothing about Delphi, but I guarantee that I could take any UI you designed in a day in Delphi and get something equivalent on the web in the same amount of time. Sticking a bunch of inputs on a page (even with some nesting) isn't complex at all. I think you are doing your customers a great disservice by not learning about web development.

Can you guarantee it'll run on the same machine, with the same browser, in 5 years, with no changes? Win32 is bedrock, the web is quicksand. Look at "HTTPS everywhere" and "you don't need FTP any more", which did little in terms of actual security, but broke almost everything in some small way. The web doesn't value legacy. It's a petulant 22 year old, that thinks it knows everything, and does stuff deliberately agai…

The whole motto of the web is “don’t break the web”. Backwards compatibility is taken very seriously. If a new browser version breaks an old site it’s a bug.

Re: Delphi still exists and is actively developed

#163

Earlier quoted context omitted.

I know nothing about Delphi, but I guarantee that I could take any UI you designed in a day in Delphi and get something equivalent on the web in the same amount of time. Sticking a bunch of inputs on a page (even with some nesting) isn't complex at all. I think you are doing your customers a great disservice by not learning about web development.

> I think you are doing your customers a great disservice by not learning about web development. Sticking a bunch of inputs in a HTML page is indeed not complex, but it has to look decent (labels and corresponding inputs line up vertically etc) and be functional (ie with sensible tab order etc). To get a sense of what we've got in Delphi, here's a demo video[1] illustrating making a simple input box. This is a "entry…

CSS Grid Layout would be the modern way of doing that on the web. But even old school HTML tables could easily accomplish the UI in that video.

Re: Delphi still exists and is actively developed

#164

Earlier quoted context omitted.

Can you guarantee it'll run on the same machine, with the same browser, in 5 years, with no changes? Win32 is bedrock, the web is quicksand. Look at "HTTPS everywhere" and "you don't need FTP any more", which did little in terms of actual security, but broke almost everything in some small way. The web doesn't value legacy. It's a petulant 22 year old, that thinks it knows everything, and does stuff deliberately agai…

You are completely exaggerating the backwards-compatibility issues that web developers face. There are web applications I wrote 15 years ago that are still working today, in modern browsers, with zero changes. And I wasn't nearly experienced as I am today, and didn't even think about future-proofing anything. Is the web as stable as Win32? No, of course it's not. But a page with 150 inputs isn't anything that require…

I'm not sure backwards compatibility is necessarily the main issue - I agree web apps built 15 years ago are reasonably likely to still function today but user expectations have changed a lot and they will feel like apps that are anachronistic. Plus there are often issues with using older SSL protocols , certs signed by no-longer trusted root CAs, and of choose anything using Flash or ActiveX controls etc. is almost certainly now broken beyond repair. The other difference is that users expect web apps to keep working using a variety of browsers (that are constantly evolving) and the backend hosting side posts presents challenges in terms of keeping it running in the face of changing hosting providers, security and availability concerns, cost etc. etc. On that basis I'd agree a desktop app built now is far more likely to still be working as expected with zero maintenance in 15 years time than a web-based one.

Re: Delphi still exists and is actively developed

#165

I still have the feeling it's the most productive way to create beautiful native Windows desktop programs. Rapid application development is not an empty promise here. All my other endeavours with UI programming (Java/Swing, HTML/JS frontends, QT) felt way less productive. Maybe MS C# is the closest to Delphi nowadays.

AFAIK one of the main driving forces behind C# and .NET was the designer of Delphi that Microsoft managed to hire away.

Re: Delphi still exists and is actively developed

#166
post #140

Earlier quoted context omitted.

You mean how you open Delphi IDE, create a new project (default is Windows VCL, but you can also do cross-platform FireMonkey just as easy), then when the main form is presented in IDE how you drop components from the components palette? As in same way you do it in Visual Studio when doing a WPF and or/ Winforms project as well? Or as in any visual IDE for any programming language, because they all follow the same id…

I guess? I was interested in whether it had some unique feature/paradigm, or was it loved for some other reason.

It was loved because it actually worked well, and the language and runtime features of VCL meant that the code was much, much cleaner than let's say in C++

Re: Delphi still exists and is actively developed

#167
post #36

Earlier quoted context omitted.

I wonder if anyone here has experience with both Delphi and SwiftUI. I'd be curious to know which one is more comfortable.

Well there's a reason all the WYSIWYG UI editors died out. They are a quick way to whip up a passable UI, but usually turns out to be quite ugly under the hood, hard to reuse, and a pain to maintain. Delphi is really from a different age, simpler times, when the common paradigm was having the app directly connected to some sort of SQL database, which serves as a stable, static data source for the UI. Making glorified…

> They are a quick way to whip up a passable UI, but usually turns out to be quite ugly under the hood, hard to reuse, and a pain to maintain

That's not my memory at all - even web-based traditional ASP apps made it relatively easy to use WYSIWYG form editors that modified the code as needed. But expectations around how dynamic UIs are supposed to be have changed. SPAs in particular are not very amenable to auto-code generation, but supposedly some options do exist (retool? Haven't tried it though).

Re: Delphi still exists and is actively developed

#168

Earlier quoted context omitted.

> I think you are doing your customers a great disservice by not learning about web development. Sticking a bunch of inputs in a HTML page is indeed not complex, but it has to look decent (labels and corresponding inputs line up vertically etc) and be functional (ie with sensible tab order etc). To get a sense of what we've got in Delphi, here's a demo video[1] illustrating making a simple input box. This is a "entry…

CSS Grid Layout would be the modern way of doing that on the web. But even old school HTML tables could easily accomplish the UI in that video.

> CSS Grid Layout would be the modern way of doing that on the web.

How do you handle the transition at 2:04 where "Last Name" is moved from its own row to sharing a row with "First Name"? Keep in mind I might want to add a third element in that row afterwards.

IIRC with tables you'd have to modify the column spans of all the other rows which is way too much effort. How does it work with the CSS grid layout?

Re: Delphi still exists and is actively developed

#169

I remember one of the great things about delphi was that it statically linked everything into the single .exe making it totally self contained. A Windows GUI program could be a couple hundred KB, no other DLLs required. C/C++ could do the same but you were stuck with nasty raw win32 calls and a lower level language.

Also the compiler was lightening fast.

* lightning

Re: Delphi still exists and is actively developed

#170

We use Delphi at work. We've gotten a lot of pressure from customers to move to the web. However the lack of ways to design non-trivial UIs quickly does not make it seen feasible at the moment. Then there's the fact that Win32 is like bedrock in terms of stability. We've got forms that's been designed and coded over 15 years ago which still works just as fine as they did back then. We've got input-heavy UIs, the one…

What no one in the responses is talking about ...is speed of using the UI during day to day operations.

Web interfaces are extremely clunky to use when trying to do things via only-keyboard (which is the only way to have muscle-memory help you zip through forms) methods.

They are slow to update and in some cases, the Web browser's UI is fighting with you, such as offering to replace your input with the previous data you put in a form field of the same name, etc. In certain cases the tab method of navigation between fields gets broken or something else that interrupts the person's flow happens.

Having worked in a case where the ticketing system and related interfaces were half-Web and half-Java-application-on-Windows - even the Java application was better to use via the keyboard.

If you are paying people on a regular basis, whether hourly or per-shift, and the UI slows people down by 5% , what is the cost over the (perhaps) 3 years of that application's life?

Even 4 users at $50k/year each in the USA (with healthcare and other business expenses etc. that means a $20/hour full time job) means $10K/year (5% * 200K salaries) in extra expense.

Post reply on HN