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 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. Getting the UI layout done and components connected to the DB will take me a day tops, it'll look great and based on history should work for the next 10+ years. The web seems like such a step back whenever I try it.
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.
On my new ThinkPad and the latest Delphi it compiles/links at 50-60K lines/second that performance has been consistent throughout the 25 years using Delphi. What it means in practice is you change a line of code, press F9 and the program is executing with no discernable delay.
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 try to map information-dense UI’s like that to the web, it will cost more to develop and the UX will be worse. (we saw double the dev cost and a slower and more cumbersome ui)
2. in most cases information-dense UI like that is bad design and should be avoided. I couldn’t see it back then how things could be done differently to make screens less dense, but looking back there were plenty of ways.
> 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.
“ >150 input fields including multiple child tables up to levels 3 deep with their own grids”
Yeah i’ve built single page apps with more input fields than this and grid tables all in a single view. Are you sure this cant be easily done?
Coincidentally that was first 15 years ago with extjs, second time with react 3 years ago - the latter being a slower process but still pretty much doable.
And I've seen Delphi apps; I recently worked on one. In my experience they don't look great. Maybe you've done a lot of work to theme the controls; if so, wonderful. But what I'm familiar with just brought up Windows dialogs, and ... well, that's functional but I wouldn't say it looks great.
But here are a few examples of ways you could create 150 fields in a day on a web app and have them look great:
Form should follow a database schema and automatically display database records? https://marmelab.com/react-admin/ (I used this approach to bring up an admin panel for more than 150 fields, though spread over a couple dozen pages, because of course that looks better than trying to bring up 150 fields on one page.)
The standard way to create a large form (or any data table on a page) today is to iterate over the fields you want and add them to a page. There are frameworks like Chakra that can help you make everything look attractive--and you can theme the result in whatever color scheme or styles you like.
I really don't want to have to touch Delphi ever again; it felt like I'd fallen back into the 1990s in code development terms, and I missed all of the modern features I'd grown accustomed to. If it's what you like, and it pays the bills, then enjoy. But know that people who have used more recent tools like myself consider it to be anachronistic.
Good to know. I use that; didn't know it was Delphi. It's...not terrible looking. It's all Windows controls, as I mentioned above, which makes it look, well, simple. And it's a utility that really doesn't need to look fancy, so it's fine for what it is. It doesn't seem to have a dark theme, which is a bummer, but otherwise it does the job.
> It's all Windows controls, as I mentioned above, which makes it look, well, simple.
Simple is beautiful.
> And it's a utility that really doesn't need to look fancy, so it's fine for what it is.
"Fancy" sucks.
> It doesn't seem to have a dark theme, which is a bummer, but otherwise it does the job.
"Dark theme" is moronic: Having your app use only standard Windows controls meant it automatically used whatever "theme" the user had set Windows-wide, so it always adapted to their preferences. No per-application "dark theme" or "purple theme" needed.
Until Microsoft themselves sabotaged all that, starting late in the lifespan of Windows 7. Assholes.
Err... Yeah, depending on what you mean by "field", the answer is yes. In one day it is possible to stick 150 fields in an HTML document and apply some CSS to make it look nice.
Including functionality? Like including making them do what they are supposed to do? From what I recall about Delphi from years ago there is massive difference in amount of boilerplate and wiring to make stuff work.
Delphi has almost none, while most tech I have seen on web has a lot of it.
Depends. Slow development frameworks such as react or vue may take a while. Vanilla js with something like axios should be straight forward. All you need is calls back and forth to your server to fetch and apply data. A trivial thing.
Edit: However, my challenge is on wether it can be done or not. Delphi is cool, and tbh any tool you are an expert in will let you do something quicker than a tool thats new for you. It will probably take me a while to achieve the same goal in delphi.
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 against the advice of those with more experience.
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 requires cutting-edge web technologies. It'll work just as well today as it'll work in 5 years.
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.
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.
Yes. In fact the entire javascript toolchain that HN is always bemoaning is there to make sure that an application runs on 15 year old browsers just fine.
Really, yes. Use plain html, no CSS, no JavaScript, CGI implemented in some boring language, and plain http without ssl on the intranet and require vpn to connect from the outside.
> 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 level" demo, but it's representative (though we don't use the runtime customization).
I'd really appreciate input on something which could allow us similar decent looking UI with similar effort on the web.
Like, note how "Last Name" lines up with "Product ID" below, even though they're in different groups. Things like that.
> 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?
>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.
This is pretty simple with CSS grid -- literally takes a couple of seconds. I am a fan of Delphi, and used it myself in the late 90s, but I think you just might just give it more credit due to familiarity.
There are benefits to a web-app these days, due to the onerous requirements and demands of different operating systems and platforms.
> I think you just might just give it more credit due to familiarity.
Fair enough. I've tried searching for these things but it's very hard to find good resources. So far I've not found a way to do this with similar ease, but from this thread it seems it might be possible after all.
Some concrete examples or resources would be much appreciated.
> There are benefits to a web-app these days
Sure, I definitely see the positive sides of a web application, especially for our smaller customers.
>Some concrete examples or resources would be much appreciated.
Ok. I am not sure of your current front-end experience level, so I will give pointers as if you are not experienced with CSS grid, forgive me if this is incorrect.
The key CSS items in this case would be:
display: grid;
... which will allow for CSS grid layout, and then for the particular item you discussed, the following two CSS values would do the trick.
grid-template-areas .... for the layout container itself in a pseudo-visual way, and grid-area for the items to be laid out.
Here[1] is a simple example, but if you are a visual-type person would get the idea across.
The demo at the top of the page is interactive and you can see how easy it is to move around items. Of course these items would already be styled themselves to maintain label positioning and alignment so simply moving the letters in the grid-template-areas value would be sufficient to completely change the layout.
This does not let you drag and drop as in your demo, but it is equally fast and gives instant visual feedback in the browser.
As a side note, I morn daily the continuing loss of desktop applications, which is where I cut my teeth in development. But the explosion of platforms and continued aggression from OS manufactures in the name of "safety" is basically forcing the hands of people to move to web apps. I agree that, in general, they are not as snappy or as light-weight as a well-designed desktop application (a "real" one, not an electron app), but if you know what you are doing you can get close and get all the benefits that do come with web apps.
And, from someone that has done both desktop and web app development, web apps can be laid out very quickly if you have experience. I almost can not think of a single-page (non-animated) application that I can't layout in a single day. This is especially true if you are using an existing UI framework or you have built-up one of your own over time. The time-consuming parts tend to be testing on multiple platforms/screen-sizes for compatibility (iOS being the worst) and the business logic.
Let me know if that is not the type of info you were looking for, and I will be happy to point you in a direction to get the info you are looking for.
Will definitely take another stab using this. I'm assuming the grids compose, so I can work on one group (say name-address set) and it'll be well behaved when added into a larger layout grid.
The WYSIWYG drag and drop is nice, but if the results are predictable enough a manual "edit-and-run" cycle should suffice.
> Of course these items would already be styled themselves to maintain label positioning and alignment
So I guess this is the only thing I'd still be struggling with. Concretely, consider a grid layout like this:
a b
c c
d e
Here each cell has a label and a text input. Here the labels and inputs in a and d, as well as b and e, should automatically line up vertically, including if say b's label changes due to a dynamic event.
I'll have to see if it's easier with the grid layout.
>I'm assuming the grids compose, so I can work on one group (say name-address set) and it'll be well behaved when added into a larger layout grid.
Yes. That will work as expected.
>Here the labels and inputs in a and d, as well as b and e, should automatically line up vertically, including if say b's label changes due to a dynamic event.
This is where not rolling your own UI elements are faster. They will have been tested and any serious problems would have been addressed. But, even if you do roll your own, you can expect to be able to line up labels and fields both vertically and horizontally, even if the labels dynamically change (although watch for line wrapping if that is a possibility).
But, generally, your idea would work. I typically use flexbox unless I have a reason to use grid. For example if the entire flow of a page design changes between desktop and mobile, I normally use grid or if I need things consistently centered both vertically and horizontally, I use grid.
For laying out form UI elements, there are tons of examples that you can easily find online to fit the look and feel you are looking for.
If you have not settled on a stack yet, Svelte and Solid will offer the snappiness you are used to with desktop apps (due to no duplicate/virtual DOM). The drawback being that plugin elements are more readily available for more popular frameworks like React, however imho the plugins for Svelte or Solid tend to be better written.
With CSS grid you can define row & column template, and assign names to them. Then name your fieldset to be placed in there. Search CSS Tricks Grid, if you want to know more
If you pay me £30000 and give me 3 months, and work with me to determine how your current designs look like, and what your current workflow is, I can make a react based environment for you to do your designs in just as quickly. If you pay me £60000, I do it in 2 months.
It did until roughly 5 years ago. From what i found by googling the product was acquired by a larger competitor and then decommissioned in favour of an existing product. The benefit in web based uis is that they work on any platform a supporting browser can be installed. And if you understand js it can work for a very very long time.
There are indeed plenty of ways of designing non-trivial UIs on the web, but I am not sure any of them are that great, especially when you involve state. And there has been a mountain of pre-work done to make web UIs appear uniform across devices and browsers, and even with that pre-work done you still have issues on various mobile and tablet devices.
I'm kind of curious now.
Delphi claims you can "Build Native Apps 5x Faster With One Codebase
For Windows, Android, iOS, macOS, and Linux" the biggest corollary I can think of there is Election, and we all know how we feel about Electron apps here.
It's mostly taken care of by the framework, though we have some breathing space due to our customers not jumping on HiDPI. It took some years for most of the kinks to be ironed out in the framework from what I gathered.
We've yet to receive a HiDPI bug report, but we do get reports when we forget some customers still run 800x600 screens...
...for the enterprise. Which is okay, there's plenty of mixed quality software for that sector. It's just that Delphi used to be a lot more oriented towards beginner to small-business developers.
And note that this happened before the web pillow-smothered decent desktop UIs. If it was all about a reduced audience for desktop-based applications and then supporting that, I would understand it more.
I haven't been following Delphi itself, but the parent company also manages ExtJS, which is aimed/priced similarly, yet with support/quality that doesn't justify this.
Weird that outside of the BCPL or ML families, it's Ada that seems to be the one with the most momentum these days.
Application development has gone backwards so much compared to the RAD tooling from the 90s. I really can't even properly describe it to the younger generation. :(
ah the GUI designers from Borland, light years ahead of everything else... it just worked and looked nice (compared to Microsoft shitshow that was Visual Studio back then), was very easy to learn and its the only thing in software I've seen in 20 years which deserved the title RAD.
Delphi cut the corners with their fixed positioning. It will not work for web and it works very poorly for localization (labels change their lengths and can overlap over each other).
As soon as you introduce layouts to your UI, all the Delphi simplicity goes out of the window.
This is an interesting challenge to invent a way for UI to be pixel-fixed, yet work in web and with localization. If someone would do that, you could rebuild Delphi for web.
I guess one way is to build a pixel-fixed form for English language and let AI to build a layout for this form.
We had things like expandable container groups for UI controls that could auto-resize the child controls as necessary to fit their content back in the 90s.
Granted, it wasn't as easy to set up properly vs modern web layout engines - but there is so much more to RAD applications than the UI layout by itself.
So? Many apps don’t need localisation. Responsive UIs weren’t all that important in the mid 1990s when monitors and their resolutions were all in a relatively small corridor. I remember 20 inch CRTs to be the absolute high-end that few could afford. Most PCs came with 14 or 15 inch monitors, 17 inch later.
Totally agreed. I have done both a lot of work with the Borland tools and over the years with various web based libraries and languages, Borland wins hands down, in spite of the underlying horrible mess.
This. How easy was it to put together a well-functioning Windows desktop app in Delphi, compared with the complexity of developing a Web app these days?
I love using these RAD tools but I think part of what we're forgetting is how much lower the standards were (both visual and functional) for UIs back then. Sure you could throw together a professional UI in a lot less time, but part of that was that the definition of "professional" was "looks exactly the same as every other Windows application and uses the same 5 form elements". We've just come to expect more variety so the RAD approach doesn't take you as far these days.
> I love using these RAD tools but I think part of what we're forgetting is how much lower the standards were (both visual and functional) for UIs back then.
They weren't lower then, they're lower now.
> Sure you could throw together a professional UI in a lot less time, but part of that was that the definition of "professional" was "looks exactly the same as every other Windows application and uses the same 5 form elements".
Yup. That's still the correct definition.
> We've just come to expect more variety so the RAD approach doesn't take you as far these days.
Yes, unfortunately users have been conditioned to expect myriad variations of something like Kai's Fucking "Power Tools". And most of them have even been deluded into thinking of that as a good thing. They're wrong.
I think they really screwed up after Delphi 7, when they did the horrible Delphi.NET.
Also, they should have had some better pricing, something like:
Personal use: Free.
Commercial use: Free until you are making $x a year, like Unity I think, and then different prices.
Note: I might remember wrong, as this was so long ago. I started with Delphi 1.0!
I think their original pricing scheme for the first 5 or 6 versions of Delphi was fine. The cheapest version was just $100, which even a student could buy by saving for a few weeks (get them hooked while young, etc :-P). The versions that added features focused on enterprises were more expensive but these wouldn't be needed by a lot of people (a lot of Delphi programmers were making small shareware utilities instead of big database applications).
I have a "Delphi for Kids" book which included a free version of the lowest Delphi tier. And yes, sure, I guess you can do the same with the current community version, but it does show how broadly Delphi was aimed and received.
Which is the sad thing. Even if Idera were to change their tack, it wouldn't matter anymore, as there's no broad appeal for a "desktop full stack" solution anymore.
Right now, it doesn't matter anyway. They're in that enterprise tier along with commercial Smalltalks and APLs, even if they'd give away everything for free tomorrow it wouldn't change the world of computing.
After a while they got greedy and fucked up that scheme, moving stuff that had been in the Professional edition (most importantly, client-server DB connections) into Enterprise, and other stuff (three-tier app development) from Enterprise into a new Architect edition. And then steady substantial price hikes for all editions from version to version. Shot themselves in the foot, AFAICS.
Delphi IDE is available for Windows only, regardless of its version. I suspect @runjake meant is that the free version only targets Windows, while the architect edition of Delphi can target all of the major OS'es out there.
The free Community Edition supports targeting Windows, Android, iOS and macOS.
From a feature point of view, it is similar to what you get with the unrestricted Professional version.
Enterprise and Architect also has the Linux compiler.
On Windows you can use the tried and battle tested VCL framework, and for multi platform there's FireMonkey.
The IDE's are, however only runs on Windows (Or Wine if you're brave, YMMV).
One of the best aspects of Delphi is how quickly you can whip together simple GUI applications.
The main issue nowadays is finding helpful resources on the internet, as hardly anybody writes Delphi anymore.
Actually I do. Whenever I need a small tool like a calculator for a video game or a simple GUI program for processing images, I always go for a barebones single html file web application.
That way doesn't scale well. Things become very messy and unmaintainable really quickly. This is how people code in the past, and there are good reasons why people moved on.
Code becomes unmaintainable when it was organized poorly and grows or if discipline was not maintained during growth.
React projects are just as susceptible to that, and "modern" web development is quite frankly a larger maintainability headache due to the dependency hell they bring.
Just one more quick tip, you should probably use the unary operator "+" to convert strings to float. `parseFloat('2,000')` gives 2, which is probably not expected, while `+'2,000'` gives NaN indicating the input format is not recognized.
The linked Lazarus. Here is a quick screencast making a window with two fields and a button that sums them (though i forgot the "return sum" caption :-P) in ~45 seconds:
> Something that lets me draw a window with two number fields and a button that says "return sum", but it's two minutes of work and self-explanatory.
Tcl/Tk would be the most straightforward choice. Even easier than Lazarus. It's not really a native look, but practically nothing is truly native these days.
Same here. I've tried to pick up WPF but holy fatcats, what an explosion of XAML files in exchange for... pretty much nothing, really. It's a shame, really.
Delphi's FireMonkey is in many ways similar to WPF in the way you can manipulate UI elements, except all the fluff and cruft WPF/XAML has. On the plus side, FireMonkey is multi platform too.
VCL is still the tried and tested UI framework for Windows only applications though, nothing beats its flexibility.
I would almost like XAML, if it wasn’t for styling. If it had some CSS like DSL, I’d use it more, but unfortunately overcrowding styles invokes nasty blobs of XML boilerplate often having to override stuff that doesn’t seem relevant to what you want to do.
Same feeling about WPF. XAML just never caught on with me and I stayed with Forms for a long while after WPF came out. With XAML, it seemed like they were trying a bit too hard on declarative.
Now working in SwiftUI, which is declarative but in a more understandable way, with a View building mechanism behind it that ties things together so that you understand what you're doing a bit better. Not sure I'm explaining that well...
Not good enough at it yet to build anything fast, but I could see that being the case after a few more months with it.
But in that case, why even use WPF if I can just keep using WinForms? Besides, judging by the news and announcements on the Microsoft site, it would seem that WinForms is still being sort of developed while WPF is... pretty much dead.
You can easily adopt WPF features later, compared to migrate WinForms to WPF. I think both WinForms and WPF are being sort of developed, but WinForms is old so it have more developing needed area, like accessibility and HiDPI.
For something trivial and cross platform: Tcl with Tk or Python with wxpython.
Java with Swing does still exist and works too.
It's harder (IMO) to "scale" a Tcl/Tk or wxpython project though as there aren't great built-in patterns and especially with wxpython, the API is a bit clunk and boilerplate heavy.
For a bigger project that you don't need to be cross-platform, you can still make a Windows Forms C# project in Visual Studio. It still works pretty well even, although Visual Studio seems to get slower and farther from this use case each year.
Folks mentioned a few good options already, but another one is using C# and visual studio's built in form designer. It's very easy to get started with if you've seen a similar language before (e.g. Java).
I used Delphi years and years ago and it was great for building GUI applications quickly and easily. Much nicer than Visual Basic. I probably wouldn't recognize it now, other than I suppose it's still Object Pascal, which is a very good programming language, all things considered; straightforward, not too fancy, not too dumbed down.
Be warned: You need to enter a valid phone number. They will call you asking on what you plan on building with the software. I've had that happen to me within a few days of downloading the software.
I use Google Voice for that. I don’t have it tied to my phone, so the only thing they can do is send me text messages that I only see when I’m expecting something.
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.
You can still mix C++Builder and Delphi today. Embarcadero made huge efforts to make sure their Clang powered compilers has interop with Delphi code and vice versa.
C++Builder still share the VCL and FireMonkey frameworks with Delphi.
Over the years the minimum size of VCL apps increased. Last I checked (10 years ago maybe) it was like 1MB or more compared to 200KB or so in Delphi 3.
Almost certainly is the extended RTTI information - VCL is huge after all and relies heavily on RTTI. The forms, objects, etc you are editing in the form designer are not just stand-ins like in, e.g. Glade, wxFormBuilder, QtDesigner or similar tools, they are live instances of the actual objects that are serialized on disk whenever you save the project with the serialized data becoming part of the program's resources and are deserialized when the program starts (VCL/Delphi calls this "object streaming"). This means that the full RTTI information needed to serialize and deserialize the objects (and any other object) needs to be part of the executable.
At some point they extended the RTTI information so that you can also make dynamic calls to methods, obtain fields, etc so the RTTI data became larger.
Lazarus adds a ton more data to the executables so where you'd get a 1MB in some recent Delphi, you'd probably get something like a 5MB executable with Lazarus (without debugging information - that'd make it much larger) on Windows. On Linux it can be even larger, e.g. the simple calculator shown here[0] (up left window) is ~2.88MB, stripped.
Pretty much all of these programs (Glade, wxFormBuilder, etc) have a similar approach, the point is that the way Delphi (and Lazarus) works is with you working directly with the live instances of the objects that will be serialized on disk - there is a 1:1 mapping between all those and the information is extracted directly from the objects themselves.
In a way Delphi is kinda similar to how Unreal Engine works whereas Glade is kinda similar to how the original Quake engine worked.
Delphi Win32 executables I compiled last century still work fine. I hope the programs I am writing today will still work on whatever version of Windows is around in 25 years. Microsoft for all its many faults has not yet screwed up the Win32 sub-system.
My main problem with delphi: it is "too proprietary". It was a very productive ide in the 90's or early 2000's but lost their path and never recovered.
Some new versions broke compatibility with previous version's components. There was the case where you paid a good amount of money on some proprietary components and they simply wouldn't work in the next version: you were imprisoned in an obsolete ide. By not being multi-platform (I hear it improved it lately) you could only use it with/for win32 so it lost servers, embedded and mobile. By not being open-source nobody could improve it.
Then it had to compete with "native tools". Whoever develops for windows wouldn't quit ms' tools to use it, whoever develops for mac wouldn't quit apple's tools to use it, whoever develops for android wouldn't quit google's tools to use it, whoever develops for linux was mostly ignored after kylix.
Note that I didn't even mentioned price and license.
They improved it later, I heard. But seems more like the old case of too little too late. Most successful programming languages today are open source and multi-platform. Delphi was dependent on win32 for too long and it still is "too proprietary". You do the world a favor by porting your project to lazarus.
They should break off and commercialize just the cross-platform GUI and rapid development IDE for that and put a language like Go under it. Go with a good RAD IDE would be so amazing, like yank out my wallet and throw money at you while shaking amazing.
Give me a good cross platform GUI. Give me a good IDE for it. Don't make me learn yet another fucking programming language that exists nowhere else to use it.
The last part counts against this and also against Flutter, which forces you to learn Dart which is used nowhere but Flutter. What would have been wrong with Go or TypeScript? People already know those.
Most successful languages are open source for very clear reasons, but a cross platform IDE is something that could very well justify being commercial. It's an absolute ton of work and a constant moving target to support. So far no pure open source effort has managed to succeed unless you count the various HTML-based GUI systems that are indirectly subsidized by Google and Apple.
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.
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 database editors is what it was really good at.
These days.. things changed. UIs need to be flexible, reactive, reusable, adaptable. UIs that can handle uncertain states, asynchronous data flows, change dynamically and so on. SwiftUI / React / Flutter all ended up at the same paradigm, it's a much more advanced way of doing things. Also, high level languages are much more pleasant to work with.
Delphi still delivers unmatched productivity when it comes to designing UIs and writing maintainable multi platform software.
Delphi's FireMonkey framework has a lot of things right and you can create resusable forms easily, where you don't have to fight with a declarative UI (This paradigm is an anti-pattern and totally misplaced for UIs).
There are many multi platforms apps made with Delphi which are by no means "a glorified database editor" ;)
> 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).
For me when Borland became Embarcadero, it seemed like it lost it’s scrappy hacker ethos.
Turbo Pascal, Turbo C, Delphi, C++ Builder were all very innovative products that catered to the individual developer. The Embarcadero rebrand seems like a turn towards Enterprise.
For me now, JetBrains is the new Borland, a scrappy company with a strong focus on what individual developers need and consistently turning out excellent software.
Even though I own the latest Delphi Compiler it still seems 2 steps forward and 2 steps back each release, yes it gets better but they always seem to screw some little thing up which you need to work around (high DPI Issues, tcategorypanelgroup and IDE not repainting properly etc since my update from 10.3 to 11.1) 90% of their market is Win32 so I really dont understand why they concentrate 90% their development outside of this.
Embarcadero was acquired by the same jackasses that bought out a company where I used to work. The new owners had a bunch of attitude and kept crowing on about "their playbook". It turned out that the primary technology that they were buying us for was the one part of our product that we actually licensed from another vendor. I believe they spent millions and didn't get what they were looking for.
They had an offshore team that theoretically could work with the codebase, but I don't remember seeing anything of consequence added to the product in the past 7-8 years. If I ever found that they bought out a company that used technology that I depended upon, I'd migrate to a new solution.
Yeah, if you want something like Delphi, try Lazarus instead which -for the most part- is basically an open source and cross platform Delphi clone[0], so you're not bound to the whims of a corporation that is often seen as where old proprietary software goes to die.
Since Embarcacero was acquired in 2015 and until now, there has happened quite a bit to the RAD Studio IDE and underlying tech.
I don't know about your situation, but, Delphi and C++Builder has not been left to rot.
I miss Delphi.... even though I've got it installed.
I can't bring myself to use it.
The "free" version has a hook in it that just doesn't sit well with me... they want a cut of any money I make with it, on their terms. It's easier for me to ignore it, and just put up with the limited documentation of Lazarus. I miss the days when I could afford Delphi.
All my future developments will be in Lazarus but I have one mega-client with a big Delphi production program I have to keep happy for the foreseeable future or until their large team of developers and advisors can decide which language/platform/infrastructure etc they want to redevelop it in.
3+ years of consultants and meetings but not one line of code so far :-)
In the old days I loved them. Then I found myself using older versions despite having newer ones because of important bugs.
Then came 64 bit code. They were years late in releasing a compiler that could produce 64 bit code and the reaction from the company seemed to be that it's a tiny portion of the users that need it.
Never mind that for that not-so-tiny portion (you might have no direct need of 64 bit address space but if you have to play nice with 64 bit code you have to be 64 bit--plugins) it was a total showstopper, companies relying on it were dead in the water, had to to a total rewrite or die.
I got the strong feeling that they were looking at us customers as a resource to be milked, not supported. My employer at the time died in the housing collapse, while I still have a couple of little Delphi apps around that I wrote I haven't touched it since then. C# was almost as good (and at this point all that's missing are arrays with an enum index and arrays that don't start at zero) and has much better support.
I still have a warm spot in my heart for Delphi. When I bought a license for Delphi 1.0 running on Windows 3.1, it was like a revelation to me. Having previously used Borland Pascal on DOS, I found it unbelievable how easy developing Windows UIs can be. I developed a 16-bit business app (accounting, inventory management, customer records) on Delphi 1.0 which is still running today (you need a 32 bit version of Windows 7 though). The bundled Borland Database Engine (Paradox desktop) was decent enough for structured data management in a single-user application. The best feature was the compiler that sprinted through my source code, turning it into a statically linked executable in mere seconds (on a Pentium 60).
While I have long moved on from Pascal, many great ideas of Delphi live on in C# and Typescript.
If you want Delphi to succeed you have to win the developers.
The Embarcadero website experience for a developer is nonsense. The first thing you see in the page is "BUY NOW", "FREE TRIAL". It's so aggressive that my instant reaction is to close the product page before I even get to see what the product is about.
And no, I don't want a "product demo". I don't want to contact sales. I am a developer I don't care about that. "Contact sales"/"Request a product demo" sounds intimidating. It sounds like you want me to spend $5000, which I am not willing to spend.
My primary objective as a developer is to develop applications. The website has to focus on assisting that process.
I have fond memories of using Borland's Delphi when I was a much younger boy. GUI building tools such as Delphi, VS, JavaFX and the old Dreamweaver really helped certain concepts click for me at that age.
I used Borland Delphi (as well as C++ Builder for some period) throughout my university times for all kinds of home works and hobby apps. It was extremely easy to build simple but still good-looking UIs. At some point I even had a small reusable library for graph problems (add/edit nodes/edges with nice arrows/labels etc.) What I really liked was how fast you could get to real coding part with minimum boilerplate. Happy to see Lazarus IDE still having a strong community.
Denmark's farming industry's ERP system run on a system called Ø90 which is written delphi, java and cobol. Still being actively maintained by IBM today.
I knew a pharmacist who wrote his own POS software in Delphi. It (and Visual Basic) had that position where they were so usable that even someone whose fulltime job was something else would be able to single handedly make a line of business app for that business.
it is amazing that you could just drop edit boxes and labels, hook up to data source and database and it will work without a single line of code written!
Not necessarily. I think Delphi with visual programming is ok for students. High school kids like immediate visual feedback and ease of use. Probably deal does not involve money.
...On the part of the Turkish Ministry of Education, which figured out that they'd get legions of young programmers all primed to jump ship to Free Pascal / Lazarus?
Most Delphi examples I see these days are actually modern, recently written malware samples. It statically compiles into a tiny binary which has a weird ABI which flies under the radar of AV software looking for programs up to no good. What's not to love for this purpose if you are an adversarial actor?
The vega/buran strain of ransomware malware comes to mind as a well known example from the past few years [1]
> Most Delphi examples I see these days are actually modern, recently written malware samples. It statically compiles into a tiny binary which has a weird ABI which flies under the radar of AV software looking for programs up to no good. What's not to love for this purpose if you are an adversarial actor?
And recently lots of malware detection has started looking for that "weird" ABI signature, so now everyone's anti-virus is throwing up alarms at perfectly legit age-old software just because it's built with Delphi.
At least in the ex-soviet countries, a lot of the legally-questionable software we used to write was in Pascal because that's what we learnt in school. It was an easy transition to go to Delphi - nice RAD IDE for GUI RATs or keygens/cracks, familiar OO language.
Mostly because it builds self-contained executables that are virtually guaranteed to work. Nowadays this is much less of a thing, but we are talking about the day and age of DLL Hell.
Calling RAD Studio a high-quality IDE seems like a stretch to me. I would choose VS Code or a JetBrains product any day of the week. Unfortunately you a kinda stuck with it when developing in Delphi.
I remember being a little impressed when in some version of C++ Builder i used a symbol from another source file and when i pressed Ctrl+S to save it, the editor automatically added the necessary #include file at the top. This is the mark of an IDE that actually knows the language it is editing.
The closest i've seen elsewhere is QtCreator littering the code with red error messages about the unknown symbol while i'm typing the code together with a lightbulb next to the line with it which, if i click on, it adds the #include.
From a technical perspective the ability seems to be there, it just doesn't feel as smooth and seamless. Not to mention all these errors that appear while i'm typing make me anxious - like, STFU, i know the code is wrong, i'll fix it once i finish typing this part :-P.
I worked for about ten years on a suite of tools written, in large part, in Delphi. As far as I know, those tools are still being maintained in Delphi today.
It was a tiny software group in a large company, and paying Embarcadero whatever they wanted was just a matter of filling out paperwork. I imagine a lot of their current paying customers are in a similar situations.
Agree. If someone is paying you a shit-tonne of money to write a program then get Delphi Professional for US$1400, its still a good product, the more expensive $5K client/server/architect versions are not worth it at any price as third party delphi libraries for database and reports are cheaper and far superior (devart/fastreports/etc)
You can do the same with Lazarus without any external libraries. I wrote a fairly polished production system for a seafood factory in Lazarus 15 years ago which is still in daily use.
Amazing what a single developer with the right tool can achieve, shame we cant get any young people interested in anything but apps.
It is basically open source and cross platform Delphi (there are a bunch of differences but from a high level perspective i think that it describes it fine for people who already know Delphi).
Also check this video i made a few years ago[0] making a simple puzzle game in Lazarus. You can skip to 11:30 if you don't care about downloading, compiling and configuring it and just want to see it in action.
I'm working with the Delphi libraries every day in C++ Builder, bucause my company bet on Turbo C++ and Builder in the 90s, when Microsoft technologies seemed primitive compared to it.
At a recent meetup in my country, 90% of Delphi developers were over 60 years old. Also, Embarcadero licenses aren't cheap.
We also started with Borland C++ 3.1 in the 90s. The GUI IDE was mind-blowing at the time. It was superior to MS' Workbench. However, Borland really dropped the ball with C++ 4.5, and we had to switch to Visual Studio.
It does still exist, and I'd love to try it out, but I'm not throwing down thousands of dollars when it costs significantly less for me to get Visual Studio Pro as a single developer ($30 a month iirc) or you know... $120 for JetBrains IDE's annually (after 3 years) it makes no sense for me to throw down a thousand dollars (per year?) same with you Qt. I'm looking to evaluate your product and prototype and maybe build small projects that need a UI but your pricing scheme is not for people like me at all.
One would likely argue that JetBrains probably isnt a RAD IDE, but Visual Studio definitely is fully capable of RAD editing capabilities, think WinForms.
I tried it out and it wasn't exactly stable. Someone from Embarcadero that was mostly marketing reached out to me and I told them I had issues, they just tried to sell me a license instead of taking the time to get someone technical to talk to me. Not sure I want to buy a license from someone who doesn't invest more into ensuring their primary customer base gets the help they need. I'm not even sure if I'm allowed to build anything commercial under their free tier if I wanted to, so if I want to see if something would be worthwhile now I have to take a thousand dollar gamble as opposed to $30 a month with Visual Studio Pro, or even $120 with JetBrains.
Update: Looks like JetBrains is $149 per year, and moving forward after October 2022 it will be $173 per year.
As someone who worked with Delphi for many years I've often wondered if there is a lot of money to be made by charging companies to work on these codebases. As much as I liked Delphi back in the day,
low job satisfaction puts me off looking in to the idea.
Could someone please explain/describe how GUI creation was done with Delphi? I tried to look up a video/wiki page but I don’t see what kind of abstraction did it use and why was it as liked?
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 idea?
> I was interested in whether it had some unique feature/paradigm, or was it loved for some other reason.
It was so beloved because it actually worked exactly as the marketing slogan at the time claimed: "The power of C++ with the ease of Visual Basic". (Or was it the other way around?)
This was a time when Microsoft's "Visual" Studio IDE was anything but: It had no visual form builder, just a code editor. To actually put something on screen, you had to write reams of code straight out of a Charles Petzold tome. Visual Basic, OTOH, sure did have a nice easy graphical UI builder, but a pathetically weak ultra-high-level language -- in contrast to Object Pascal, which is every bit as high- or as low-level as C++.
I learned all three in an "Object Oriented Programming" course I took in 1995, IIRC in the order 1: OO concepts, 2: C++, 3: VB, 4: Delphi (or was it 2: VB, 3: C++?). After the two preceding, Delphi was a revelation and love at first sight.
That love soured slightly after the Kylix debacle, some more with diverse bugginess and drawn-out implementation of Windows developments (Unicode, 64-bit, High-DPI...), and finally petered out almost totally over the covert "feature moved to higher-priced more Enterprise-y edition" and overt price hikes over the years (decades) since, with the on-again off-again free (gratis) Community Edition shenanigans as perhaps the final nail in the coffin.
But Delphi versions 1 through 7 (1995 -- ca 2005-10) still has, and probably will for ever have, a special place in my heart as my most beloved programming tool. And fortunately, it has a worthy heir in Free Pascal / Lazarus.
Open Notepad, yeah, that classic one from Windows. Look at it, see all its menus, features, behavior. Now ask yourself: How much time would take me to create a clone of it in my preferred IDE/programming language?
Then comeback here and tell me your answer. I will tell you in advance mine: "In Delphi it would take maximum 3 hours". That's the core definition of RAD.
What it did well was data binding of UI controls to SQL databases. A form would be linked to a database viewmodel (ish) where you could drop sql connections and tables to link up to a UI. Delphi (the vcl) took care of everything. You could put an editable grid on a page and all CRUD would _just work_
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++
Drag and drop. Look at Visual Studio's handling of C#--and polish it. And note that I'm comparing a 15 year old version of Delphi against current VS--and I still favor the Delphi version.
The linked page may be a snapashot of what delphi became: the video autoplays; controls disappear spontaneously with no obvious way to bring them back; most of the initial time in the video is spent showing the welcome screen: you can now set the background image and theme!; it has lots of text in the form of images, one of these says "Support for 4k+ Screens. Welcome to the future!"; the download button puts you in a page where you have to enter a lot of personal information and prove your are not a robot.
Delphi was great, until C# and WinForms came along. Then there was honestly no reason for me to use Delphi again. All the other UI junk in Visual Studio is terrible in comparison, for me.
Both Embarcadero.com and Lazarus project homepage refers to that they have the capability of RAD.
Lazarus - "RAD - Rapid Application Development."
Embarcadero - "RAD Server - Reduces the complexities of rapidly building and deploying a multi-tier turn-key enterprise REST API application server with Swagger support."
Wikipedia has an article[0], but in general it can probably be thought as a precursor to agile (the article says that agile is a RAD method) in that instead of doing some lengthy pre/planing process you use an iterative approach that adapts to what the users want.
In this particular case Lazarus is a RAD IDE in the sense that it allows quick development and iteration of functional GUIs - Delphi was also like that but at some point Borland/Inprise/CodeGear/Embarcadero/Whoever made it more of a name to use for their products ("RAD Studio") than something that describes them.
Delphi and it's components are still nice. But their C++Builder seems like if just keeps getting worse. Instead of maintaining the Borland compiler and debugger they've been replacing it with new ones that work about a quarter as well.
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 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. Getting the UI layout done and components connected to the DB will take me a day tops, it'll look great and based on history should work for the next 10+ years. The web seems like such a step back whenever I try it.