I did professional development in Delphi for 13 years, writing and maintaining a sprawling 700k line reservation system. I don't miss it much. It was a great learning experience to have to fill in all the gaps in the standard libraries by twisting and turning Pascals rigid rules into something semi-useful; writing foreign function interfaces to WinSock to get around the limitations in the provided toy socket implementation; finding ways to convince the over-engineered pixie-dusty data-layer to issue effective SQL; and trying to keep up with Borland's, nay Inprise's, wait Embarcadero's, ever changing priorities and price hikes.
I don't even find the GUI-builder that amazing. It's very easy to use, and up to a certain scale it's very convenient; but it encourages and rewards coupling the implementation to the interface at every turn, making any attempt to do the right thing an uphill struggle.
One of the most painful memories I have from software, the stuff that haunts me in my dreams; is writing stored procedures for Delphi's favorite database, Interbase. Whenever you did something wrong, it would give you an error saying 'Error at BLR offset 283729' or similar, offset being the offset in the compiled code where the error supposedly happened; thereby forcing an inhuman level of discipline when making changes. I had to write and maintain thousands of lines of that bullshit; since by the time we dug that deep into the performance of the BDE, the entire application was fused to it on UI level. Switching meant going through every single stupid form in the application and carefully translating event logic, bindings and properties to pure SQL.
You experience is more a reflex on the nose-dive that management than what the tool/language is; including the Interbase engine, that was open-sourced then become closed fast.
Bad code is normal across enterprise applications, but even taking into account the RAD biased approach of the Delphi IDE is easy to do good coding. What is not easy is to have badly-trained developers doing massive amounts of code.
I know, because as moderator in Club Delphi, we answer A LOT of question about VERY BASIC stuff. Is amazing the amount of people that use Delphi (or JS, or .NET or PHP... we have sections for that too!) without read even a basic book or some decent basic entry-level tutorials/documentation.
And about databases? Dammit, I don't know who is the bastard to blame in turn one of the easiest thing to learn and convince everyone "Nah! how wanna spend 20 minute of basic SQL/Relational fundamentals? Just write sql dammit!".
The other bulk of questions I help is about SQL...
My experience is 13 years of trying really hard to do the right thing within a sinking ship. Yes, we where young and inexperienced; and yes the foundation of the system was built using what turned out to be the worst turds in Delphi; and yes, I agree that it's possible to build better software in Delphi. But no, really; enough is enough; unless you're absolutely forced to, I see no advantages in choosing Delphi these days.
> it would give you an error saying 'Error at BLR offset 283729' or similar, offset being the offset in the compiled code where the error supposedly happened
Wow, I didn't realise it was possible to have error messages worse than Oracle's.
Kinda like Winsock Error 10107, "A system call that should never fail has failed." I recall running into that one at my first job out of high school - once we'd looked up the error code, we had a good chuckle about how unhelpful it was.
(It was actually our bug - we were doing a Winsock layered service provider, and the error code indicated that we'd failed to return SUCCESS and hadn't set any additional error info. At the time, though, Microsoft's documentation gave only the one sentence above as a description.)
My one brush with Borland C++'s GUI builder was that the developers were doing things like setting the colour of a UI component based on some state (like the background colour of a text box for example), and then elsewhere in the program, checking the colour of that component to make some decision...
I don't blame this on Borland. Nonetheless.. I ran.
Oh the days of WYSIWYG HTML editors. I still find websites that have the Dreamweaver change-image-on-hover JavaScript. They still work on older browsers though...
I see jQuery-Jockey code like that all the time. It's indicative of a novice programmer. I can't blame Borland for that. Just teaching someone that the view should never be the source of truth, can go a long way.
> 'Error at BLR offset 283729' or similar, offset being the offset in the compiled code where the error supposedly happened;
Should have used madExcept or another tool like it. madExcept gives you runtime error logs which report the source code line of origin of any exception in your application. It's incredibly useful, particularly in the scenario you describe:
That early experience gradually got me motivated enough to learn more powerful tools. These days, Common Lisp (https://github.com/codr4life/cl4l) is my preferred tool for most problems; but I'm gradually learning to like Forth as an embedded DSL (https://github.com/codr4life/lifoo) and might be convinced to write C (https://github.com/codr4life/libc4life) under the right circumstances. I swore early on to never, ever settle for crumbles from the design table again. Then I kept on learning the same lesson over and over again through most languages in common use, until I finally accepted that nothing but simple, powerful, general purpose and free was going to work for me. Mysterious ways, indeed :)
Don't know how to put this... The tech/tools you enumerate give me the impression that your problems are not directly related to (commercial) software development.
If I was ever asked "why are you sitting around on the computer all day instead of going and doing something productive", I'd say that I was gaining exposure and experience. Limiting that exposure means less of a general ability to easily orient yourself when dropped into unfamiliar circumstances or situations.
Driving around randomly uses gas and contributes to maintenance costs, but gives you an irreplaceable spatial idea of your environment that you can't get from scrabbling through a directory, and which you definitely can't absorb from Google Maps or a GPS.
I only grasped these ideas quite recently, and have been rather motivating to get me to learn more about the academic aspects of CompSci.
I'm all for building tools to explore CS. However I believe the question they responded to expected a replacement for what I understand to be a very "pragmatic" development environment.
Why not? They're tools, not fashion items. If you dig a bit deeper you'll find an entire category of people writing software using powerful, mature tools. The reason it's not as commercially feasible is that most problems are not really that difficult any more. And since the software won't break every three months because of moving targets, no one will call for your help once it's in place.
The world is big; you can find a few people doing whichever thing, even if weird. But unlike free software developers, companies are still mostly local (as opposed to remote). That's why I'm guessing you're indulging your intellect with these projects rather than building tools to support commercial software development. To be specific, I'd have a hard time imagining a "difficult problem" for which Forth would be the solution. As for Lisp, I realize Clojure is pretty successful, but my best guess for the reason is the JVM.
I work with Delphi professionally. And we maintain a code base of about 150,000 lines of Pascal and about 300,000 lines of T-SQL (written to work in both Sybase and Microsoft SQL).
Delphi may be easy, but it's not simple. Once you get into the meat of things, Delphi's ecosystem truly becomes a limitation.
Delphi's main drawback is its lack of library availability. If you are in the marked for modern technology, using Delphi is a major hindrance. And if you do find something, it's usually not of the same quality as the alternatives for other languages.
I have nothing against Pascal, per say, but I do feel that I am being deliberately terse for the sake of the compiler, rather than for clarity. Indeed, having to declare all variables at the beginning of a method doesn't necessarily make it more clear, sometimes the reverse.
Even a popular tool like Indy for Delphi doesn't correctly implement the HTTP protocol, and therefore doesn't respond as you'd expect on malformed headers, so you have to handle those calls yourselves.
Delphi was leading the pack in the 1990s, but has since fallen behind greatly.
I've written a web server - and maintain a web server - in Delphi, and it's not something I would wish on anyone else.
This makes me think of when I was writing CGI web apps in Turbo Pascal 6.0 running on Windows 95 using AOLserver (I think) in 1995 or so. (Even back then I remember that it felt odd, like two worlds of computing colliding in an unexpected manner. This was just before I got into Linux/SunOS/Unix - perhaps mostly because it felt like it was the way to for the web backend, and the web obviously seemed like something to bet on.)
Turbo Pascal fealt great then (everything was coherent, relatively well-designed, speedy, etc), but after recently looking back at the code from then.. ehh.. we have better things now.
(Except perhaps in ease of getting started - for beginners.)
Dynamic languages have the edge for web development. Web is nasty, badly/poorly "designed", or more exactly, patched to barely work for app development.
BTW, Synapse is better (IMHO) than Indy. One of the biggest damages of MS (yes I blame MS first) is that turn anything in a monster of complexity, I don't know if trying to mimic Java or as side-effect that a big company like MS can't understand how do lean app development.
Then the management idiots at borland follow MS (like everyone else) and the rest follow both. That is how you get something like Indy and other libraries.
Was WAY LATER with the arrival of python/ruby that that become more popular the idea of simple/good design on libraries.
Some of it is returning back to Delphi, however, because management price Delphi out of the equation of many of his own customers not exist a good ecosystem to rely on.
---
P.D: Still do good web development in languages with static types is a bit harder (even F# struggle with it); and I'm unsure what language of this family show a great experience here.
To truly understand and appreciate a language, I believe one must write these features first without a framework (that at least let's someone appreciate the point of a framework more).
However, in this case, this is our own implementation. And unfortunately, this is due to a large number of corner cases we need to handle (such as Sybase support, own SQL driver support, because of multiple result sets, etc.), I don't believe a framework could replace our implementation.
Trust me, though, if we were to rewrite this all from scratch, a completely new approach would be taken.
But generally speaking, if a company is still using Delphi, it's probably because they don't have the liquidity to actually re-write their code base.
> I don't believe a framework could replace our implementation.
It's pretty easy to use as much or as little of mORMot as you like. I use it for its webserver and websocket implementation but I don't, for example, use its database layer (using FireDAC in preference).
Indy is problematic there are other (commercial quality) http libraries around. Indy works and has source available and has a great set of maintainers but it's quality is variable.
There are some great sets of component libraries around though - tmssoftware and devexpress are very good, and of course you can always use c.
Thank you for the information, as we do use some TMS components. I suppose it was just natural for us to simply pick Indy, but perhaps looking into commercial ones might be something to consider. Although, at this point, we have worked around most of Indy's quirks, so it may not be viable later.
This is the one that I'd probably investigate seriously apart from indy for any comms http://www.nsoftware.com/platforms/delphi/. I looked at it many years ago and it seems the best supported.
It does, but you still need to manually declare all the types and functions. And then, since it's C, you also have to deal with low-level stuff like memory management for strings and other buffers.
Whereas someone working with, say, C# or Java, can just go and find a library that's native to their language, ready to use out of the box (even if internally it wraps that very same C library).
It's the usual curse of a small ecosystem. Things were different back when Delphi was popular.
Oh. I used SWIG to automate a lot of that. It'll build the wrappers for you. The upside with it is that you don't have to wait for package maintainers to update your bindings.
That was always my biggest disappointment with Delphi. Things that were simple, free, and of very high quality in other languages would lead you into a thicket of shady, low quality nagware VCL components that had a tangle restrictions on use and usually a magic DLL blob you were then forced to distribute along with your app.
It was a constant infuriating disappointment. Delphi should have been so much more.
I find that just the default component library of Delphi vastly exceeds what you get these days, for instance in Android or IOS, or (shudder) on the web.
If anyone using Delphi to build big apps in early 90s was told that to do the same function in 25 years time they would need HTML, CSS, JS, Ruby or PHP or similar, some SQL, some Rust or Go and probably a few DSLs - it would take months longer to build - require multiple servers - and would need more test code than app code to get it 98% as stable - you wouldn't have believed a word of it.
Every single time I have to use a grid control online I shake my head.
I strongly suspect the generation after this will rediscover the power of desktop apps and some of the dev tools that were around at that time. Web interfaces just don't work efficiently for some roles - especially in enterprise environments.
You're still using Rust / Go ? I've been using Luna on the Rocket stack, with Huston for distribution and Apollo for stack management, and it fixes mostly all the problems you've mentioned.
Just make sure to avoid Apollo release nr. 13 as it is rumoured to contain a nasty bug. Something with some storage method causing it to blow up I think it was.
You're wasting your time with Luna? I'm using stackless Albus, and use ADD (anticipatory driven development). It eliminates all config and perf issues with the Rocket stack, and leaves me time to contribute to the Satori project.
>I strongly suspect the generation after this will rediscover the power of desktop apps and some of the dev tools that were around at that time.
The biggest thing desktop apps are missing was the delivery mechanism. With web apps:
* a new user is just a hyperlink away
* pushing app updates is a page reload
* server-side state eliminates all of the migration headaches for client-based state
People are fickle and they will decide not to use a service if it takes a couple of seconds to load. When you require them to download an app and install it, you've already eliminated two major categories of users: impatient users, and users who don't know how to (or aren't allowed to) install applications.
yes this was always the reason given for not using Delphi instead of making a web app in every enterprise I worked at. Every time I said "hey how about we do this in Delphi, we'll have it finished in a couple of weeks" the argument was "but we'll have to put it through the windows guys and get a package made and distribute it to the users", so we made a web app. a couple of hundred grand later we had a web app, it wasn't as good as what the Delphi one would have been, it was slower, less features, but hey our 20 users didn't need to download it. lmao, I was paid by the hour.
I personally suspect that actually, Henry Spencer's famous prediction is more likely what's looming around the corner.
You just wait - there will be a terminal emulator written with webassembly+Canvas eventually. Perhaps powered by the already existing Emscripten port of Linux.
The problem with using the canvas functionality for everything is that it's an all-or-nothing proposition, and you end up having to write a lot of stuff that is already handled by the browser, or can only be handled by the browser (think bi-directional text/NLS issues).
I don't think that's a problem, personally. Something like canvas should be an all-or-nothing proposition. There's very little overlap between what you need for content-based static web pages and applications that just happen to run on the web.
The problem is canvas wasn't designed to be that all-or-nothing alternative to the DOM. It was designed as an alternative to the flash player for html5 games. As a result, it lacks several features that are needed to display generic content, the most prominent of these features being proper (and easy!) font rendering.
I suppose you could build your own advanced font rendering engine (I think Flipboard did exactly that), but that's more work and risk than most companies or even individuals are prepared to take these days. And you are right; creating your own would cause you to re-create a lot of stuff that's already handled by the browser, like font highlighting, copy/paste, etc.
I write enterprise apps almost exclusively in Ruby and a very small amount of SQL and HTML, but I'm guessing Delphi doesn't have some magical fairy dust that makes SQL unnecessary.
If you told me your stack is as you described, I'd say there's either some serious overengineering going on where you work, or you're solving a very different problem that would have been very complicated even in the Delphi world.
I think you're also vastly underestimating the operational work involved in deploying, maintaining, and syncing thousands of desktop apps in this type of environment. I'm personally happy I only have to get my software running on a couple nodes both with the exact same configuration.
Delphi used drag and drop and property setting to do most of what you'd do in Rails. Whether it's validation, master-details views, specifying display formats to represent decimal formats as currencies, specify the correct editing control for a database column - all specified as properties on the components representing the connection to the database.
You'd then be able to drag and drop columns from the list onto a form, and it would create the correct components depending on type, with appropriate labels, etc. Similarly, drop a grid on a form and get type-aware in-cell editing. Automatic updating of a details view when navigating through a parent data set. Etc.
One of the nicest things about Delphi was that you could compile into a single executable that you could deploy without further dependencies. One of selling points of Go, 20 years ago.
Same with when we developed oracle forms apps in late 90s or to a lesser extend VB. So much slower and more complicated to produce something simple which works for 90% of cases for business apps.
- empty form will have 24+16 lines of code in 2 files
- you will have to pay 3000 per seat per 6 months to make a website
- it only works on windows
- hello world have full access to all user's data
- you paid 3000 and it still cannot reliably add main icon to your app (XE6)
- you cannot increment build number from command line
- no job posting in last 12 months
- nobody is using it
> you paid 3000 and it still cannot reliably add main icon to your app (XE6)
You just gave me a humongous rush of nostalgia from when I was 12 and always had Resource Hacker open to make my apps look "professional" on every compilation. Thank you.
For hobbyists and those on a budget, there's always Lazarus/Free Pascal.
3) Not true, unless you're talking about the IDE. However, there are all sorts of Object Pascal IDEs such as Lazarus (cross-platform IDE) and Oxygene (uses Visual Studio) that can use the same/similar Object Pascal code.
4) I'm not even sure what you're talking about here. Privileges under Windows, etc. has nothing to do with Delphi specifically.
5) Also not sure what you're describing here. You can add an icon to your application pretty easily via the Project Options dialog. One of our best-selling products is developed in XE6, and we don't have any issues with the application icon.
6) This is a build system issue. Most build systems handle version info/manifest generation without issue.
7) Zero ? I think that's pretty easy to disprove.
8) Definitely not true. If what you say is true, then we wouldn't be in business. There are still a lot of companies making a lot of money using Delphi, primarily because they didn't spend a better part of the 00's trying to rewrite their flagship application(s) in C#, just for kicks.
Having said all that, yes Delphi is definitely not in the same position it was in the early 00's, but it didn't all of a sudden get a crappier compiler or component library. If you invested in Delphi then for your business, then your applications could still be compiled today on Windows 10 without major issues or re-writes. It's hard to quantify that kind of value, but it's still important. It's the same reason why so many businesses stick with Windows - there's a lot of value in being able to run applications that are a decade old on newer versions of the OS.
The fact of the matter is that there are only two major options for writing LOB Windows applications fast today: Delphi and C#. Anything else isn't going to be anywhere near as productive. And, if you're writing applications that need to be distributed to a lot of seats and work on every version of Windows from the past decade, then using .NET is going to be somewhat problematic.
There is a lot of legacy Delphi code out there. I make a good living by supporting some companies. And they have no intention at all to replace / rebuild any of it because that will be much more expensive. As is often with legacy code.
I guess the RAD market vanished with Rails and its competitors.
Back in 1998 - suddenly - it was possible to develop quickly a web application with a CRUD web scaffold behind to start feeding data.
The problem we have now we is the need to maintain loads of dependencies and libraries nobody knows who's in charge its development: they're just "popular" and have some documentation.
While I don't necessarily want a Delphi-like thing for Web development, I do want a Delphi-like thing for developing GUI desktop applications.
So far I've tried out a few things, but for some reason they don't "feel" the same as Delphi did. Maybe it's because I'm older and have moved on to different tools, or maybe it's because I haven't made the time to properly invest in these.
Anyways, here's what I've played with:
- NetBeans - Has a form builder, I'm comfortable with Java, it's cross-platform enough. I'm not sure why I've never used it for my personal GUI apps, even though I've built a bunch of little things to use for work.
- SharpDevelop - Looks great, checks all the boxes for doing GUI development, but I'm not comfortable enough with C# or VB.NET to use it effectively.
- Lazarus - Currently playing with this now. Feels a lot like Delphi (as it should!). I'm disappointed in how much Object Pascal/Delphi I've forgotten though. It brings back a lot of good memories though.
I'm a little embarrassed to admit it, but just today I was thinking about how I miss Visual Basic 6... Such a great IDE for slapping together a crummy GUI with buttons, textboxes and labels all slightly misaligned :) I'd love to have something similar for Python.
I miss VB6 at times (the tooling - not so much the language) as well. It was so simple to create a functional Windows application as compared to writing a web application to do the same thing.
Have you tried Xojo (used to be called REALbasic)? It's the closest I've found to Delphi, especially in that it builds & deploys really easily (eg no Java runtime required, feels native, never feel like I'm fighting with the compiler and my tool-chain).
I haven't played enough with Lazarus to see how they compare though, it looked promising too.
I think the primary downside people find with QT is the language support. People want cross-platform, native UI (i.e. not GTK) in a statically typed language higher level than C++. Even Go versions require a long compile time and don't work w/ the msvc toolchain and (IIRC) QT quick and QML are a bit hamstrung if you want to do advanced things with controls.
I would love full QT with a modern, high-level static language that is not hobbled on Windows. .Net may be the first to get there with a quality cross platform UI (Mono's WinForms are a bit hobbled too).
There is an inherent "HOLY SH*T" moment that happens to all desktop developers when they transition to Web. You are used to one type of interaction when doing native that is pretty simple and straight forward.
The real killer is the move to asynchronous development for everything. In Delphi (and C# desktop), most calls can be made synchronously be default, and simply. No so in the web (yes, you can do synchronous web calls...but you shouldn't). And that is ignoring the whole statically-type-and-compiled language to JavaScript issue. And then dealing with a huge array of libraries, patterns, and best practices that are completely unknown.
Then comes out "why can't this be simple like what I was used to?" Actually, what you were doing wasn't simple at all, you were just used to it. You understood the complexity, so it seems simple. Web development also becomes simple once you understand it. But first you have to be willing to learn again.
We're releasing version 2.06 shortly, and it has much-improved designer drawing performance and design-time/run-time layout performance. The layout performance improvements greatly improve the initial load performance.
The Delphi RAD model of development is actually perfect for single-page web applications because you're inherently only writing one layer of the application, the UI.
I had a quick look and decided to try the audio player. The volume control isn't draggable. Also, I was a bit baffled at the framework's decision to inline the page font, which is unlikely to change.
It looks like you're using your own HTTP server solution which doesn't seem to have caching, so all content is being redownloaded each visit. ETags and Last-Modified are very easy to implement, FWIW. (Note: I say that from the standpoint of reassurance, not insult!)
This seems kind of interesting, but my immediate concerns are interoperability with plain JS and how rapidly blocking issues are resolved since this isn't open source.
I'm very curious to see what HN would make of this system; have you ever posted it? Maybe that could be considered after the TreeView component and a TodoMVC example were available.
Note that I'm not dissing this at all. It's clear to me that this has a niche of people that are very happy and productive using this because it lets them reuse knowledge they gained years ago. (I've looked at Pascal a bit, but never really played with it. Lazarus is somewhere on my todo list, just to get a feel for things.)
Thanks for the feedback, it is always appreciated.
I'll take these one at a time:
1) The "volume control" is a cheat - I created that demo and used a progress bar instead of an actual draggable horizontal gauge (not available).
2) The font is the icon font (a trimmed-down version of Font Awesome) used for the icons in the applications. It's the preferred way of doing vector icons in Elevate Web Builder, at least for now, but you also have the option of turning off both embedding of the icon font and whether the icon font is included at all (both are compiler options). In general, Elevate Web Builder always tries to keep the number of requests required to load the application to a minimum, hence the very aggressive in-lining of everything.
3) The If-Modified problem is a bug, and a really embarrassing one at that (I'm installing a fixed server this afternoon). There's a millisecond file timestamp comparison issue that is causing the If-Modified to never kick in. The web server that we provide is just a "nice to have" thing because it automatically handles the database JSON API for loading datasets and consuming transactions, so that's how it's typically used, with less usage for static resources. Larger customers typically implement their own back-end database handling for IIS, Apache, etc. It's pretty easy to implement and the JSON API is very simple.
4) In terms of interoperability with JS, you can include external JS source with any project and it will get deployed with the project. After that, you also need an external interface to the JS code so that the compiler knows how to resolve any of the JS symbols:
5) As for issues and how they are resolved: we're pretty responsive regarding support/bugs, but Elevate Web Builder includes source code to the entire run-time and component library, so you're free to modify most of the product and we're able to give immediate hot fixes for most issues (~90% of issues/bugs are in this code and not in the IDE/compiler). In fact, you could take the command-line compiler that we separately provide and use it to create your own Object Pascal <--> JS IDE/product.
6) We've mentioned the product here before and it's received mixed reactions. It is, without a doubt, an odd product for most developers coming from traditional web development. :-) There are a lot of design choices that go against what one would recommend when hand-coding an HTML/JS/CSS application, but work beautifully when you're talking about a compiler doing the work for you. The main point of the product is to capture the productivity that Delphi provided in the desktop arena and bring it to web applications. This means an intense focus on performance, reducing dependencies and deployment issues, and ensuring that one can concentrate on the business task at hand.
Here is a "Hello World" in Elevate Web Builder:
a) Select File/New Project from the main menu.
b) Drop a button on the main form.
c) Double-click the button and type in:
ShowMessage('Hello World');
d) Hit F9 to run the application.
You've now created a web application that shows a modal dialog with "Hello World" when you click on the button, and it will run on any modern browser (>= IE9), including mobile. Contrast that with the setup/coding involved to get any sort of hand-coded web application up and running. You can see how this works in more detail here:
If you download a trial version, you can get a feel for the technology in the product by looking at the WebUI unit (WebUI.wbs). It's a ~13k-line UI layer that implements both the design-time external interface and a run-time virtual DOM that allows for very fast performance due to its BeginUpdate..EndUpdate reference-counted update cycle functionality. The run-time avoids interrogating or touching the DOM like it has the plague. ;-) It will also show how the animation primitives work, along with how the control interfaces are implemented. The control interfaces allow you to selectively skin controls on a per-control, per-project basis, with on-demand loading of the customized skins for each project at design-time.
> 1) The "volume control" (...) used a progress bar instead of an actual draggable horizontal gauge (not available).
Ah, that's the name of what I was looking for. I think HTML5 sliders can be styled similarly to how the volume control looks, but I understand you're targeting a wide variety of Web browsers here.
The reason I mentioned it was because I'm used to being able to drag volume controls directly - I'm not used to them being output-only. I guess I was deliberately looking for cracks in the design, to be honest :)
> 2) (...) [Y]ou also have the option of turning off both embedding of the icon font and whether the icon font is included at all (both are compiler options). In general, Elevate Web Builder always tries to keep the number of requests required to load the application to a minimum, hence the very aggressive in-lining of everything.
Oh, loading as a separate resource is is available as an option. Cool.
While somewhat unintuitive, I have indeed learned that fewer bigger requests can load quicker than many small requests - which does makes sense, I guess obsessing about caching isn't everything. (https://news.ycombinator.com/item?id=13601451 / https://danluu.com/web-bloat/ - particularly the 3G bits, since lots of people tether)
> 3) The If-Modified problem is a bug, and a really embarrassing one at that (I'm installing a fixed server this afternoon). There's a millisecond file timestamp comparison issue that is causing the If-Modified to never kick in.
Ah, I see. Comparison between 1488416112 and 1488416112.336420126? Completely understandable.
> The web server that we provide is just a "nice to have" thing because it automatically handles the database JSON API for loading datasets and consuming transactions, so that's how it's typically used, with less usage for static resources.
Ah, I see, that's the app server.
> Larger customers typically implement their own back-end database handling for IIS, Apache, etc. It's pretty easy to implement and the JSON API is very simple.
That makes perfect sense.
> 4) In terms of interoperability with JS, you can include external JS source with any project and it will get deployed with the project. After that, you also need an external interface to the JS code so that the compiler knows how to resolve any of the JS symbols: (...)
Oh, nice! So you do have interop. That makes quite a lot more possible.
Now I'm wondering whether your UI architecture is abstracted enough that end-users could build UI components out of JS... hmm, that probably wouldn't work, the UI designer wouldn't be able to control them. (I'm guessing you can design your own controls in Pascal?)
> 5) As for issues and how they are resolved: we're pretty responsive regarding support/bugs, but Elevate Web Builder includes source code to the entire run-time and component library, so you're free to modify most of the product and we're able to give immediate hot fixes for most issues (~90% of issues/bugs are in this code and not in the IDE/compiler). In fact, you could take the command-line compiler that we separately provide and use it to create your own Object Pascal <--> JS IDE/product.
That's a great development model, and one I've considered myself (providing source to a large portion of the codebase to accelerate urgent fixes).
I was wondering how the Pascal bit worked for a while there. I'm curious if you pulled in another language implementation or built your own; I'm guessing you went full crazy and made your own implementation, considering you compile to JavaScript? :) (not sure though, Wikipedia mentions that Smart Mobile Studio have a JS-targeting implementation)
> 6) We've mentioned the product here before and it's received mixed reactions. It is, without a doubt, an odd product for most developers coming from traditional web development. :-)
Yep. I can see the niche for this though. Plus, diverging from the mainstream means you get to neatly sidestep the frenetic insanity associated with the cutting edge, which can be really really nice if you find something that pays well. :) (Still looking for my own one of that)
> There are a lot of design choices that go against what one would recommend when hand-coding an HTML/JS/CSS application, but work beautifully when you're talking about a compiler doing the work for you.
Unfortunately modern Web development has gotten so caught up with layers and layers of tooling and compilation, even hand-coded apps are beginning to resemble sprawling enterprise apps. :/
But you make a good point.
> The main point of the product is to capture the productivity that Delphi provided in the desktop arena and bring it to web applications. This means an intense focus on performance, reducing dependencies and deployment issues, and ensuring that one can concentrate on the business task at hand.
Yeah.
> Here is a "Hello World" in Elevate Web Builder:
> (...)
> Contrast that with the setup/coding involved to get any sort of hand-coded web application up and running. You can see how this works in more detail here: (...)
Before I watched the video I was half-scared this was a slightly more built-out Pascal-based iteration of the old BAT2EXE "batch compilers" that could never do anything. My apologies :)
I can now see this is essentially a GUI builder connected to a Pascal>JS transpiler. That's really cool.
And yeah, this is much quicker than finding a grid display library that actually works, building an efficient data model to load data into it, handling network issues... hides under box
> If you download a trial version, you can get a feel for the technology in the product by looking at the WebUI unit (WebUI.wbs).
With signing up... really like the "Real name" vs "Displayed name" vs "User ID" distinction! Hm, idea: <label>s for the input fields on the new user form... oh, and what's the automatic signup rate with your current captcha?... ahh, consider NOT sending the user password back through failed forms... definitely definitely consider HTTPS for at least the signup form (!!!)... and maybe redirect the user to the page they were on when they clicked the signup link. The site design is very nice though.
(Regarding the captcha system, you have me confused and very curious. Are you hashing the current time, or adding hash codes to a DB...? The PNG URL has no parameters in it! :P)
> It's a ~13k-line UI layer that implements both the design-time external interface and a run-time virtual DOM that allows for very fast performance due to its BeginUpdate..EndUpdate reference-counted update cycle functionality. The run-time avoids interrogating or touching the DOM like it has the plague. ;-)
It could be very fun to pit your virtual DOM against React's. :D
I wouldn't be surprised at all if yours won out - I think React tries to "guess" by itself when to push its virtual DOM to the screen, and it constantly gets it wrong of course. A reference-counted approach with "don't update for a minute" boundaries sounds very simple and elegant. So I'm serious, benchmarking your system against React's could be quite interesting; but the problem would of course be in finding React-based controls to compare against.
Also, Pascal doesn't actually look that bad. I've been meaning to get around to having at least a passing knowledge of it for a while...
> It will also show how the animation primitives work
Ah, the world of HTML4.999999999999
> along with how the control interfaces are implemented. The control interfaces allow you to selectively skin controls on a per-control, per-project basis, with on-demand loading of the customized skins for each project at design-time.
Huh, very nice. That's really cool.
---
I thought I'd mention: the designer itself seems to actually work in Wine (in that it didn't crash on me, and is in fact running in another virtual desktop right now), but I got an error message that the web server failed to bind. Happy to do further digging if you like.
Also, shift+scroll doesn't scroll horizontally in the designer. Something I've gotten used to from Chrome, thought I'd mention it.
---
I was also curious: have you ever considered pitching this for mobile UI development? With a pixel-perfect grid-based system like this (that does admittedly offer some very impressive snapping options) the only way would be to create mobile-specific forms - but such an approach could potentially work quite well. The only other thing I can think of would be (re)designing controls that play nice with primarily touch-based environments, and implementing views with slide animations and such. I don't think this would be a doomed idea, I'm guessing you've already thought about it.
> While somewhat unintuitive, I have indeed learned that fewer bigger requests can load quicker than many small requests - which does makes sense, I guess obsessing about caching isn't everything. (https://news.ycombinator.com/item?id=13601451 / https://danluu.com/web-bloat/ - particularly the 3G bits, since lots of people tether)
There are some valid points to be made about bloat, and Elevate Web Builder's monolithic applications do tend to be on the larger side. However, the big issue is always perceived load time, and that's what we always work on improving first. The size of the application itself only really matters on the first load after a change/re-compile/re-deploy, provided that you don't have a bug in your web server that complete negates this performance improvement. ;-)
> Ah, I see, that's the app server.
Yeah, and it's going to be getting some attention before summer, specifically with GZip and SSL support. The general idea is that (eventually) we're going to be adding the Object Pascal run-time engine that is currently used in the IDE at design-time to the web server, thus offering the same language for the entire stack. When you work with controls/components in the designers in the IDE, the run-time actually executes code from the component library, which is why scrollbars work and you can click on buttons in controls to add new sub-controls, etc. It's nice for a control/component developer because they only need to set a simple flag that indicates that they want design-time events for a given control, and the IDE/component library takes care of the rest.
> Now I'm wondering whether your UI architecture is abstracted enough that end-users could build UI components out of JS... hmm, that probably wouldn't work, the UI designer wouldn't be able to control them. (I'm guessing you can design your own controls in Pascal?)
That's a very astute observation, and 100% correct. :-) The easiest way to use external JS controls in Elevate Web Builder is to use a TBrowser control, which is simply an iframe control that will isolate the control from the "normal" UI controls. However, it's also very easy to just create a wrapper control in Object Pascal that interfaces with the JS, which is what we did with the TMap control for Google Maps support.
The whole IDE is designed around the idea of creating and installing your own controls/components, just like in Delphi. And, more importantly, it is a lot easier because there are simple UI element building blocks (in the virtual DOM) to use for building up controls, with the UI elements doing all of the heavy lifting and modifications being simple property changes/method calls.
> That's a great development model, and one I've considered myself (providing source to a large portion of the codebase to accelerate urgent fixes).
It's pretty much been the "Delphi" way of doing things since it was first created and sold by Borland, so we can't really take credit for it. It' funny, though, because it pre-dates open source. I never used Turbo Pascal, but I think it did something similar, and it really pre-dates open source.
> I was wondering how the Pascal bit worked for a while there. I'm curious if you pulled in another language implementation or built your own; I'm guessing you went full crazy and made your own implementation, considering you compile to JavaScript? :) (not sure though, Wikipedia mentions that Smart Mobile Studio have a JS-targeting implementation)
We had some experience doing an interpreter in our SQL implementations for our database engine products, so it was a natural move for us. The most difficult portion was building the run-time execution engine, mentioned above.
>> While somewhat unintuitive, I have indeed learned that fewer bigger requests can load quicker (...)
> There are some valid points to be made about bloat, and Elevate Web Builder's monolithic applications do tend to be on the larger side. However, the big issue is always perceived load time, and that's what we always work on improving first.
Totally makes sense. Taking bandwidth into account too is important, but yeah, user perception... :)
> The size of the application itself only really matters on the first load after a change/re-compile/re-deploy, provided that you don't have a bug in your web server that complete negates this performance improvement. ;-)
Cool view :)
There's also the fact that browser caching can be terribly broken: I unfortunately can't find it right now but I read somewhere of how a dev found Safari on their iPhone was only caching a few KB (!!!!) of Web content. Obviously something was broken somewhere (maybe Safari used a disasterously incorrect percentage-of-free-space calculation) but yeah. I have to admit that I'm considering hand-rolled ServiceWorker-backed caching systems myself; the only infuriating question is where to actually store the data (ref http://stackoverflow.com/q/42288596/3229684).
>> Ah, I see, that's the app server.
> Yeah, and it's going to be getting some attention before summer, specifically with GZip and SSL support.
Nice!
> The general idea is that (eventually) we're going to be adding the Object Pascal run-time engine that is currently used in the IDE at design-time to the web server, thus offering the same language for the entire stack.
Oh coool.
> When you work with controls/components in the designers in the IDE, the run-time actually executes code from the component library, which is why scrollbars work and you can click on buttons in controls to add new sub-controls, etc. It's nice for a control/component developer because they only need to set a simple flag that indicates that they want design-time events for a given control, and the IDE/component library takes care of the rest.
I noticed that from the video! Really cool feature.
>> Now I'm wondering whether your UI architecture is abstracted enough that end-users could build UI components out of JS... hmm, that probably wouldn't work, the UI designer wouldn't be able to control them. (I'm guessing you can design your own controls in Pascal?)
> That's a very astute observation, and 100% correct. :-) The easiest way to use external JS controls in Elevate Web Builder is to use a TBrowser control, which is simply an iframe control that will isolate the control from the "normal" UI controls.
Oh, of course....
> However, it's also very easy to just create a wrapper control in Object Pascal that interfaces with the JS, which is what we did with the TMap control for Google Maps support.
It might be a very interesting idea to create wrappers for popular libraries. I'm not quite sure which libraries to support, but "look at this island written in Pascal" is suddenly very interesting when you go "and here's the dead-simple interop to this bunch of other things you already know".
> The whole IDE is designed around the idea of creating and installing your own controls/components, just like in Delphi. And, more importantly, it is a lot easier because there are simple UI element building blocks (in the virtual DOM) to use for building up controls, with the UI elements doing all of the heavy lifting and modifications being simple property changes/method calls.
I have to admit that I really like the visual design way of doing things. I played with Visual Basic just under a decade ago but I'm glad I moved on from it as it didn't impose enough architectural structure. I poked Lazarus recentlyish; it's on the todo list. :P (especially considering its Linux support)
>> (...) (providing source to a large portion of the codebase to accelerate urgent fixes).
> It's pretty much been the "Delphi" way of doing things since it was first created and sold by Borland, so we can't really take credit for it.
Ah, interesting!
> It' funny, though, because it pre-dates open source. I never used Turbo Pascal, but I think it did something similar, and it really pre-dates open source.
"Shared source"?
>> I was wondering how the Pascal bit worked for a while there. (...)
> We had some experience doing an interpreter in our SQL implementations for our database engine products, so it was a natural move for us. The most difficult portion was building the run-time execution engine, mentioned above.*
I think you're referring to WebUI.wbs...? 13k LOC (5448 without {...} blocks, 6076 with {$IF}s, apparently) is pretty crazy, yeah.
These are backwards, I forgot that HN posts the latest comment first. :-)
> Yep. I can see the niche for this though. Plus, diverging from the mainstream means you get to neatly sidestep the frenetic insanity associated with the cutting edge, which can be really really nice if you find something that pays well. :) (Still looking for my own one of that)
It's doing pretty well, and we're slowly but surely building up a decent customer base. Plus, we're a very small company, so we don't need much revenue.
> With signing up... really like the "Real name" vs "Displayed name" vs "User ID" distinction! Hm, idea: <label>s for the input fields on the new user form... oh, and what's the automatic signup rate with your current captcha?... ahh, consider NOT sending the user password back through failed forms... definitely definitely consider HTTPS for at least the signup form (!!!)... and maybe redirect the user to the page they were on when they clicked the signup link. The site design is very nice though.
Yeah, try to ignore the web site issues for now. It's a little dated, and is about a decade old now. We're going to be "dog-fooding" the whole thing with Elevate Web Builder, once the web server is updated to include the Object Pascal run-time and the GZip/SSL support is added. It will make a good example that customers can use to build their own sites, etc. It will be a mix of back-end-generated pages with mini Elevate Web Builder apps for various sections that now use plain HTML forms. Having said that, we're going to move the logins on to HTTPS sooner than that.
> (Regarding the captcha system, you have me confused and very curious. Are you hashing the current time, or adding hash codes to a DB...? The PNG URL has no parameters in it! :P)
Yes, it's performing some machinations on the time to generate the code. Essentially the code/PNG is stored and then deleted after it has been used. Again, not our finest work, but we don't have too many people trying that hard to sign up on the web site with robots. :-)
> I wouldn't be surprised at all if yours won out - I think React tries to "guess" by itself when to push its virtual DOM to the screen, and it constantly gets it wrong of course. A reference-counted approach with "don't update for a minute" boundaries sounds very simple and elegant. So I'm serious, benchmarking your system against React's could be quite interesting; but the problem would of course be in finding React-based controls to compare against.
I've also wondered the same. Besides what you point out, my concern with React is that it might stress the GC too much, but that's based upon my limited understanding of how its diffing algorithm generates what it needs to update the DOM. In contrast, Elevate Web Builder only needs to track a simple change set per UI element and enforce one simple rule: no UI element will actually apply its DOM updates until all parent elements are no longer being updated. The initial application load results in only one pass of DOM updates because there is a BeginUpdate..EndUpdate block around the application "surface" (body element) during the application load. And, more importantly, elements are created once and stay created.
Elevate Web Builder 2.06 actually adds some more optimizations in this regard, including the concept of "local change blocks" whereby layout and measurement are delayed until the EndUpdate call (where UpdateCount=0) on a per-element basis without taking into account the parent update status. This provides a much-needed reduction in how many calls are necessary to compute the width/height of UI elements that are auto-sized. The measurement functionality touches the DOM (off-screen, but still part of the DOM), hence it's very slow. So, the general design is that local updates control when layout/measurement occurs (there's also a method to force this), and global updates (including parent update status) control when DOM updates are applied.
> Also, Pascal doesn't actually look that bad. I've been meaning to get around to having at least a passing knowledge of it for a while...
It's actually quite a nice language, although the Elevate Web Builder variant is a little more restricted than Delphi, due to some of the limitations of JS. We've written database engines, ODBC drivers, PHP extensions, web servers, general applications and libraries, and an IDE/compiler using it, so it's pretty versatile. More importantly, it has GUI options on the desktop, which is where a lot of languages fall down. It is often the case that "just use an embedded browser" is not a viable solution for a professional application, and then you're stuck using some tacked-on GUI toolkit that may or may not work particularly well with your language.
> Ah, the world of HTML4.999999999999
:-)
> I thought I'd mention: the designer itself seems to actually work in Wine (in that it didn't crash on me, and is in fact running in another virtual desktop right now), but I got an error message that the web server failed to bind. Happy to do further digging if you like.
It's probably just the binding to port 80, which is a bit naive, but can be changed pretty easily:
(if you want to follow up on this via email, you can contact us at support@elevatesoft.com)
> Also, shift+scroll doesn't scroll horizontally in the designer. Something I've gotten used to from Chrome, thought I'd mention it.
Thanks, I'll check that out and make sure that it's added.
> I was also curious: have you ever considered pitching this for mobile UI development? With a pixel-perfect grid-based system like this (that does admittedly offer some very impressive snapping options) the only way would be to create mobile-specific forms - but such an approach could potentially work quite well. The only other thing I can think of would be (re)designing controls that play nice with primarily touch-based environments, and implementing views with slide animations and such. I don't think this would be a doomed idea, I'm guessing you've already thought about it.
We also target mobile, fully support touch, and there are a lot of responsive flow options in the layout functionality, but yes, it's normally best to create separate mobile/desktop versions simply so that one can take advantage of the unique functionality on each platform. This isn't as bad as it sounds, however, because one can easily share units between projects, including database units that include database model functionality. There are also simple method calls for aggregate animation operations such as sliding:
> These are backwards, I forgot that HN posts the latest comment first. :-)
Ah, the 10k character limit. Heheh. Thanks again for replying!
In HN's case, it's because Arc sorts all comments with the same score chronologically... so I upvoted your first post. :)
Incidentally, Reddit's PM system happens to produce the same results too. Unfortunately due to post weight fuzzing the only way to keep things in consistent order is to make a tree of replies, or clearly mark "i of n" etc. Anyway.
> It's doing pretty well, and we're slowly but surely building up a decent customer base. Plus, we're a very small company, so we don't need much revenue.
(Very) small companies FTW.
> Yeah, try to ignore the web site issues for now. It's a little dated, and is about a decade old now. We're going to be "dog-fooding" the whole thing with Elevate Web Builder, once the web server is updated to include the Object Pascal run-time and the GZip/SSL support is added. It will make a good example that customers can use to build their own sites, etc. It will be a mix of back-end-generated pages with mini Elevate Web Builder apps for various sections that now use plain HTML forms. Having said that, we're going to move the logins on to HTTPS sooner than that.
Nice! I see.
>> (Regarding the captcha system, (...))
> Yes, it's performing some machinations on the time to generate the code. Essentially the code/PNG is stored and then deleted after it has been used. Again, not our finest work, but we don't have too many people trying that hard to sign up on the web site with robots. :-)
Oooh, I see. That's a nice and simple approach! I must admit my own thinking with captchas was something along the lines of "probably needs to be a Rube Goldberg machine, preferably one built out of kitchen sinks - that should make it secure enough"... I must admit I didn't quite think through simpler approaches like this (probably due to all the captcha fails I've come across, although I can't relocate the one I was thinking of right now).
>> I wouldn't be surprised at all if yours won out (...)
> I've also wondered the same. Besides what you point out, my concern with React is that it might stress the GC too much, but that's based upon my limited understanding of how its diffing algorithm generates what it needs to update the DOM.
FWIW, imgur is nigh unusable on my old ThinkPad T43 (if not for the Imagus image preview extension I {c,w}ouldn't use it). So yeah.
> In contrast, Elevate Web Builder only needs to track a simple change set per UI element and enforce one simple rule: no UI element will actually apply its DOM updates until all parent elements are no longer being updated.
Oh that's what you mean by reference counted... yup, that's a far simpler approach.
> The initial application load results in only one pass of DOM updates because there is a BeginUpdate..EndUpdate block around the application "surface" (body element) during the application load.
Nice :D
> And, more importantly, elements are created once and stay created.
I've noticed that modifying large chunks of HTML can cause rather large glitches, whereas isolating changes to the elements in question is ridiculously fast, yeah.
> Elevate Web Builder 2.06 actually adds some more optimizations in this regard (...)
That is really cool. I wish more application frameworks focused this much on efficiency :(
>> Also, Pascal doesn't actually look that bad. (...)
> It's actually quite a nice language, although the Elevate Web Builder variant is a little more restricted than Delphi, due to some of the limitations of JS. We've written database engines, ODBC drivers, PHP extensions, web servers, general applications and libraries, and an IDE/compiler using it, so it's pretty versatile.
I see (wow). So it _is_ a transpiler. Now I'm wondering if it'll ever have options to optimize for ES2015, or obsessing over JS generation (ref https://news.ycombinator.com/item?id=13762787), or even compiling directly to WebAssembly...
(FWIW, wasm's interpreter architecture and bytecode set are already locked in and both Firefox and Chrome already have (disabled by default) support - everyone's just tossing up how (hopefully not "if"!) to talk to the DOM.)
> More importantly, it has GUI options on the desktop, which is where a lot of languages fall down. It is often the case that "just use an embedded browser" is not a viable solution for a professional application, and then you're stuck using some tacked-on GUI toolkit that may or may not work particularly well with your language.
Yep, and this gets you Pascal->HTML. Makes a lot of sense.
>> Ah, the world of HTML4.999999999999
> :-)
The day HTML interpreters reach parity will likely be the day we're all using something else :(
>> (...) the web server failed to bind.
> It's probably just the binding to port 80 (...)
OH, of course, you can't bind to ports <1024. Yup, that fixed it. One question though: I was playing with the stop/start server buttons and couldn't restart the server "because it was already listening". I suspect it might be a missing SO_REUSEADDR: https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
It's okay though, I just picked a different port.
And now I have a new problem: I'm seeing "Emitted C:\users\i336\My Documents\Elevate Web Builder 2\Projects\D:\project1.js (total size is 965998 bytes - not compressed)", which presumably isn't working. (Previous "is this what you wanted?"s included "C:\users\i336\My Documents\Elevate Web Builder 2\Projects\..\..\..\..\..\project1.js"!). I've emailed you in case you're interested :) (full disclosure: I'm just playing around with this, and I don't know any Delphi people, although EWB is of course filed away)
> Thanks, I'll check that out and make sure that it's added.
* 1024x768 sort-of-masterrace *
>> I was also curious: have you ever considered pitching this for mobile UI development? (...)
(PS. By "snapping options" I was trying to describe dynamic flow/resize, yep)
> We also target mobile, fully support touch, and there are a lot of responsive flow options in the layout functionality, but yes, it's normally best to create separate mobile/desktop versions simply so that one can take advantage of the unique functionality on each platform. (...)
Oh okay! Nice. (Although not targeting mobile is kind of crazy, so it makes sense...)
You have major open source libraries like GTK, wxWidgets, Qt.
Also .NET, Java which offer multiple ways of doing forms that are tied to the target platform.
In addition, RealBasic (now Xojo) and... Delphi.
After Borland, other companies continued working with Delphi, namely, Embarcadero
You mean after Borland destroyed themselves with a over-the-top business strategy Embarcadero could swoop in and buy several Borland assets and trademarks (Delphi, C++ Builder, Interbase) rather cheaply.
Most of the people I knew who worked with Delphi moved on to .NET and Visual Studio. Main reason being that working with Windows Forms or WPF and the .NET BCL in combination with C# is pretty similar to working with the VCL and Object Pascal. Common factor being Anders Hejlsberg [0]; one of the biggest drivers behind both the Delphi and .NET ecosystem.
I guess this is rather tangential, but I recently returned to professional web development and I'm finding a shocking amount of the work is either rewriting websites according to the whims of SEO consultants, or updating things to new releases when the old versions stop getting security updates. Neither of which are really issues for Delphi projects.
Well the bigger problem is it's (apparently) what the customer demands. The problem being that we, the old and better developers, didn't come up with a better solution than these kids.
Actually, that's not what customers demand. Customers demand a SOLUTION. IT managers demand less work and that's why web is so prevalent. IT teams just need to run a script to release version 2.0 of your application, being used by hundreds, thousands or millions of users.
- For fast drag and drop RAD style development use UNIGUI, great interfaces, plain and simple delphi development.
- If you want a modern, optimized and responsive Web UI in full javascript (but with typed and gentle Object Pascal), use "Smart Pascal Studio", it´s like typescript but includes a GUI editor, widgets, node.js backend etc. check out their full js desktop https://www.youtube.com/watch?v=ee_kXdueV_4&feature=youtu.be (impressive).
- If you want to bring your existing client-server delphi apps to the web, use Thinfinity.
- For a incredibly fast, low resource consumption, REST ready ORM, use MORMOT.
- For a nice, elegant and simple ORM use TMS Aurelius.
Please keep an eye in Smart Pascal Studio, it shares some ideas with Typescript but their tools are way ahead in development, they started some time before Typescript, it is a glimpse into the future of Web-desktop-mobile development.
Twenty years ago, I wrote an application for the taxation office to help businesses calculate payroll tax. It was written in Delphi for maximum portability, because it had to run on Windows 3.1x, 95 and NT and was distributed to 16,000 businesses on 3.5" diskettes. Talk about old school.
I'd love to hear what you think of Anvil (https://anvil.works) - it sounds like exactly what you're asking for.
It's a very Delphi-like (or VB-like) tool for building web apps: Drag and drop for visual layout, then write code with a simple object model behind it. (It's 2017, so Python rather than Pascal - but more similar than it is different. Also built-in git repo, a built-in database, code completion, integration with services like Google Drive/auth/mail, etc.) I'm a cofounder, so I'm interested to know whether it scratches your itch.
Thanks - yeah, there's a lot of optimisation still to do on load times. (We need some JS to let you write client-side code in Python, but we know we can load it a lot faster.)
I'm intrigued what smelt "overly engineered" to you, though. We're trying quite hard to keep the programming interface simple, so if something there offended you, that's good to know. (Or if it was another comment about load time, then...yeah. That just went up the bug tracker a bit.)
I mean the demo feels over-engineered. Create an account, activate account by email, and login... just to download a 1-page pdf. I understand that the point of the demo was to show the ability to create a working web-app, but a better demo would showcase something with more meat than a single file download. Perhaps a simple twitter clone with file attachments or something along those lines instead of a file download app that has no other functionality.
Aha! Yeah, that makes sense. It descends from a use case a consulting client had a while ago (for which they ended up with a $X0,000 Salesforce deployment instead of something I could build in an afternoon with Anvil, and in a few days without it). Clearly not an obviously accessible example - we'll fix that up a little :)
("Twitter clone with attachments" is one we use in workshops, actually - it fits neatly into a single session. Guess I should write that up.)
I recently had to write a desktop GUI app, and chose Electron[1] because I figured that for once I'd try something new and hip with lots of OSS libraries because it wasn't too critical and I needed to pass it on to someone else and figured there are lots of frontend web devs around. Well, it's kinda OK, but man, that thing is held together with spit and baling wire, and you feel like it's all going to come down with the slightest breeze. The previous GUI app I'd built was in Java/Swing, and while I wouldn't call the experience particularly pleasant, at least it felt solid.
What I mostly hate in webdev is exactly that, helding together with spit and baling wire, a pile of HTML tags meant for document publishing, CSS and JavaScript, while pretending the browser is a proper application VM.
Than switching browsers, including the same one but a different version, and start implementing workarounds. Multiplying this experience for each browser/version/OS required by the customer.
And it's not just web. I also used Julia in that project, and while the language itself is really awesome for numerics (especially as I had to migrate a lot of existing Matlab code, which is a pleasure with Julia), good luck trying to package a standalone app (especially if you're using native libraries). Oh, and the startup time? It's funny how some people complain about the JVM in that regard.
Every once in a while I try to pull my head out of the JVM world to try other stuff, see what else is out there, and people seem to be putting up with a lot of pain that's downright unacceptable with more established tech. I'm guessing people may be coming over from scripting languages where they're used to this stuff (and they may it jarring to work on the JVM). Even when things aren't that bad, like with NPM, they're miles behind the sturdiness of the Maven ecosystem (which is far from perfect in itself).
Oh, don't get me wrong -- Julia is a great language and I hope I get the chance to use it again. But its biggest issue right now isn't even the startup time, but the fact that you can't even write a self-contained application with it (well, you can, sometimes, and with great care).
>Julia is an interesting language for those of us that know Dylan.
Interesting. I had tried out Dylan briefly (in one of my occasional spells of trying out multiple new / different languages), but long ago - and at that time I did not understand it much, maybe due to knowing less about some of the advanced programming language features and their benefits than I do now. Can you elaborate a bit on Dylan's features and the connection with Julia?
It's at least better than it once was, heck everything is better with modern Javascript etc., transpiling from TypeScript, tooling or whatever. But yeah, the issues with the underpinnings is in my opinion still funny enough exactly as readily apparent as ever.
The only thing that pleasantly surprised me while working on that project was Typescript and its IDE support (vscode). Java is still easier overall, but given what they have to integrate with (untyped libraries and legacy code, separate type declaration files) it's pretty damn impressive.
I worked for a (casino) gaming company that thought electron would be appropriate for a production slot machine. I expressed serious doubts that JS was the right language for a graphics appliance, but I didnt want to take control of the situation. A few months later, there was memory fragmentation and leaks that nobody could figure out. That company went belly up shortly thereafter.
No source for bits of it which makes it risky since it seems there's only one guy developing it.
Looking at it's comms it seems pretty lightweight, though it does generate a lot of messages.
Last time I looked the Sencha library it used was fairly old
That said if you've got a low-medium weight web app you want to build and don't care if it looks like windows, then it's dead easy (really 1 day or so, it's that easy).
VirtualUI is another interesting way to have a remote web interface to a Win32 Delphi app. Not necessarily scalable to a large number of users but a nice option if it fits your requirements:
The release candidate works great however what ultimately turned us away from this product was the fact that they only offer source code for the client components, you don't actually ever get to see the source code for the server, which is a big nono.
At every Google IO they presented it, and yet the overall native support of all required features without any kind of polyfills is still missing across all browsers.
Because Ada compilers used to be targeted to the military, aviation and corporations with big pockets. Only in the last decade we saw the language getting an usable open source version thanks to the work of Ada Core and their contributions to GNAT.
All other surviving Ada compilers are commercial, following the same price practices as usual.
So many of us in the Pascal golden days were only able to buy Pascal compilers.
Just to put this in perspective, Turbo Pascal for Windows 1.5, the last TP version before Delphi was created, would be around 100 € on today's money. An Ada compiler would be at very least 5K €.
Also despite the famous "Why Pascal Is Not My Favorite Programming Language" assay from Brian Kernighan, the majority of Pascal compilers supported the UCSD, Apple and Borland extensions, so the actual Pascal dialect used by most of us was quite close to Ada83 in terms of features (minus generics).
In 2017, given the existance of GNAT, SPARK and updated Ada standards, Ada would be probably a better option.
This is one aspect of why the DOS/Windows ecosystem swamped away the old software industry. People who worked before windows don't seem to grasp this simple fact.
Tons of variations : Why wasn't UNIX used ? Why did dBase beat all the minicomputer and mainframe solutions ? Why weren't the free C compilers used by hobbyist programmers ? Why did nobody run X11 ?
The answer is this : because doing that cost unreasonable amounts of money.
Either they did so directly, or because necessary hardware cost boatloads. And that happened because of 2 effects : either because it only ran on one kind of architecture that was really, really expensive, or because it required ridiculous amounts of resources.
Simple is subjective. I find the React way of making web UIs, where you just write a `render` function, way simpler than manually mutating existing UI widgets to match the data every time it changes. Or some weird manual data binding via model wrappers.
Maybe it's a tiny bit more code in the very beginning, but it becomes worth it very soon (as soon as you get past hello world pretty much).
That being said, we could always have better tooling, even for this paradigm.
Maybe there's a similarity in how it worked under the hood, but the users of those APIs most definitely could not write UIs in that style.
In Win32 code, you still have persistent windows with child "windows" (UI controls/widgets) on them, that have UI-specific internal state (such as text, position, links to their own child windows, etc.) that is different and separate from your application's state (variables, data structures).
Then you have to manually mutate (SetWindowText, ListView_InsertItem, CreateWindowEx, DestroyWindow etc.) the UI when something in your application's data changes.
Unless you don't use any native UI controls and just draw everything manually I guess, but people generally didn't do that.
> In Win32 code, you still have persistent windows with child "windows" (UI controls/widgets) on them, that have UI-specific internal state (such as text, position, links to their own child windows, etc.) that is different and separate from your application's state (variables, data structures).
I don't get it. This is a property of every UI toolkit. In other words, this goes for the web as well. In the underlying structures, all data exists independently of your application.
If you mean that there's libraries for the web (angular 1) that make it easy to pretend this isn't true, that the contents of your variables are really on screen, similar libraries exist for windows apps as well. Hell, all of those database things like Access, in a way, have just this concept (the language/tooling pretends that the form field for field X IS field X, through bidirectional synchronization).
Also, except for windows 3.0 apps, nobody ever called things like SetWindowText themselves.
Persistence, and the lack of options to turn it off is one the of major pain points with the web as a platform. Even canvas is persistent, which makes no sense at all to me.
And for me at least, there's two huge differences. On windows, very big apps could work together and be open a dozen at a time. A dozen of single-page-app tabs will, on the other hand, slow my Xeon-backed chrome to a crawl. Secondly, I have never seen any webapps that approach the complexity of normal windows apps. The most complex web apps currently are things like Google Docs, and the average is something like a webform. How many years of the web platform do we need to conclude that it has found some way to prevent feature-full applications from being written ?
I've developed plenty of applications for both windows desktop and for the web, and it's pretty clear to me: the web enforces extremely complex methods of doing things. Markup, javascript, RPC (can be HTTP), other language, another data language is the default layer. Adding a single field to a single record type requires knowing HTML, JavaScript, HTTP (how to use HTTP and encode stuff in it), and then backend language (let's say Java), then SQL. ALL of them need to be modified to just modify a record type.
The web is extremely lacking in performance, and is far, far more complex than it needs to be.
Your talking about the difference between immediate mode vs retained mode, immediate mode being the "self contained render" method. This is nice and clean up to a point in complexity, and then the advantages of retained mode (or "manually mutating existing UI widgets to match the data every time it changes") outweigh the disadvantages, namely the management of the UI/data interface.
What are the advantages of retained mode UI (genuinely curious)?
Assuming you have good enough primitives to work with (i.e. you write your render function in terms of HTML elements and other React components - or something similar, not raw lines and rectangles), then I just don't see any.
That talks about game UIs, which are indeed much more difficult to work with, e.g.
>The GUI library consists of one-shot "RenderButton", "RenderLabel", "RenderTextBox"... functions
>all RenderXXX functions that have user interaction like a buttons or checkbox have return values that indicate whether e.g. the user clicked into the button.
But React is nothing like that.
Writing JSX very much resembles writing HTML, which makes the tree structure easy to read/write, you bind event handlers to elements (`onClick={this.helloClicked}`) just like you could with HTML, passing data (props) to child components is trivially simple etc.
That's why I wrote "assuming you have good enough primitives to work with" in my previous comment. With game UI libraries, you often don't, and often there are limitations in the language itself that prevent the libraries from being good enough.
When you have a nice environment to work with, all that retained mode does is duplicate the state - so you have your application data, plus the internal state of the UI component, or even the larger structure of the components - and it places the additional burden of keeping them in sync on your shoulders.
In short: because the web is inherently stateless and it's much harder to deal with than stateful UIs.
I last used Delphi back around the turn of the century, so I'm remembering it as a drag-and-drop Windows UI framework/builder. ASP.NET WebForms is the most similar thing I've used (and it's been at least 5 or 6 years since I last really used it). I would not recommend investing a lot of time in it.
WebForms is great when you are starting. It is drag-and-drop, with 'controls' like text boxes, drop-downs, check boxes, grids, labels and pictures, and there are a ton of 3rd party control toolkits.
WebForms abstracts away the stateless nature of the web, and attempts to make it look like it's stateless. The trouble is it's a leaky abstraction, and at some point it's unavoidable that you will have to deal with it either indirectly or directly.
Indirectly, you deal with slow load times as a crazy amount of 'state' storage is required to maintain the abstraction. I dealt with an app at one point that had a grid with many text box controls in it, where the 'state' information was well over 1MB -- which gets sent as part of every request to the server.
As your app gets more complicated, you start running into more direct problems. In my experience, as soon as you're build any type of interaction that's not something built-in (can be done by clicking in the IDE), you start fighting with the framework. The lifecycle is necessarily complicated in order to support the stateful abstraction, and you must understand it very deeply to know where to put your code. The lifecycle is a series of events that happen between initializing, loading posted data, rendering output, etc.
At some point you realize the framework is getting in your way more than it is helping, and switch to just developing for stateless directly (which basically means MVC, or a stateful single-page app + stateless REST API).
Single-page web applications that get loaded once and stay loaded, and are primarily driven by JS code, don't have any of these negative attributes. State is kept in memory, just as it is with a desktop application. There is no need to shuttle around large amounts of state, other than what is needed to authenticate against/communicate with the back-end APIs.
I remember having to hack new controls e.g. options that did away with the viewstate. Then had to roll my own event handling as the events which rrelied on comparing the viewstate will the latest value would no longer fire. Great times.
The problem with Delphi and its relatives is that they are walled gardens. As long as you are working on the kind of application envisaged by the designers (roughly, CRUD with a SQL backend) everything is easy. As soon as you step outside that domain your foot disappears into a sucking quagmire.
I don't really agree. Delphi made writing native code on Windows really pleasant, primarily because it had (a) a built-in string type with reference counting and (b) strong conventions around object ownership and construction / destruction.
The built-in string type interacted really well with the Win32 API, and it was universal - there wasn't one string type to deal with the platform, and another string type for your own code, and yet another string type for third party code, all too common in C++, especially in the 90s.
The object model - zero-initialized reference types with a Destroy method that was safe to call on null values - avoided one of the biggest pains in C++ exception safety, in particular safely destroying partially constructed instances. The idioms in Delphi don't catch all cases (e.g. if a destructor throws, you're potentially going to leak), but they work really well 99% of the time without convolutions or RAII wrappers.
Delphi did exceptions very well too. Because of the strong conventions around try/finally to wrap creation and destruction of objects, exceptions never felt dangerous or uncontrolled. I don't think anyone who used Delphi in anger pined for nothrow, explicit exception specifications or wholesale replacement of exceptions with error codes.
The point is that it was a high-level native language language that was far easier to use correctly than C++.
I only wrote a couple of non-GUI toy programs in Pascal "back in the day" and did some disassembling for fun because someone told me it won't look like C disassemblies (they were right!) but tbh, Delphi from what I remember (only saw it used, never used it) isn't wow-ing me more than current state of the art GUI-builders (like say Storyboards for the Apple ecosystem) so I suppose it's mostly nostalgia? Not sure comparing it to web development is fair but (all those wicket corner cases aside) I actually like the simplicity of web layouting as well. With a decent reset or bootstrap or whatever (and maybe flexbox) I think pure HTML+CSS is very direct and can be prototyped rather quickly via "textfile change and see".
I miss Visual FoxPro. I have never been more productive in my whole life. Of course compared to today's languages that's an abomination to say, but the tools, the data browser and the sql embedded in the language made it shine on its own merits.
The languages have advanced in so many directions, I just took a look at old foxpro code and it was damn ugly, all caps and ENDIF ENDFOR everywhere. That's ugliness if I've seen it.
Now tools, they were unbeatable in their simplicity and effectiveness as you say. A data browser is the most powerful UI and the ability to connect it with a data source by its cursor name can't get any simpler. Try doing that even in Swift and it is a rain dance of sorcery to make it work.
A data source to a report, bam! As simple as that. A data source to a table, bam! to a form, bam! to any UI control, bam! That was productivity if I've ever seen it.
1. Embarcadero nee Borland always building new "cool" features (e.g. IoT) rather than core functionality (64 bit only recently, compiler slow, IDE crashes).
2. User base now mostly supporting old applications so require high level levels of backwards compatibility (with poor or broken APIs).
3. Loss of good libraries. Originally they had good libraries (and culturally the source was available for a few extra $$). Now libraries are poor, there is little incentive to make new libs, and the target is fragmented for library writers (many Devs are stuck on a variety of older versions - upgrades are costly, and upgrade reliability is erratic).
I started developing in Delphi after Delphi 1 came out, have worked in Java and C++ along the way, but I've been largely a LAMP stack web developer for the last ten years. I've looked at the code output from various Delphi web builders; it's not pretty, not inherently responsive, not accessibility compliant.
I still use Object Pascal in Lazarus for writing widgets and utilities. It cross-compiles to Linux, MacOS and Windows and lets me do things that would be difficult or impossible with a web app. But these get about 1% of my attention.
Want simple development ? go for low-code environments, that simplify a lot and use gui tools where possible(models, workflows, forms,etc). There are plenty tools of those sort, and at least the best of them(mendix/outsystems) may scale pretty well in complexity of applications created in them.
Little historical fact, Microsoft nicked Andreas Hejlsberg, the creator of the Borland flavor of Pascal (starting from the Turbo Pascal days), and had him architect C#.
So if you trust microsoft, or you're doing boring bussiness software where you don't care about anything but the paycheck, C# may be an improvement.
Yep, Delphi's soul lives a little bit in C#. Also a reason why I was quite disappointed of .NET being NGEN + JIT, instead of pure native compilation like Delphi.
At least, WP 8.x brought us MDIL, followed by .NET Native and CoreRT.
Also Anders and his team work on Typescript is quite good.
100x more powerful than the Visual Builder in VisualAge suite of products [1] and Dolphin Smalltalk's MVP-based tool and code browsers [2]?
While those (along with Delphi's VCL) are now a shadow of their past or completely defunct, I doubt anything comes close to them technically, let alone 100x more powerful than them.
PS: I just missed that this is about Web development though. Will just leave the comment here for posterity.
Have you tried to use VAJava at that time (middle nineties of the previous century)? Or maybe you were involved in producing it, or simply like Smalltalk?
"As mentioned before, VAJava is written in SmallTalk. As expected, the environment is not going to set any speed records for Java performance"
"I used the JGL benchmarks to test the performance of the Java virtual machine. When running under VAJava, the benchmarks took significantly longer to run than they did under version 1.1.5 of Sun's JDK. Therefore, I would not recommend VAJava for testing applications which are primarily computational."
I've tried something from VisualAge at that time and it was a pure catastrophe. My conclusion was that it was bought only by the enterprises who decided to force their developers to "use IBM" no matter what. Maybe VAJava was different?
I only have experience with VA Smalltalk and VA Java. I used their WebSphere suite of products years later.
> I've tried something from VisualAge at that time and it was a pure catastrophe. My conclusion was that it was bought only by the enterprises who decided to force their developers to "use IBM" no matter what.
On the contrary, VAS and VAJ was one of the most non-IBM-like products, compared to say Rational Rose or Eclipse (ironically, Eclipse was supposed to be a descendent of VAJ) or WSAD which is built on it.
> Maybe VAJava was different?
VAJ is basically the Java language bolted on the Smalltalk paradigm - code browsers, workspace, method-level versioning, etc. Smalltalk is an acquired taste, so I can see how VAJ can be a turn off for some.
Yes: I've really enjoyed using Turbo Pascal in eighties and earned for living developing using Borland products in the early nineties. I've received VA for C++ to evaluate its suitability. After I've installed it it crashed almost on every click, before I was able to even try something usable. Before it would crash, it would be also quite slow to do anything. In short, not comparable at all with the Borland feel I was spoiled with (remember, the OP here is about Delphi). I don't remember if I've tried it before or after the first (16-bit) Delphi. But I know that I was absolutely amazed with Delphi, and quite puzzled with VA C++ (not understanding how they approved the production of the CDs of something in that state). I understood that IBM favored OS/2 and I've tried it on the NT of that time, so, apart for the clumsiness of the interface (which simply didn't fit much with what I've expected an IDE should let me do easily) I've also assumed that they probably tested it only on OS/2 and have made the NT version just to say it exists.
So I can't say it appeared better than Rational Rose which was also horrible, as far as I remember, more stable (as in not crashing that much), but again in my opinion unusable except for wasting time.
The system on which I've tested was otherwise stable, the applications I've user regularly and the builds that lasted hours haven't crashed.
Ah, Ok. I have been wrong to mention the VA suite of products in my original comment. I have only used VAJ and VAS then. They were (IMO) truly great. VA C++ sounds horrible. Perhaps the other products in the VA suite sucks :)
I used Delphi too, it was great. The VCL and the community/market around it was wonderful. I looked into BCB for a bit, but unfortunately never got to using it in anger..
From your description I would assume you got to use the version where IBM tried to create a Smalltalk/Lisp Machine experience for C++, similar to Lucid's Energize C++, which was so resource demanding that IBM gave up on it.
Nowadays we have Apple and Microsoft returning to the idea of using databases to model C++ on the IDEs.
"Let’s not beat around the bush: VisualAge for C++ for Windows is a disaster as far as I am concerned. It is by far the most anti-productive environment I ever came across, C++ compilers or otherwise."
"The wizard-like approach for project configuration takes you through a number of tabbed dialog pages à la OS/2 (with spiral binders and all that), and they simply look gross on the Windows platforms. What’s worse, elementary options such as a Browse button to navigate to a project directory are missing."
"A static library is not among the options as I found during one of my tests, but for the ones that are, you sometimes wish you’d never started in the first place."
Etc. I also remember it looked visually weird. And that it didn't do what I expected an IDE to do. He describes that and also some strange manual steps.
"Installing VAC4 can range from a trouble free walk in the park to something akin to being in the first wave landing on Omaha beach. I have installed the OS/2 and NT versions on multiple machines with varying, mostly good, results. However there are some really nasty horror stories in the news groups about installs going awry. In my experience installation problems seem to revolve around four issues:
VAC4 is very picky about hardware. It will complain or not run on a machine that is seemly running everything else just fine. I've run into this more with OS/2 than with Windows."
"Once you get VAC installed there is one fix pack for version 4 and two fix packs for version 3.6 that you need to install which take care of a number of bugs. The fix pack installation also uses Feature Install. Did I mention that Feature Install really stinks?"
As in, too advanced to implement the basic functionality before being that advanced. But I think there's enough evidence: only those who were physically forced to use it could have used it then. Which was my initial opinion.
P.S. Have you personally used VisualAge C++ in the nineties? Can you tell a bit about your use too? I see you're linking the other things that weren't and aren't that VisualAge C++ thing. Thanks.
Back in 98/99 I wrote an app on Delphi for my dad to run his business. He is still using it today (on a modern OS) although he reports bugs that I no longer can fix.
Yes, it is still pretty much work in progress, lacking many C++/UWP features to be usable for UWP applications, specially regarding VS XAML editor, Blend integration and UWP controls.
Microsoft is promising feature parity with C++/CX when VS17 comes out, lets see.
In any case, .NET tends to have the spotlight for app development on the MS stack, with C++ getting the low level high performance work, so C++/CX is nice, but as way to expose those low level APIs as UWP controls, just like C++/CLI does for .NET.
I don't even find the GUI-builder that amazing. It's very easy to use, and up to a certain scale it's very convenient; but it encourages and rewards coupling the implementation to the interface at every turn, making any attempt to do the right thing an uphill struggle.
One of the most painful memories I have from software, the stuff that haunts me in my dreams; is writing stored procedures for Delphi's favorite database, Interbase. Whenever you did something wrong, it would give you an error saying 'Error at BLR offset 283729' or similar, offset being the offset in the compiled code where the error supposedly happened; thereby forcing an inhuman level of discipline when making changes. I had to write and maintain thousands of lines of that bullshit; since by the time we dug that deep into the performance of the BDE, the entire application was fused to it on UI level. Switching meant going through every single stupid form in the application and carefully translating event logic, bindings and properties to pure SQL.
Thank you Borland, but no thank you; I'm out.