Don't forget Anko for Kotlin on Android! :-)
https://github.com/Kotlin/anko
Apple's freshly laid SwiftUI uses a declarative syntax to create user interfaces and enables powerful new visual design tools in Xcode, the company's developer tool for Mac and iOS applications. SwiftUI was squeezed out at Apple's Worldwide Developer Conference, currently under way in Silicon Valley's San Jose. Craig Federighi …
Been using Qt to build cross-platform (Android,iOS) apps for a while - I also thought this looked a bit like QML.
It would be neat if the Qt guys could leverage this by a translation from QML to SwiftUI: one run through with a perl script instead of adding all the abstraction and implementation libraries that Qt needs to build for iOS?
Delphi never generated much source (the control's properties are stored in resourcestreams). JBuilder is a better example of a two way source based designer.
Also, they had a slightly different screen model. Many modern tools assume a Browser layout model that quickly adds a scrollbar if things don't fit, rather than shrinking them to size.
Just different ways to achieve the same result.
Delphi is declarative just like XAML is - Delphi UI representation was created before XML became common - still you could modify the declaration (which became a simple text file quite early) and the visual editor will display the new settings.
Initialization code went into initialization events (and de-initialization as well). It worked also for non-visual components - which can still be managed in a RAD way.
Actually as you could do anything in code you could store in a "form", you could generate the same code. But frankly, I always preferred to keep the UI design outside the source code. Less risks to inadvertently mess things - and being the UI code a lot of repetitive instruction and sometimes large blobs of binary data (images, etc.) really better to store that separated.
Sure, being Windows-only the declaration were stored in resources to keep them inside a single executable (they could be read from other files) - which incidentally made them very easy to localize - open the resource, translate what needed to be translated, adjust widgets size to fit the new strings, save the resource as a separate file, load it when the locale match.
That made loading and displaying widgets much faster as there was less code to compile, store and run - in an era where CPUs were far less faster, and RAM was scarcer. Resources aren't load in memory, unlike code. They can be read from disk when needed.
Windows applications can add scrollbars as needed too. Resizing widgets is an optional capability - anyway users usually don't like to have to scroll continuously to reach controls in an application - the "reading page" model of HTML is actually really out of place for interactive applications and not textual contents.
One limitation of the old Windows model is that widgets positions are absolute and in pixels. It doesn't work well with displays available today with different form factors, different pixel densities, and different input methods - which do need a more adaptive UI - yet not what we see in web applications today - which dumbed everything down to mobe users with enormous widgets, a lot of wasted blank spaces, and subpar experiences even for the simpler tasks - as true reflowing and resizing is a complex task.
Nope, hence "we" instead of "I".
I could have just left it with a blank space, but you have to have a bit of style about these things. I mean, i didn't think anyone would be delicate about it. I hope there is no bad blood between us, if there is we could just begin again? I know all too well how hard it is to shake it off once someone annoys you but I hope things turn out safe and sound. There's no need to see sparks fly over a simple comment. Call it what you want but I thought the joke was gorgeous.
Hopefully, we're out of the woods.
This post has been deleted by its author
"Instead of building a user interface in code with Apple's UIKit framework"
Most iOS developers do not build UIKit in code (unless they have come across from another platform and don't know any better) they use storyboards (Drag and Drop). SwiftUI looks quite good for custom screens, however for a large App with many scenes it looks like a lot of overhead.
When I started iOS programming most of the work was done in code (30% was navigating between scenes), Storyboards took this pain away, SwiftUI looks like it is giving it back.
Ultimately this look like more an attempt to head of non-Apple ways of building apps such as React Native.
The one good thing is that if you want to build an app in a react style then at least you'll now have some actual debugging tools :)
Declarative solutions, i.e. domain-specific languages, suffer from the problem that eventually you will need to break out of the declarative vocabulary into general-purpose code. (For example, your declarative HTML needs Javascript.). Often that’s really messy. The better solutions are probably those that embed the DSL in a general-purpose language, rather than vice-versa. Is that what SwiftUI is doing? It’s kind of what the name suggests I suppose.
I would still not bother with a language that is so closely tied to one platform though.
Flutter targets any mobile, desktop web. I see SwiftUI and Android Jetpack Compose as a acknowledgement that declarative immutable views are the way to go. However only Flutter can now match portability of web and the performance of native apps.
I'm happy to see SwiftUI and Jetpack Compose as they bring native developers closer to Flutter.