In order to do a Delphi-like product for the web, you need to solve these problems:
1) JS isn't discoverable from the perspective of the IDE. There's no static typing and no way for the IDE to hook up code to UI elements, and vice-versa. You need a statically-typed language that can transpile to JS without too much "impedance mismatch".
2) HTML layout functionality isn't really geared for the type of layouts that are present in desktop applications. Document-oriented layouts have a completely different set of requirements.
3) You have to solve the design-time/run-time issue, and this is not an easy issue to solve due to 1). You can't just use a browser engine at design-time for the WYSIWYG portion, so you need to create a whole "browser emulation" layer in the IDE, along with an execution environment for your statically-typed language.
Our product, Elevate Web Builder, solves these issues and implements a Delphi-like IDE for developing single-page web applications:
We've got a new version coming out soon that will also offer server-side coding in Object Pascal, giving developers a single-source-language approach to developing complex web applications.
Your IDE looks cool especially for Object Pascal die-hards but your way wrong with JS. One doesn't need static typing to discover patterned functions. You need a convention and a parser that can recognize that convention.
Re: patterned functions: you can't rely on patterned functions in a full-featured IDE that allows any class method to be an event handler/delegate for another class instance. What you end up may look like what Delphi is doing, but it is just an approximation of the real thing that won't work very well for general-purpose usage. There's going to be all sorts of edge cases that don't work correctly because you can't get a reliable signature for a given method.
I'm not familiar enough with Smalltalk to comment, but I'm guessing that it had a formal, discoverable system of hooking events to event handlers. Was that the case ?
There is no "formal" system for events, but there are patterns and most Smalltalk systems follow. For example, Pharo makes use of an object called `Announcer`, which you then subclass to make your own announcements. It works similarly to a pub/sub pattern, but using pure live objects and by sending specific messages to subscribers.
Previously, systems like Squeak used a pattern where objects had a collection of "dependents" that would be updated when sent the `changed` message. I think this is still how input events -- keys, mouse, etc -- work in Morphic.
In either case, the "handler" is whatever you want it to be, so long as the target object implements the appropriate message.
As for discoverable, I'd say most things in a Smalltalk are easily discoverable, though some of the patterns can get convoluted if you're inheriting an ancient object structure.
Thanks, very interesting. I think a lot of the confusion here is over my terminology and a general lack of understanding about what the Delphi IDE is actually doing.
By "discoverable", I mean can the IDE:
1) Compile/analyze the code in the component library/run-time,
2) Figure out which type of method can be used for a certain type of event property for a given class, and
3) Display all matching methods in the current unit/module for the user to select.
This is what Delphi does (and Visual Studio with WinForms), and all of it is done at design-time, meaning that your application is not getting compiled in order to determine any of this.
From what you're describing, I don't think Smalltalk is doing the same thing. However, it could be doing something similar if it enforces (at design-time) this part:
"so long as the target object implements the appropriate message"
You should play around with Pharo if you have some free time. It's a completely different way of doing things (and a lot of fun). Indeed, what you've described of Delphi is not happening in a Smalltalk: there's no difference between the thing you are programming inside of and the end product (at least not right away).
It's easier to think of a Smalltalk image as a live system that you are configuring (using Smalltalk itself) for some end-user or goal. Because a Smalltalk image is simply a snapshot of the state of the whole system, you can use a development image to generate a more bare-bones, customer image/application if you so choose. In other words, you can configure a Smalltalk image however you want for a client. This would be the equivalent of the kind of "compiling" that creates a usable end product. You are manipulating a live system and configuring it for some purpose rather than describing a system in text files, compiling it, and then giving it to people to use.
On a technical level, you are compiling all of the time when working in a Smalltalk. Every time you save, the changes recompile and execute, live, as instantly as these things can.
Of course this means that Smalltalk is highly self-aware, and therefore there can be / are some of the IDE features you've listed. One of my favorites is the ability to provide example inputs and example outputs and see recommended objects/messages and implement the method for doing it. It probably exists in other Java IDEs or something, but I've never seen it elsewhere myself.
I will definitely try Pharo and see how it all works. I've read a bit here and there about Smalltalk over the years, and the whole environment seems really cool. I'm especially interested in the whole "not requiring static types", because that may give some ideas on how to do a JS IDE without losing the functionality that we wish to maintain. The "liveness" of the Smalltalk environment is also very much in line with how JS/HTML are used, so there may be a natural fit there.
I just read scroot's comment (the grandparent comment to mine, and parent to yours). I found it somewhat uncannily similar to a sub-thread involving HN user mikelevins (a long-time Lisp developer) in another HN thread a while ago (about Lisp). He commented on something (it was a thread about a Show HN about Full Stack Lisp, a book), I asked a question, he replied in more depth. His description of some advanced features of Lisp was fairly similar to what scroot wrote above (but with more points added). So you might be interested to check it out:
That is the top comment by him in that sub-thread. My question to him is 2nd reply below, then he replied at even greater length. Some pretty deep stuff..
(In another of his comments - this one, in a different thread: https://news.ycombinator.com/item?id=14677396 - he also mentioned that Lisp and Smalltalk are two of only a few languages that share some of the features he talks about.)
I also should mention that I only started getting into the Smalltalk stuff a year ago, and am by no means an expert. But reading about it and using it (Pharo mostly) really changed the way I think not only about programming, but computing more generally. If you ever watch a Kay lecture you won't really get what he's saying until you've used one of these live environments, whether it's Smalltalk or an interactive Lisp.
I recommend getting the Adele Goldberg "Smalltalk: The Language and its Implementation" (colloquially known as the "Blue Book"). I find it to be the second best programming book ever, aside from The Little Schemer.
A GUI web site generator is trivial and many already exist. The difference between the web and traditional desktop based programs is that you have a lot more freedom in constructing the experience on the web. Whereas a typical WinForms app is made up of a bunch of drag and drop common controls like the button or text edit, simple text editing and buttons can take many different creative forms to best suit the intended experience.
So I guess another way of saying it is that older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences. The aesthetic and the experience as a whole is important.
>A GUI web site generator is trivial and many already exist.
>older desktop based technologies like WinForms are more geared towards purely functional experiences. The web can go above and beyond providing merely functional experiences.
Not talking about web sites here, but web apps, which in the modern sense are much more aligned with desktop apps than websites of old.
I meant web apps. Modern web apps offer a lot of freedom in constructing the precise experience we want the user to get. This is unlike traditional desktop applications with the cookie cutter controls that behave the same way from app to app.
That's not been my observation when it comes to SPAs, responsive apps, etc. They tend to use fairly straightforward components, layout schemes, etc. For instance, if you look at the components/layout capabilities that come baked into the latest version of Bootstrap, you'll find a lot of bases covered.
Regardless, there's nothing that precludes you from wrapping any control you desire into an interface that makes it droppable and configurable through a GUI editor, then have it generate code. Likewise, for the creation of different layout managers, though in practice I don't think you'd find a ton of variability there. Most "experiences" boil down to grid-based and responsive.
So, I'm not sure which precise experiences you imagine couldn't be created. It's all just code. But, if there are some, then they'd be the exception, not the rule.
You can already create simple websites with tools like above. But non-trivial SPA's can't usually be constrained by tools like that because they don't allow for enough flexibility.
It's not that the web hasn't caught up to GUI editor paradigm that has been around for decades. In fact WYSWYG web editors were common when the web was in its infancy.
>non-trivial SPA's can't usually be constrained by tools like that because they don't allow for enough flexibility.
Yeah, you've kind of repeated variations of that vague statement, to which I've replied with specific capabilities/features that SPAs and modern webapps tend to use. I've suggested that they represent very common features/layouts that can readily be constructed with the aid of a GUI tool.
But, here, you've now responded with a few website builders that are not intended to be used for the kinds of SPAs/modern webapps we're discussing. That doesn't make a point, except to say that "other things exist".
Do you have specific examples of SPA/webapp functionality that cannot be readily built with the aid of a GUI tool?
>This is unlike traditional desktop applications with the cookie cutter controls that behave the same way from app to app.
Controls in desktop apps are not just "cookie-cutter" (if I understand correctly what you mean by that). They can be subclassed in C / C++ / Delphi etc. code, to add to, or override, the functionality as well as the appearance of the superclass control. (And individual desktop app developers can, did, and still do this. It is not necessary to buy or downloads such custom controls, anyone can write them - like you say for the web.) This was being done way back in Windows (from as early as Windows 3.x [1]) and probably in Unix too (X-Windows). In fact, X-Windows may be the source, or one of the early examples, of the famous saying "provide mechanism, not policy" [2], which is related to this topic. (What that saying implies is that policy - which often involved look-and-feel - could be, and was, provided by higher layers, than the lowest layer, Xlib, which provided the mechanism (for X's style of client-server GUI programming.) I've not checked their implementation details, but probably both GNOME and KDE (which both look and behave rather differently from each other, though both are fundamentally Unix desktop environments), are built on top of X-Windows (in its newer avatar of XFree86 or whatever it is called these days).
[1] I just did this Google search for the term "paul dilascia windows programming book", and the first search result is:
which is a book by him called "Windows ++: Writing Reusable Windows Code in C++ (The Andrew Schulman Programming Series)" - which was considered an influential book at the time (see Wikipedia page link below). I had read it, years ago, out of interest, even though I was not doing much GUI programming at the time. It showed (with code) how to use C++ to wrap the procedural (WndProc), event-driven Win 32 GUI API in C++ classes, not only for more reusable code (as the book title says), but also how to subclass existing Windows controls and add more functionality to them, or change their appearance, etc. In fact, IIRC, his Windows++ framework completely hid (from the developer) the traditional, error-prone, manually coded WndProc window procedure style of programming, that was the staple of raw Win32 GUI programming. I was quite junior as a programmer at the time when I read the book, but remember thinking even then, that it was something significant that he was writing about, and the book helped me to understand some of those deeper topics to some extent. To describe it another way, the book basically contained the full C++ code for something like a smaller version of MS's MFC or Borland's Delphi or other OO Windows GUI frameworks that wrapped the lower-level raw Win32 GUI API, which involved writing a lot of low-level procedural boilerplate code (with a hand-coded event loop for each app you wrote). That was some general background and history, but more relevant to your point, it shows that customizing controls is very much possible and done in desktop apps too (not just in web apps). And you do not need to write your own GUI framework in order to customize controls, either. You can just take classes from an existing GUI framework that you use, and subclass those classes, and add or override functionality, including both look-and-feel and behavior. The second search result is Paul Dilascia's Wikipedia page - https://en.wikipedia.org/wiki/Paul_Dilascia .
HTML has more features about layout. Also styling is more flexible in HTML.
XAML has better rendering (esp. in WPF), better alpha blending (esp. in UWP), much better animations, better vector graphics, and better editor (you can create acceptable layouts using WYSIWYG, not touching raw markup). Also it has templating, data binding, and other features not found in HTML.
How many years later and the web still does not catch up.