Unfortunately "dependency hell" was very real -- it was super-easy to download ActiveX controls, install on the system, and then depend on them in the apps. Worse, Windows had a single ActiveX database per computer, and an control installed by a completely unrelated app would appear in the Delphi's palette, ready to be placed on a form. After having a few apps that would not work on friends' computers, I've mostly gave up on ActiveX components completely.. luckily third-party Delphi components were better - at least the compiled binaries would work. Source code still required system-wide install though...
If you think that "pip install", or "npm install", or even "apt-get install" on a Linux system is bad, you haven't seen what Delphi world was like. But to be fair, it's not really Delphi's fault - all Windows development was like that, full of bespoke settings that need to be set on each PC. For a complex software, it was normal to spend a few days just setting up the system so you can do initial build.
Another Delphi-specific issue was that by default forms were specified in pixels, and were hard-coded to specific font sizes; and color pickers had hardcoded colors (as opposed to system theme colors) prominently displayed. Unless you were very careful, it was very easy to make an app that could not handle different font or screen theme. And many apps that would benefit greatly from being resizable were non-resizeable instead, just because it was easier.
In fact AFAIK ActiveX support in Delphi was implemented by generating a wrapper component that converted the ActiveX control stuff to what Delphi "naturally" speaks.
For forms, even in Delphi 2 you can use the "align" property in several controls to automatically position them inside a container using the top, bottom, left, right and client area. The areas also stack so you can, e.g., position several controls at the top area and you'd get an effect similar to what a VBox container would provide in other toolkits. Though the initial versions of Delphi did not have this available everywhere, it was added to various controls over time.
Later versions also added "anchors" so that you can drag-drop stuff visually to the form but also have them resize automatically based on the parent's size. Lazarus (sort of open source Delphi-like IDE) extended this to allow anchoring stuff related to other control (so, e.g., you could have a button's right side a few pixels from another button's left side and that button's right side be a few pixels from the container's right side, or have a label be placed at the middle of an input box, or other stuff like that).
Maybe, but Delphi had anchor fields that you could use to make everything resize nicely.
The problem with that time period was that most applications were designed to not be resizeable, including most of the ones that came with Windows itself.
We still have that - some of the Windows programs right now can't be resized (Thinking specifically of dialogs and windows for device manager->driver details, or explorer->options).
This wasn't a Delphi problem at all; it was a Windows problem because that was the convention on Windows at the time.[1]
[1] EDIT: s/Windows/GUI systems/g
And I don't think other GUI systems were all that much better. Eg MacOS has plenty of fixed size stuff right now.
It was convention across all GUI systems.
As far as COM and ActiveX, though, the ability to package them side by side in the app install folder and describe them using XML (in the app manifest) rather than registry has been around since WinXP.
I also feel like this created a kind of positivity at the time rarely experienced today. I remember these Delphi conferences I used to go to as a teenager with my dad with many of the names Marco mentioned in his acknowledgments present, including himself. It was really rapid application development (RAD) without many of the stuff that parent mentions that brings so much struggle today (frontend) software development. People were having fun building software.
I’m happy to see that most of these names still seem to be able to make a living off Delphi. There’s probably still a lot of critical Windows enterprise software being maintained that needs consulting and support. Including my dad’s software he wrote 30 years ago which is still being maintained and used daily.
At my old company, it took 2 years and $2 million to re-write an application in Java. That's the cheapest project that Accenture would take.
So as long as you keep your legacy service contracts under that, you're fine. It might even be $3 million now with the new Java licensing terms.
For online I don't think Borland, or whoever owned Delhi back then, really had the resources to keep up with everything else. Even today it's pretty expensive to buy the tooling from Embarcadero to keep projects alive, but probably cheaper and less risky that porting to another language.
For example, all layout was pixel based. Making windows resizable required much complex ad-hoc code, and internationalization was hard as well. Very early in my career, I have spent person months clicking through every single screen in a large desktop application to find words cut off due to words having different lengths (measured in pixel) in different languages. I knew what "Ok" and "Cancel" meant in half a dozen languages. At the time, Java was really breaking ground with container based layouts in Swing. Delphi and Visual Basic caught up only in the .NET era.
Back in the day, JBuilder offered a Delphi like experience.
What I would agree is that the thing that actually made Swing hard are the defaults, which required books like "Filthy Rich Clients" as gate into making wow Swing applications.
> All layout was pixel based.
I'd say that was a very reasonable trade-off at the time, when most screens were somewhere between 640x480 and 1024x768 resolutions at 72 DPI. This simplified UI design sufficiently enough that VB/Delphi provided an optimal solution that, yes in hindsight, would most accurately be described as a "local maxima" for the environment and the time.
> Making windows resizable required much complex ad-hoc code
I remember there were ActiveX controls one could drop onto their form that would attempt to derive the layout based on initial positioning of controls, i.e. that a lower row of buttons should be anchored to the bottom of the window, while textboxes are took up a larger area would automagically resize with the window.
(it has been a very long time, but I think those only handled internal composition and not overall window size.. so you'd still need some custom code if you wanted dialogs as compact as possible. But as long as you never missed setting Align property, you did _not_ have to manually resize every control for different text/font size).
https://web.archive.org/web/20160406102051/http://vbrad.com/...
Oh my was I amazed.
https://docs.oracle.com/javase/8/docs/api/java/awt/class-use...
Believe that was there from the beginning, mid 90s.
Microsoft has been pushing XAML for long enough that it could drink, drive and vote in my country
These sort of excuses always come up when Delphi and its insane productivity is mentioned. The same thing happens in conversations about how slow software has gotten.
High-DPI displays, internationalization, and accessibility are a pain but don't introduce enough complexity to hand-waive away the criticism.
Going a bit off-topic, but the browser is carrying around so many legacy concepts and ideas - it's a complete disaster - but it's the only option. The document object model is slow and weird to use to build reactive user interfaces.
We should demand something better. The browser is a local maximum as an application platform, and we should stop defending it.
Both had layout managers, they just required a bit more effort to use, and developers as we know are all lazy.
My day job involves working with PeopleTools, which basically does this. Draw forms (and build all of the supporting objects), save them, and they're accessible through a web browser. You don't need to know HTML, CSS, JS, etc (though it can help), and you can knock out a very based CRUD form in no time without writing any code.
I think the Microsoft Power Platform has features similar to this as well.
But neither of these options are very accessible to regular folks. Something that has the ease of development of Delphi, the deployment simplicity that comes with presenting the application via a web browser, and is accessible to regular folks would be incredible.
This is truly interesting, and the description on that wiki page suggests that it might be exactly what I'm looking for, but it seems like any concrete information about it has vanished.
https://xojo.com/products/web.php
I haven't really used it - I'm just a hobbyist coder who enjoys the VB6 style development of the desktop version of Xojo.
I find myself waffling between "This is too expensive for me to play around with at home" and "Considering what this does, $399 really isn't that bad..."
I'm still tempted...
It is incredible that given its heritage, we have had to wait 25 years for .NET to finally provide a similar experience, and there are still some rough edges.
While it offered a way to perform AOT compilation, NGEN was only meant for fast startup and nothing else.
It's even the same person: Microsoft poached Anders Hejlsberg, creator of both Turbo Pascal and Delphi, to architect .net.
If anyone poached Anders Hejlberg, it was the ex-Borland friends working at Microsoft, under the usual referral program many companies have.
Actual history behind on what happened,
"Anders Hejlsberg: A craftsman of computer language"
https://behindthetech.libsynpro.com/001-anders-hejlsberg-a-c...
And yes that is why .NET not having proper AOT in 2001 was such a disappointment.
While I get the aversion, HTML+CSS is a pretty good combination for layout and there are efforts towards application tooling for other languages. That said, I don't dislike JS/TS nearly as much as some on here. It's a highly expressive language that's flexible enough to get things done in a number of ways. And yeah, the overhead is kind of crazy, especially when devs bring in massive dependency chains. As a whole, it's still one of the better options for getting an application "everywhere".
What's wrong with Lazarus, compared to Delphi?
I'd like to know more about this. Any links to the discussions? My google-fu is failing me right now.
So, even though Android and iOS modules could be more thoroughly integrated into Lazarus or they putting forth an integrated LCL based solution, they're not. That's very weird. From the perspective of how much more useful Lazarus can be, and from their users asking for it.
[1] https://github.com/jmpessoa (LAMW)
These web apps show tables with data, images with figures, and some controls to request calculations or data from a server. jQuery is used to update the drop-down list according to previous choices.
You are not tied to Visual Studio or Windows (as in, you can target Windows and Linux when using macOS, or Windows and macOS when using Linux).
Rust is generally anemic if you need a visual editor. Go and Python are in even worse state (there are no production-ready frameworks for Go to do cross-plat GUI app dev).
The biggest alternative so far is Flutter.
It failed within a year or two.
> Especially on the web side, where even a single view sometimes requires having multiple unrelated dependencies (packers, builders, transpilers, etc.),
... is only true if you jumped on the SPA bandwagon. Things don't have to be this complicated.
However I feel like the current paradigm of declarative ui, with automatic re-render, like React (and what I actually use: Compose Multiplatform) is very good for producing maintainable applications and encourages UI decoupling.
I agree that the dependency hell and project setup parts on the web are horrible, but I wouldn't say it's part of "UI Development".
First time someone used “grandparent” and I could relate :-)