12 ms·

Delphi is still unrivaled when it comes to rapid GUI prototyping in combination with easy deployment. It's much easier than QT/GTK and you usually get a standal

Delphi is still unrivaled when it comes to rapid GUI prototyping in combination with easy deployment. It's much easier than QT/GTK and you usually get a standalone .exe with no external dependencies. I really want to cry when I see the current alternatives... Node/Electron with dozens of MB of runtime and all that Javascript stuff? What went wrong that we end up with this?

riledhel 10y ago
And compile times were pretty fast too
- yoodenvranx 10y ago
  I really want to see Delphi compile times on a modern i7 and a fast SSD. For small-ish projects that should be pretty much instantaneously.
  - tvmalsv 10y ago
    That is correct. My "apps" are really just small utilities, and the compile times are about 1s or a little less on my older i7 with spinning rust.
  - vintagedave 10y ago
    This video shows a million lines of code in five seconds: https://www.youtube.com/watch?v=Yq2mNUzcpE0 https://www.youtube.com/watch?v=Yq2mNUzcpE0
    - boznz 10y ago
      Just about sums up why I still use it if I want to get something done.
  - PeCaN 10y ago
    It's instantaneous for large projects. Literally I've compiled fairly large Delphi projects in the time it takes a Python interpreter to start.
jsudhams 10y ago
I miss VB6 and VB.net desktop apps as well. still my go to platform for personal apps, so easy to write. Not really sure why for internal company apps people are moving to webapp.
- lojack 10y ago
  We use web apps at my company because almost all developers know how to make them, not all computers are windows PCs, and you don't need to install anything of download anything for someone to use them. If you're talking about electron apps, that's a whole other ballgame. We don't build electron apps for internal stuff afaik.
  - mattmanser 10y ago
    To be fair to him, it used to be that everyone knew how to make desktop apps and no-one knew how to make web apps. So that's definitely not the reason.
    - lojack 10y ago
      I can tell you with 100% certainty that the primary reason we build webapps for internal products at my company is because all the developers already know it. I understand this is more of an anecdote, but I really find it hard to believe other companies aren't making similar decisions.
      - mattmanser 10y ago
        I can tell you, with 100% certainty, that 10 years ago that was not the case. And there's a really good reason everyone switched.
        lojack 10y ago
        I can tell you that I agree completely with that. But, that's not at all what I'm disputing. People within companies are building web apps because thats what they know. The world has changed in the past 10 years. In response to that, you took a hard line stance that this is "definitely not the reason." I disagree. I _think_ you're trying to argue about why developers -- as a whole -- have moved towards web apps, but its hard to say because that's not at all what I'm talking about and you haven't made that part clear.
metachris 10y ago
The strong point of Electron is easy _cross-platform_ application development and packaging (spits out .exe, .app and Linux binary), with no further dependencies. Ever tried packaging a QT application for Mac, Windows and Linux? I can tell you it's a painful experience, one I don't want to repeat. Also HTML+CSS allows for extremely versatile styling and fine-grained control of appearance.
- wtbob 10y ago
  A weak point, though, is JavaScript — quite possibly the worst popular computer language in history. I honestly think I'd rather starve than write another line of JavaScript again. Even reading JavaScript diffs from other guys on my team is a horrible, terrible experience. It's just a sad, awful, miserable, verbose, broken language. As a compilation target from a better language, I suppose it's mostly acceptable. But on its own? Never again.
  - problems 10y ago
    The problem with it as a compilation target in my experience is that interacting with other libraries becomes challenging - the JS ecosystem is now huge, but if you want to use many of those libraries from a wrapping language, it's possible but might present many challenges. Like Typescript definition files. Producing them on a massive libraries is near impossible for a single individual to undertake. I've seen some people try to process them from docstrings, but the result was really kludgey.
    - WorldMaker 10y ago
      I think writing Typescript definitions for a massive library is usually pretty straight forward and I've got a few that I haven't minded writing/helping maintain. "Good enough" typings can be very quick and easy to build and "Perfect" typings take time sometimes but nowhere near "impossible". Furthermore, Typescript recently made it much easier to work with libraries that have no typings at all. If you don't mind implicit anys, things might just work. If you are strict about no implicit anys then the minimum boiler plate to define a module with any type has dropped to a bare minimum: declare module 'module-name' If I have a complaint in that space, it's that sharing typings is a lot more complex than I think it should be. DefinitelyTyped is a single megarepo where most typings originate and has developed a culture of trying to get typings perfect. Unfortunately, perfect is the enemy of the good, and "good enough" typings for lesser used libraries often languish in PR obscurity, at least in my experience. Beyond DefinitelyTyped, libraries can embed their own typings in their npm packages, which is great, but not every library author is thrilled to "own" Typescript typings. (All in all, I still feel like I have better luck contributing typings directly to library authors than DT, though.) Beyond that there are tools like Typings to grab typing files from arbitrary GitHub repos, for instance, but there's not much of a good way to advertise types that way because most people will only check NPM now. Sorry, this seems to have turned into more of an off topic rant than I at first intended.
rubber_duck 10y ago
Web has a good deployment/discover-ability/accessibility story, Node/Electron/Cordova are just there to reuse the work you already did. It's not technically superior but it's economically superior since you usually get maximum reach with web and then minimize cost with the hybrid approach.
- marvin 10y ago
  Distribution is the number one reason we do webapps at all. I feel this point is sometimes lost on younger generations that have barely seen on-site deployments at all. Sometimes you don't need the distribution magic that webapps allow, and can dispense with the huge overhead that comes with it. That's where tools like Deliphi/Windows Forms et al can make your life easier. Today it's a corner case, but it's worth keeping in mind that it's still an option.
marvin 10y ago
Windows Forms is still a completely decent option that gives you the same advantages.
- zubspace 10y ago
  I fully agree. I sometimes wonder, why so many people jump to fancy frameworks like WPF where you need to create the markup yourself. I can spit out interfaces for desktop apps in no time with good old winforms but struggle to write data-bindings, triggers and what not in other frameworks. And it even looks consistent and the tools are generally easy to adjust and extend.
  - astine 10y ago
    You don't need to write the markup yourself with WPF. You can drag components into the designer just the same as with winforms assuming you are using Visual Studio, and everything will look pretty standard unless you go out of your way to change it. As to the databinding, I find that WPF has more upfront work in databinding, in that you actually have to write some code, but that it's a lot more flexible in the long run. When I used to write winforms, I usually ended up with a lot of business logic embedded in hooks. It was a mess and was hard to reason about.
    - WorldMaker 10y ago
      I think there is an interesting learning curve point where once a developer gets used to WPF layouting/templating, databinding, and MVVM patterns that developer will forever after be way more productive on WPF than WinForms.
- bakhy 10y ago
  i fully agree! though technically, there is a pretty big dependency there - the .NET Framework... however, Mono supports WinForms on all platforms, and is able to compile everything into one standalone EXE. to be honest, i have not tried either, so i cannot say much about how that works in practice. from my experience with Mono, it can be dangerous. every now and then a new version breaks threading, causing mysterious pauses or crashes, and i've read (i think a text by Ayende) that the GC can also be buggy. but for the stuff that Delphi was good at, for smaller RAD apps, it might be worth a try.
ptero 10y ago
IMO Pascal is a good, clean language and Borland was a top engineering shop that built Delphi as a rapid development tool that supported Windows. At the time there was nothing comparable for Windows development. There was a huge marked for Windows consumer applications and games (Linux was not a household name yet) and very little outside of clumsy Visual Studio to write them. I recall reading at WSJ at the time that Borland CEO was the only person whom Bill Gates feared as a competitor. That said, it was 20 years ago. Now there are IMO much better cross platform tools for RAD (Python, Tcl/Tk, ...) and Delphi is showing its age (no Linux targets?). Unless I have to live in a Pascal world there are much better tools today. My 2c.
- yoodenvranx 10y ago
  > Now there are IMO much better cross platform tools for RAD (Python, Tcl/Tk, ...) That's why I wrote "in combination with easy deployment". Yes, you can do faster RAD in Python but good luck with easy deployment.
  - aidenn0 10y ago
    Tcl/Tk is trivial to deploy; on linux and OS X, wish already exists and tclkit makes it easy to deploy in windows.
- vintagedave 10y ago
  > no Linux targets? Linux is coming in the next release - there will be a blog on that soon. It already has Mac, iOS, and Android on top of its Windows support. Honestly, I do not believe that Python or Tcl/Tk count as "good" RAD cross-platform tools. Only if you've never used something like modern Delphi to compare them to. We regularly have customers give feedback about their productivity with Delphi/C++Builder, versus Python, C#, etc, and they say they get apps completed and released twice as fast or often more. "5x" is quoted often in our marketing material, and that number is not marketing, it's based on numbers people tell us. - David (one of the PMs at Embarcadero; I work with the blog author Marco.)
  - marcosdumay 10y ago
ivm 10y ago
> Delphi is still unrivaled when it comes to rapid GUI prototyping in combination with easy deployment. Try Unity3d component-based uGUI that you can edit live during the "playmode". After building complex UIs in it, going back to Xcode Interface Builder is like moving from iOS to a smartphone from 2005.
statictype 10y ago
What went wrong that we end up with this? Shifting of priorities. I remember when people used to complain that Delphi executables were 'bloated' and large - 200KB was the minimum size? At that time the complaints didn't seem absurd when we were connecting via 36k dialups. Admittedly we have probably swung too much in the other direction.
- jmiserez 10y ago
  The apps on my phone easily reach 100MiB each, how is that the other direction?
  - debacle 10y ago
    He's saying the focus switched from how small your package can be to not caring about install size.
erikpukinskis 10y ago
> Node/Electron with dozens of MB of runtime and all that Javascript stuff? What went wrong that we end up with this? I'll tell you. Microsoft and Apple need to protect their native app license revenue, so they hobbled Netscape, brought browser development in house, and made a prohibition on allowing web pages to be integrated tightly into the OS. If those electron apps could get the same OS integration in the browser as native apps get, the distributable could be kilobytes, even smaller than your Delphi executable. But how would Microsoft and Apple make money if they're just a host for web apps? They're not going to turn themselves into a commodity/utility.
- iajrz 10y ago
  > Microsoft and Apple need to protect their native app license revenue I don't really understand. I never paid a license to create and distribute native applications.
  - erikpukinskis 10y ago
    Well there's Office. But also you provide the content which makes Windows licenses have value. If there were no Windows apps, they couldn't price it higher than Linux.
- cwyers 10y ago
  This seems... backwards. What integration could MS give to web apps that they aren't already? Microsoft replaced their help file format with HTML starting with Vista. HTML and JS are first-class languages for building UWP apps. If anything, it's Netscape's lawsuit against MS for bundling IE that kept them from doing more to integrate web pages into the OS, not the moving of browser development in-house.
  - erikpukinskis 10y ago
    Start menu integration, USB device access, graphics and sound APIs, notifications... Just look at the Windows APIs there are a wealth of things Microsoft doesn't want in browsers if they can avoid it. Well... there are people on the browser team trying their best, but the resource constraints keep investment where it needs to be to protect Windows and Office licensing.
draegtun 10y ago
Rebol/View (& SDK) was a great alternative. An extremely light weight language, library & cross-platform GUI (exe was under 1mb). Ideal for very rapid GUI prototyping... * http://www.rebol.com/rebol-view.html http://www.rebol.com/rebol-view.html * http://www.rebol.com/docs/sdk/ http://www.rebol.com/docs/sdk/ * http://re-bol.com/business_programming.html http://re-bol.com/business_programming.html NB. I say "was" because Rebol 2 SDK has (i believe) been discontinued. Rebol 3 & Red do offer new GUI / encapping replacements but not at same level of maturity.

riledhel 10y ago

And compile times were pretty fast too

yoodenvranx 10y ago
I really want to see Delphi compile times on a modern i7 and a fast SSD. For small-ish projects that should be pretty much instantaneously.
- tvmalsv 10y ago
  That is correct. My "apps" are really just small utilities, and the compile times are about 1s or a little less on my older i7 with spinning rust.
- vintagedave 10y ago
  This video shows a million lines of code in five seconds: https://www.youtube.com/watch?v=Yq2mNUzcpE0 https://www.youtube.com/watch?v=Yq2mNUzcpE0
  - boznz 10y ago
    Just about sums up why I still use it if I want to get something done.
- PeCaN 10y ago
  It's instantaneous for large projects. Literally I've compiled fairly large Delphi projects in the time it takes a Python interpreter to start.

jsudhams 10y ago

I miss VB6 and VB.net desktop apps as well. still my go to platform for personal apps, so easy to write. Not really sure why for internal company apps people are moving to webapp.

lojack 10y ago
We use web apps at my company because almost all developers know how to make them, not all computers are windows PCs, and you don't need to install anything of download anything for someone to use them. If you're talking about electron apps, that's a whole other ballgame. We don't build electron apps for internal stuff afaik.
- mattmanser 10y ago
  To be fair to him, it used to be that everyone knew how to make desktop apps and no-one knew how to make web apps. So that's definitely not the reason.
  - lojack 10y ago
    I can tell you with 100% certainty that the primary reason we build webapps for internal products at my company is because all the developers already know it. I understand this is more of an anecdote, but I really find it hard to believe other companies aren't making similar decisions.
    - mattmanser 10y ago
      I can tell you, with 100% certainty, that 10 years ago that was not the case. And there's a really good reason everyone switched.
      - lojack 10y ago
        I can tell you that I agree completely with that. But, that's not at all what I'm disputing. People within companies are building web apps because thats what they know. The world has changed in the past 10 years. In response to that, you took a hard line stance that this is "definitely not the reason." I disagree. I _think_ you're trying to argue about why developers -- as a whole -- have moved towards web apps, but its hard to say because that's not at all what I'm talking about and you haven't made that part clear.

metachris 10y ago

The strong point of Electron is easy _cross-platform_ application development and packaging (spits out .exe, .app and Linux binary), with no further dependencies. Ever tried packaging a QT application for Mac, Windows and Linux? I can tell you it's a painful experience, one I don't want to repeat. Also HTML+CSS allows for extremely versatile styling and fine-grained control of appearance.

wtbob 10y ago
A weak point, though, is JavaScript — quite possibly the worst popular computer language in history. I honestly think I'd rather starve than write another line of JavaScript again. Even reading JavaScript diffs from other guys on my team is a horrible, terrible experience. It's just a sad, awful, miserable, verbose, broken language. As a compilation target from a better language, I suppose it's mostly acceptable. But on its own? Never again.
- problems 10y ago
  The problem with it as a compilation target in my experience is that interacting with other libraries becomes challenging - the JS ecosystem is now huge, but if you want to use many of those libraries from a wrapping language, it's possible but might present many challenges. Like Typescript definition files. Producing them on a massive libraries is near impossible for a single individual to undertake. I've seen some people try to process them from docstrings, but the result was really kludgey.
  - WorldMaker 10y ago
    I think writing Typescript definitions for a massive library is usually pretty straight forward and I've got a few that I haven't minded writing/helping maintain. "Good enough" typings can be very quick and easy to build and "Perfect" typings take time sometimes but nowhere near "impossible". Furthermore, Typescript recently made it much easier to work with libraries that have no typings at all. If you don't mind implicit anys, things might just work. If you are strict about no implicit anys then the minimum boiler plate to define a module with any type has dropped to a bare minimum: declare module 'module-name' If I have a complaint in that space, it's that sharing typings is a lot more complex than I think it should be. DefinitelyTyped is a single megarepo where most typings originate and has developed a culture of trying to get typings perfect. Unfortunately, perfect is the enemy of the good, and "good enough" typings for lesser used libraries often languish in PR obscurity, at least in my experience. Beyond DefinitelyTyped, libraries can embed their own typings in their npm packages, which is great, but not every library author is thrilled to "own" Typescript typings. (All in all, I still feel like I have better luck contributing typings directly to library authors than DT, though.) Beyond that there are tools like Typings to grab typing files from arbitrary GitHub repos, for instance, but there's not much of a good way to advertise types that way because most people will only check NPM now. Sorry, this seems to have turned into more of an off topic rant than I at first intended.

rubber_duck 10y ago

Web has a good deployment/discover-ability/accessibility story, Node/Electron/Cordova are just there to reuse the work you already did. It's not technically superior but it's economically superior since you usually get maximum reach with web and then minimize cost with the hybrid approach.

marvin 10y ago
Distribution is the number one reason we do webapps at all. I feel this point is sometimes lost on younger generations that have barely seen on-site deployments at all. Sometimes you don't need the distribution magic that webapps allow, and can dispense with the huge overhead that comes with it. That's where tools like Deliphi/Windows Forms et al can make your life easier. Today it's a corner case, but it's worth keeping in mind that it's still an option.

marvin 10y ago

Windows Forms is still a completely decent option that gives you the same advantages.

zubspace 10y ago
I fully agree. I sometimes wonder, why so many people jump to fancy frameworks like WPF where you need to create the markup yourself. I can spit out interfaces for desktop apps in no time with good old winforms but struggle to write data-bindings, triggers and what not in other frameworks. And it even looks consistent and the tools are generally easy to adjust and extend.
- astine 10y ago
  You don't need to write the markup yourself with WPF. You can drag components into the designer just the same as with winforms assuming you are using Visual Studio, and everything will look pretty standard unless you go out of your way to change it. As to the databinding, I find that WPF has more upfront work in databinding, in that you actually have to write some code, but that it's a lot more flexible in the long run. When I used to write winforms, I usually ended up with a lot of business logic embedded in hooks. It was a mess and was hard to reason about.
  - WorldMaker 10y ago
    I think there is an interesting learning curve point where once a developer gets used to WPF layouting/templating, databinding, and MVVM patterns that developer will forever after be way more productive on WPF than WinForms.
bakhy 10y ago
i fully agree! though technically, there is a pretty big dependency there - the .NET Framework... however, Mono supports WinForms on all platforms, and is able to compile everything into one standalone EXE. to be honest, i have not tried either, so i cannot say much about how that works in practice. from my experience with Mono, it can be dangerous. every now and then a new version breaks threading, causing mysterious pauses or crashes, and i've read (i think a text by Ayende) that the GC can also be buggy. but for the stuff that Delphi was good at, for smaller RAD apps, it might be worth a try.

ptero 10y ago

IMO Pascal is a good, clean language and Borland was a top engineering shop that built Delphi as a rapid development tool that supported Windows. At the time there was nothing comparable for Windows development. There was a huge marked for Windows consumer applications and games (Linux was not a household name yet) and very little outside of clumsy Visual Studio to write them. I recall reading at WSJ at the time that Borland CEO was the only person whom Bill Gates feared as a competitor. That said, it was 20 years ago. Now there are IMO much better cross platform tools for RAD (Python, Tcl/Tk, ...) and Delphi is showing its age (no Linux targets?). Unless I have to live in a Pascal world there are much better tools today. My 2c.

yoodenvranx 10y ago
> Now there are IMO much better cross platform tools for RAD (Python, Tcl/Tk, ...) That's why I wrote "in combination with easy deployment". Yes, you can do faster RAD in Python but good luck with easy deployment.
- aidenn0 10y ago
  Tcl/Tk is trivial to deploy; on linux and OS X, wish already exists and tclkit makes it easy to deploy in windows.
vintagedave 10y ago
> no Linux targets? Linux is coming in the next release - there will be a blog on that soon. It already has Mac, iOS, and Android on top of its Windows support. Honestly, I do not believe that Python or Tcl/Tk count as "good" RAD cross-platform tools. Only if you've never used something like modern Delphi to compare them to. We regularly have customers give feedback about their productivity with Delphi/C++Builder, versus Python, C#, etc, and they say they get apps completed and released twice as fast or often more. "5x" is quoted often in our marketing material, and that number is not marketing, it's based on numbers people tell us. - David (one of the PMs at Embarcadero; I work with the blog author Marco.)
- marcosdumay 10y ago

ivm 10y ago

> Delphi is still unrivaled when it comes to rapid GUI prototyping in combination with easy deployment. Try Unity3d component-based uGUI that you can edit live during the "playmode". After building complex UIs in it, going back to Xcode Interface Builder is like moving from iOS to a smartphone from 2005.

statictype 10y ago

What went wrong that we end up with this? Shifting of priorities. I remember when people used to complain that Delphi executables were 'bloated' and large - 200KB was the minimum size? At that time the complaints didn't seem absurd when we were connecting via 36k dialups. Admittedly we have probably swung too much in the other direction.

jmiserez 10y ago
The apps on my phone easily reach 100MiB each, how is that the other direction?
- debacle 10y ago
  He's saying the focus switched from how small your package can be to not caring about install size.

erikpukinskis 10y ago

> Node/Electron with dozens of MB of runtime and all that Javascript stuff? What went wrong that we end up with this? I'll tell you. Microsoft and Apple need to protect their native app license revenue, so they hobbled Netscape, brought browser development in house, and made a prohibition on allowing web pages to be integrated tightly into the OS. If those electron apps could get the same OS integration in the browser as native apps get, the distributable could be kilobytes, even smaller than your Delphi executable. But how would Microsoft and Apple make money if they're just a host for web apps? They're not going to turn themselves into a commodity/utility.

iajrz 10y ago
> Microsoft and Apple need to protect their native app license revenue I don't really understand. I never paid a license to create and distribute native applications.
- erikpukinskis 10y ago
  Well there's Office. But also you provide the content which makes Windows licenses have value. If there were no Windows apps, they couldn't price it higher than Linux.
cwyers 10y ago
This seems... backwards. What integration could MS give to web apps that they aren't already? Microsoft replaced their help file format with HTML starting with Vista. HTML and JS are first-class languages for building UWP apps. If anything, it's Netscape's lawsuit against MS for bundling IE that kept them from doing more to integrate web pages into the OS, not the moving of browser development in-house.
- erikpukinskis 10y ago
  Start menu integration, USB device access, graphics and sound APIs, notifications... Just look at the Windows APIs there are a wealth of things Microsoft doesn't want in browsers if they can avoid it. Well... there are people on the browser team trying their best, but the resource constraints keep investment where it needs to be to protect Windows and Office licensing.

draegtun 10y ago

Rebol/View (& SDK) was a great alternative. An extremely light weight language, library & cross-platform GUI (exe was under 1mb). Ideal for very rapid GUI prototyping... * http://www.rebol.com/rebol-view.html http://www.rebol.com/rebol-view.html * http://www.rebol.com/docs/sdk/ http://www.rebol.com/docs/sdk/ * http://re-bol.com/business_programming.html http://re-bol.com/business_programming.html NB. I say "was" because Rebol 2 SDK has (i believe) been discontinued. Rebol 3 & Red do offer new GUI / encapping replacements but not at same level of maturity.