SwiftWebUI(alwaysrightinstitute.com)
alwaysrightinstitute.com
SwiftWebUI
http://www.alwaysrightinstitute.com/swiftwebui/
106 comments
Yep, this is super exciting.
I would be surprised if Apple isn't working on SwiftUI for web themselves. They have web versions of all of their major apps already – Photos, Numbers, Keynote, etc. I'm sure they'd prefer to not have a completely separate implementation for those. SwiftUI currently supports all the platforms those apps... except the web.
Also it makes a ton of sense to have an Apple-supported way of writing web backends in Swift... after all, they have a lot of those too.
I don't know if they'd support Windows and Linux because they could just support web instead and that would be good enough. Maybe Android is worth it though? The main reason is I'd imagine they might want to unify the codebase of Apple Music and Apple TV apps, but I'm sure they'd worry about bringing too many good apps to their competitor's OSes. That's probably too scary so they'll probably prefer to just build two apps like they already do.
Also, this reminds me, is there any way to listen to Apple Music or watch Apple TV on Windows, Linux, or Chrome OS? I don't think so. I'd have to imagine that's in the works.
I would be surprised if Apple isn't working on SwiftUI for web themselves. They have web versions of all of their major apps already – Photos, Numbers, Keynote, etc. I'm sure they'd prefer to not have a completely separate implementation for those. SwiftUI currently supports all the platforms those apps... except the web.
Also it makes a ton of sense to have an Apple-supported way of writing web backends in Swift... after all, they have a lot of those too.
I don't know if they'd support Windows and Linux because they could just support web instead and that would be good enough. Maybe Android is worth it though? The main reason is I'd imagine they might want to unify the codebase of Apple Music and Apple TV apps, but I'm sure they'd worry about bringing too many good apps to their competitor's OSes. That's probably too scary so they'll probably prefer to just build two apps like they already do.
Also, this reminds me, is there any way to listen to Apple Music or watch Apple TV on Windows, Linux, or Chrome OS? I don't think so. I'd have to imagine that's in the works.
There is Musish (https://musi.sh/) which uses the MusicKit JS to allow Apple Music playback in the browser.
There are also plans to bring the Apple TV app to Smart TV platforms as well, so a similar framework may be on the way for TV too.
There are also plans to bring the Apple TV app to Smart TV platforms as well, so a similar framework may be on the way for TV too.
They probably aren't. Remember that Apple isn't very fond of the web app idea because it could make them lose their app store and the revenue from it.
A Swift-based web framework doesn't have to come from Apple; as already shown, you can write your own DSLs in Swift 5.1
Well, web apps could kill their desktop platform because you can have the same experience cross-platform, so why buy a Mac? It's in their interests to ensure that the Mac app is substantially better than the web app by integrating more deeply into the OS. So offering a single framework that can do a great job on web apps and an excellent job on Apple platforms, you ensure that it's the most attractive option to developers who would otherwise build an Electron app. And you ensure that most cross-platform apps (which is most apps) are better on Apple platforms.
(If they get there first, this has a side benefit of preventing Windows, Linux and Chrome OS from doing the same thing as easily.)
(If they get there first, this has a side benefit of preventing Windows, Linux and Chrome OS from doing the same thing as easily.)
That's weird. Why did they say that web apps were the way to go for the first two revs of "iPhone OS"?
But seriously: app store revenue is a rounding error. It's more likely that Apple perceives web apps as a threat to their bottom line the same way they view ripped MP3s as a threat to their iTunes revenue.
But seriously: app store revenue is a rounding error. It's more likely that Apple perceives web apps as a threat to their bottom line the same way they view ripped MP3s as a threat to their iTunes revenue.
> app store revenue is a rounding error.
“Apple’s apps economy: Bigger than Hollywood”
https://fortune.com/2015/01/22/apples-apps-economy-bigger-th...
“Apple’s apps economy: Bigger than Hollywood”
https://fortune.com/2015/01/22/apples-apps-economy-bigger-th...
Eh? Videogames have made more money than Hollywood for years, that's not news or impressive.
$14b (app store napkin estimate), out of $265b (2018), is ~5%.
$14b (app store napkin estimate), out of $265b (2018), is ~5%.
In 2018 AppStore revenue was $46.6 billion [1]. Apple revenue for 2018 was $265.6 billion [2]
So, your "rounding error" is in reality 17.5% of Apple's entire revenue. It's "only" twice bigger than the entire Mac portion of Apple's business which is $25 billion [3]
[1] https://www.cultofmac.com/601492/app-store-google-play-reven...
[2] https://www.statista.com/statistics/265125/total-net-sales-o...
[3] https://notesmatic.com/2018/12/apple-revenue-from-mac/
So, your "rounding error" is in reality 17.5% of Apple's entire revenue. It's "only" twice bigger than the entire Mac portion of Apple's business which is $25 billion [3]
[1] https://www.cultofmac.com/601492/app-store-google-play-reven...
[2] https://www.statista.com/statistics/265125/total-net-sales-o...
[3] https://notesmatic.com/2018/12/apple-revenue-from-mac/
> use full-featured Swift to output HTML ... a hint of something huge and possibly disruptive to come.
This technique has been here for a while with Kotlin and its kotlinx.html library: https://github.com/Kotlin/kotlinx.html#dom
I used it recently on a small project (server-side on the JVM) and might use it the client-side as well (compiled to JS) – you can implement adapters to integrate with your JS framework of choice.
This technique has been here for a while with Kotlin and its kotlinx.html library: https://github.com/Kotlin/kotlinx.html#dom
I used it recently on a small project (server-side on the JVM) and might use it the client-side as well (compiled to JS) – you can implement adapters to integrate with your JS framework of choice.
And even before that in Scala (e.g., Scalatags).
Even before that in Java with GWT.
Any programming language can be used to produce HTML, but here – with Scala, Kotlin and Swift – we're talking about something more specific: using an internal DSL to write concise, simple and somewhat declarative code that describes the HTML tree.
Java definitely can't (reasonably, sensibly, practically) do that. GWT seems to be using XML from what I can tell: http://www.gwtproject.org/doc/latest/polymer-tutorial/widget...
Java definitely can't (reasonably, sensibly, practically) do that. GWT seems to be using XML from what I can tell: http://www.gwtproject.org/doc/latest/polymer-tutorial/widget...
And probably before that Common Lisp
This all looks like Flutter to be honest.
Indeed, but I prefer SwiftUI's syntax though, and the property wrappers + view modifiers paradigm, as well as Apple's Combine framework for processing data/events. Appears to result in less verbose and much cleaner, modular code compared to Dart+Flutter.
Yeah I really liked Flutter so I was excited that some of it's best ideas were coming to Apple. But Flutter is so young it's hard to imagine they rewrote whatever they had in a few months and got it ready to ship in just a few months for all of their major platforms. So I don't think they've borrowed it from Flutter, but if they did it might be even more impressive.
The first commit to Flutter was made in Oct 23 2014 (Initial name was Sky), It is almost as old as the Swift language itself. So, IMO, Swift UI had quite a bit inspiration from Flutter. If you look at the samples, the similarity is uncanny.
Isn't Flutter just a reimagining of React Native anyway?
In theory, there are four fundamental approaches.
1. Separate stacks, native widgets
2. Shared stack, native widgets
3. Separate stacks, custom widgets
4. Shared stack, custom widgets
React Native uses methods 1 and 2. They have unified components that can be used across platforms, but they lack features, so most complex apps use the second approach. The big wins are a more known language (JS) and sharing a bunch of the "backend of the frontend".
The big downside happens when you add more systems (eg, web, OSX, Windows, Linux, etc). When you do this, the intersection shrinks and the potential for bugs in the shared widget increase dramatically.
Flutter uses methods 3 and 4. Rather than using the native widgets, they carry along Skia to do the rendering for them. This neatly skips most of the UI intersection issues because if the native widget for X lacks a certain feature, you can add it yourself in your custom widget. When dramatically different looks are desired, you can still use separate widgets for different systems. Adding additional systems is usually less difficult because rather than writing hooks into everything on the system, you only need more basic system hooks and the effort to get the renderer working.
The big downside here is development time and little inconsistencies. Instead of leveraging the work already done by the native developers (who probably know their system much better than the library's devs), everything must be built from scratch. Getting 90% there is easy, but getting every little detail working so it feels native is much harder. In addition, you must keep up with native widget changes which generally adds a lag time between their release and your catchup (but on the plus side, you may have already implemented some features they were missing). It should also be added that some UI features may not be available on some platforms (despite the shared widget) simply because the underlying OS does not support them, so multiple components may still be necessary for some things.
Both approaches have been tried in the past. Qt is probably the most successful at cross-platform design and they use the 3rd and 4th methods. I'm inclined to think its a better solution in the end even if it is more costly.
1. Separate stacks, native widgets
2. Shared stack, native widgets
3. Separate stacks, custom widgets
4. Shared stack, custom widgets
React Native uses methods 1 and 2. They have unified components that can be used across platforms, but they lack features, so most complex apps use the second approach. The big wins are a more known language (JS) and sharing a bunch of the "backend of the frontend".
The big downside happens when you add more systems (eg, web, OSX, Windows, Linux, etc). When you do this, the intersection shrinks and the potential for bugs in the shared widget increase dramatically.
Flutter uses methods 3 and 4. Rather than using the native widgets, they carry along Skia to do the rendering for them. This neatly skips most of the UI intersection issues because if the native widget for X lacks a certain feature, you can add it yourself in your custom widget. When dramatically different looks are desired, you can still use separate widgets for different systems. Adding additional systems is usually less difficult because rather than writing hooks into everything on the system, you only need more basic system hooks and the effort to get the renderer working.
The big downside here is development time and little inconsistencies. Instead of leveraging the work already done by the native developers (who probably know their system much better than the library's devs), everything must be built from scratch. Getting 90% there is easy, but getting every little detail working so it feels native is much harder. In addition, you must keep up with native widget changes which generally adds a lag time between their release and your catchup (but on the plus side, you may have already implemented some features they were missing). It should also be added that some UI features may not be available on some platforms (despite the shared widget) simply because the underlying OS does not support them, so multiple components may still be necessary for some things.
Both approaches have been tried in the past. Qt is probably the most successful at cross-platform design and they use the 3rd and 4th methods. I'm inclined to think its a better solution in the end even if it is more costly.
As a typical Mac snob, I used to care a lot about using native widgets. But UIKit doesn't even ship with a good-looking button class, and native apps often rewrite UI elements because the builtins are not very flexible (hello UITabBar). In theory that should make it easier for toolkits like Flutter to gain ground.
> But UIKit doesn't even ship with a good-looking button class
There are so few times when one should want to use a plain button in iOS anyway. Most times when a user needs to make a choice or start a task, they pick it from a UITableView, UIAlertController presented as an action sheet, or press a UINavigationItem.
> often rewrite UI elements because the builtins are not very flexible (hello UITabBar)
What's specifically missing here? You have items, each has an icon and text, they can also have badges. Tapping on items changes the currently shown content view. What's a tab bar supposed to do besides that?
A lot of the times I see these sorts of basic UI paradigms recreated, or the typical iOS HIG ignored by recreating an Android-style UI, the app can sometimes break when iOS has a major (or even minor) update or ignore accessibility guidelines. They're usually not significantly different in function, usually just aesthetics, and not usually sufficiently so to justify the cost.
There are so few times when one should want to use a plain button in iOS anyway. Most times when a user needs to make a choice or start a task, they pick it from a UITableView, UIAlertController presented as an action sheet, or press a UINavigationItem.
> often rewrite UI elements because the builtins are not very flexible (hello UITabBar)
What's specifically missing here? You have items, each has an icon and text, they can also have badges. Tapping on items changes the currently shown content view. What's a tab bar supposed to do besides that?
A lot of the times I see these sorts of basic UI paradigms recreated, or the typical iOS HIG ignored by recreating an Android-style UI, the app can sometimes break when iOS has a major (or even minor) update or ignore accessibility guidelines. They're usually not significantly different in function, usually just aesthetics, and not usually sufficiently so to justify the cost.
> There are so few times when one should want to use a plain button in iOS anyway.
Almost every first-party app starts with a "Data & Privacy"/"What's New" dialog that uses a blue pill button, and almost every third-party app has a big fat "log in" button. Or look at Apple's redesigned Maps app. I don't know if I've ever worked on an app that didn't have its own ad-hoc button class.
> What's a tab bar supposed to do besides that?
Facebook, Instagram, Tweetbot etc. seem to have their own implementations because they want to hide the labels. Spotify has one to animate the icons when tapped. Audible has one to show the album art in the middle item. I'm going through my third-party apps right now, and only WhatsApp seems to use UITabBar as it was intended.
> the app can sometimes break when iOS has a major (or even minor) update
So did UITabBar earlier this year: https://stackoverflow.com/q/53084806
I nudge my clients towards stock UIKit components as much as possible, for all the reasons you mentioned, but I don't think UIKit is that much better than e.g. Flutter in the way that AppKit is many times better than Electron.
Almost every first-party app starts with a "Data & Privacy"/"What's New" dialog that uses a blue pill button, and almost every third-party app has a big fat "log in" button. Or look at Apple's redesigned Maps app. I don't know if I've ever worked on an app that didn't have its own ad-hoc button class.
> What's a tab bar supposed to do besides that?
Facebook, Instagram, Tweetbot etc. seem to have their own implementations because they want to hide the labels. Spotify has one to animate the icons when tapped. Audible has one to show the album art in the middle item. I'm going through my third-party apps right now, and only WhatsApp seems to use UITabBar as it was intended.
> the app can sometimes break when iOS has a major (or even minor) update
So did UITabBar earlier this year: https://stackoverflow.com/q/53084806
I nudge my clients towards stock UIKit components as much as possible, for all the reasons you mentioned, but I don't think UIKit is that much better than e.g. Flutter in the way that AppKit is many times better than Electron.
> Facebook, Instagram, Tweetbot etc. seem to have their own implementations because they want to hide the labels
All one has to do, to hide the labels, is set the labels to "" and adjust the image insets to account for the empty space.
> Audible has one to show the album art in the middle item
That's possible with stock UITabBar. Just set the appropriate image for the UITabBarItem and, again, adjust the image insets.
> and only WhatsApp seems to use UITabBar as it was intended
That's surprising. I don't use WhatsApp anymore, but most of it seemed custom. Well, that scores WA one point, I guess.
> I don't think UIKit is that much better than e.g. Flutter in the way that AppKit is many times better than Electron
Until you want to use iOS' built-in accessibility features, and you are disappointed to see that third party apps needlessly reimplemented widgets and didn't do the extra work to make them accessible.
Sadly, accessibility is always seen as an optional extra, not a fundamental feature. It's been a fundamental feature of AppKit and UIKit since time immemorial.
When some of these apps make it to macOS via Project Catalyst, this issue might become exacerbated to some extent.
All one has to do, to hide the labels, is set the labels to "" and adjust the image insets to account for the empty space.
> Audible has one to show the album art in the middle item
That's possible with stock UITabBar. Just set the appropriate image for the UITabBarItem and, again, adjust the image insets.
> and only WhatsApp seems to use UITabBar as it was intended
That's surprising. I don't use WhatsApp anymore, but most of it seemed custom. Well, that scores WA one point, I guess.
> I don't think UIKit is that much better than e.g. Flutter in the way that AppKit is many times better than Electron
Until you want to use iOS' built-in accessibility features, and you are disappointed to see that third party apps needlessly reimplemented widgets and didn't do the extra work to make them accessible.
Sadly, accessibility is always seen as an optional extra, not a fundamental feature. It's been a fundamental feature of AppKit and UIKit since time immemorial.
When some of these apps make it to macOS via Project Catalyst, this issue might become exacerbated to some extent.
You can hide the labels in a stock UITabBar, but you can't change its size, and I suspect this is what motivated Facebook and others to hide the labels in the first place.
You are right about the Audible use case, it might actually be using using a stock UITabBar. And in my experience WhatsApp has always been a pretty good platform citizen. It's one the very few icons on my home screen that tries to match Apple's style.
Agreed about a11y, I'm glad that Apple keeps bringing it up as a core feature.
You are right about the Audible use case, it might actually be using using a stock UITabBar. And in my experience WhatsApp has always been a pretty good platform citizen. It's one the very few icons on my home screen that tries to match Apple's style.
Agreed about a11y, I'm glad that Apple keeps bringing it up as a core feature.
To be fair, on Android Flutter is indistinguishable from native material design.
React Native doesn't use native widgets, only Xamarin does that.
It is in a way, it supposed to be a crossplatform declarative ui that feels native, isn't slow and etc
And Flutter looks like what has been done in Lua elsewhere, &etc.
> unlike Microsoft I don't have to worry about it being museum'ed and forgotten after a couple short years.
I wouldn't necessarily get my hopes up.
I wouldn't necessarily get my hopes up.
Apple have yet to dishearten me like that in the last 10 years since I started investing into their technologies. With Microsoft there has always been a Sword of Damocles hanging over your head.
I still harbor frustrations from the indecisive flip-flopping that occurred in the Windows ecosystem from Vista -> 7 -> 8 -> 10. It's still not easy to tell at a glance what Microsoft's primary APIs/frameworks currently are, what they're supposed to be called, or what their long term strategy is (besides masquerading as the new champion of open-source), and that doesn't inspire confidence.
One thing I'll credit Microsoft over Apple though, is the quality of their documentation.
I still harbor frustrations from the indecisive flip-flopping that occurred in the Windows ecosystem from Vista -> 7 -> 8 -> 10. It's still not easy to tell at a glance what Microsoft's primary APIs/frameworks currently are, what they're supposed to be called, or what their long term strategy is (besides masquerading as the new champion of open-source), and that doesn't inspire confidence.
One thing I'll credit Microsoft over Apple though, is the quality of their documentation.
It's been a while since I had to program native, non-cross-platform Windows apps, but isn't the flip-flopping mostly about what's considered the standard for UI programming, yet older technologies still work?
I could still make an application with MFC, if I felt particularly masochistic. Carbon on the other hand…
I could still make an application with MFC, if I felt particularly masochistic. Carbon on the other hand…
I was referring to things like removing the Start Button/Menu in one version then bringing it back in the next.
Or the "Metro" versus "Classic Desktop" duality, where you had two versions of each builtin app. Some documents/links inexplicably opened in one version and other things in the other. Some dialogs used the classic UI while others used Metro. Some system preferences used the new fullscreen UI subsystem while others opened in the legacy Windows 95'ish panels..and they linked to each other! (like desktop resolution/monitor settings.)
I recall an instance where I could not copy/paste a password for a VPN service, because the password field appeared in a Metro-based sidebar overlay on the "classic" desktop, that collapsed itself when I clicked on a classic window.... Of course Metro was thankfully disowned by subsequent Windows releases as well, but it's still a cautionary tale of Microsoft's indecisiveness and Lovecraftian UI horrors.
Or earlier situations like when they cannibalized DirectInput in favor of the dumbed-down XInput API, dropping advanced features for force-feedback joysticks.
Or when you could not get great DirectX performance or access all of its features from within .NET for quite a while.
WPF was not used by Microsoft themselves in their own products as much as its adopters hoped, either.
Whereas on the other side of the fence, Apple has already been using Swift in quite a few user-facing areas of their products, and their latest graphics tech was fully usable from their latest language since Day 1.
Or the "Metro" versus "Classic Desktop" duality, where you had two versions of each builtin app. Some documents/links inexplicably opened in one version and other things in the other. Some dialogs used the classic UI while others used Metro. Some system preferences used the new fullscreen UI subsystem while others opened in the legacy Windows 95'ish panels..and they linked to each other! (like desktop resolution/monitor settings.)
I recall an instance where I could not copy/paste a password for a VPN service, because the password field appeared in a Metro-based sidebar overlay on the "classic" desktop, that collapsed itself when I clicked on a classic window.... Of course Metro was thankfully disowned by subsequent Windows releases as well, but it's still a cautionary tale of Microsoft's indecisiveness and Lovecraftian UI horrors.
Or earlier situations like when they cannibalized DirectInput in favor of the dumbed-down XInput API, dropping advanced features for force-feedback joysticks.
Or when you could not get great DirectX performance or access all of its features from within .NET for quite a while.
WPF was not used by Microsoft themselves in their own products as much as its adopters hoped, either.
Whereas on the other side of the fence, Apple has already been using Swift in quite a few user-facing areas of their products, and their latest graphics tech was fully usable from their latest language since Day 1.
Objective-C still reigns supreme in some areas of Apple platforms, like real time audio.
While C++ is the language to go for device drivers and Metal shaders.
So there are still a couple of Swift free zones as of today.
I can list similar stuff being left behing by Apple, or even link that Java ONE video with Steve Job talking about Java going to be Mac OS X "Swift".
While C++ is the language to go for device drivers and Metal shaders.
So there are still a couple of Swift free zones as of today.
I can list similar stuff being left behing by Apple, or even link that Java ONE video with Steve Job talking about Java going to be Mac OS X "Swift".
> Objective-C still reigns supreme in some areas of Apple platforms, like real time audio.
This at least should receive some improvement in the form of the new Swift-based Accelerate APIs:
https://developer.apple.com/videos/play/wwdc2019/718/
This at least should receive some improvement in the form of the new Swift-based Accelerate APIs:
https://developer.apple.com/videos/play/wwdc2019/718/
[deleted]
You can still run Carbon on Mojave. It's been deprecated for a few years, sure, but obviously so has MFC.
> what their long term strategy is (besides masquerading as the new champion of open-source), and that doesn't inspire confidence.
The WinUI team started to publish publicly about their roadmap, you can see some information here: https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
So, I'm not a windows developer and I'm not familiar with their APIs and technologies, but they seem describe a clear strategy for "WinUI 3.0" as far as I can tell.
The WinUI team started to publish publicly about their roadmap, you can see some information here: https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
So, I'm not a windows developer and I'm not familiar with their APIs and technologies, but they seem describe a clear strategy for "WinUI 3.0" as far as I can tell.
Past history tends to indicate WinUI will be in the dustbin in a few years to be replaced by some new and shiny framework, possibly in response to SwiftUI if that turns out to be really successful.
Forgot to call out Combine, another important piece of the picture.
https://developer.apple.com/videos/play/wwdc2019/722/ (Introducing Combine)
https://developer.apple.com/videos/play/wwdc2019/721/ (Combine in Practice)
Whether you have any business in the Apple ecosystem or not, I think you'll agree they made some good moves on several fronts this year.
And as is the case with most Apple announcements, there's a lot of comments here saying that they weren't the first, about how SwiftUI is actually based on something we unearthed from the Mesozoic. Well of course, but very few are actually comparing these similar technologies. I personally prefer SwiftUI+Combine's way of doing X, even if it's clearly not the first tech to do X.
For example, at first glance, Dart+Flutter code seems full of clutter, whereas SwiftUI's
https://developer.apple.com/videos/play/wwdc2019/722/ (Introducing Combine)
https://developer.apple.com/videos/play/wwdc2019/721/ (Combine in Practice)
Whether you have any business in the Apple ecosystem or not, I think you'll agree they made some good moves on several fronts this year.
And as is the case with most Apple announcements, there's a lot of comments here saying that they weren't the first, about how SwiftUI is actually based on something we unearthed from the Mesozoic. Well of course, but very few are actually comparing these similar technologies. I personally prefer SwiftUI+Combine's way of doing X, even if it's clearly not the first tech to do X.
For example, at first glance, Dart+Flutter code seems full of clutter, whereas SwiftUI's
Thing {
ForEach(model) { data in
Child(from: data)
}
}
.modifier(y)
.animator(z)
> Whether you have any business in the Apple ecosystem or not, I think you'll agree they made some good moves on several fronts this year.
I am extremely curious whether Combine will turn out to be a good move for the ecosystem. It's not like competent Swift developers grow on trees right now, and having to grok reactive programming seems like yet another barrier to entry.
Due to all the overlapping transitions, iOS developers soon need to know some Objective-C (and by extension C), Swift, UIKit, SwiftUI, XIBs/storyboards/classic MVC, Combine, the pointless code signing mess, and some web technologies for hybrid screens. I wouldn't be surprised if that's when Apple loses the mobile toolkit wars just like they've already lost on the desktop.
I am extremely curious whether Combine will turn out to be a good move for the ecosystem. It's not like competent Swift developers grow on trees right now, and having to grok reactive programming seems like yet another barrier to entry.
Due to all the overlapping transitions, iOS developers soon need to know some Objective-C (and by extension C), Swift, UIKit, SwiftUI, XIBs/storyboards/classic MVC, Combine, the pointless code signing mess, and some web technologies for hybrid screens. I wouldn't be surprised if that's when Apple loses the mobile toolkit wars just like they've already lost on the desktop.
cough garbage collection cough modern syntax cough java bridge cough
The difference with MS is that they at least somewhat acknowledge mistakes and announce shifts. Apple silently edits history and points to the next shiny.
The difference with MS is that they at least somewhat acknowledge mistakes and announce shifts. Apple silently edits history and points to the next shiny.
> ... and unlike Microsoft I don't have to worry about it being museum'ed and forgotten after a couple short years.
How so?
How so?
Microsoft historically brings out a bunch of (often half-finished) APIs and then either officially or unofficially deprecates them rapidly (has any MS UI toolkit since win32 actually survived more than a decade with active maintenance?) Apple historically does not.
Apple kind of did it to OpenCL because they really want people to use Metal. That’s the only example that comes to mind, though.
Not their own thing, though. They’ve killed off plenty of third party standards (whatever happened to first party X11 for MacOS, say?)
Do you have examples of those? I'm not an expert at all on this topic, but WPF and WinForms have been released in 2006 and can still be used to develop windows graphical applications as far as I understand.
Even better as far as I can tell, WPF, WinForms, and WinUI are open source since 2018: https://www.hanselman.com/blog/AnnouncingWPFWinFormsAndWinUI...
Repositories:
- WPF: https://github.com/dotnet/wpf
- WinForms: https://github.com/dotnet/winformsblog-scottha
- WinUI: https://github.com/Microsoft/microsoft-ui-xaml
Now, I'm not familiar with those technologies, and don't use them, so I may be missing some things.
Even better as far as I can tell, WPF, WinForms, and WinUI are open source since 2018: https://www.hanselman.com/blog/AnnouncingWPFWinFormsAndWinUI...
Repositories:
- WPF: https://github.com/dotnet/wpf
- WinForms: https://github.com/dotnet/winformsblog-scottha
- WinUI: https://github.com/Microsoft/microsoft-ui-xaml
Now, I'm not familiar with those technologies, and don't use them, so I may be missing some things.
I mean, they've shoved them on GitHub, but are they still doing any significant work on them? My impression was the WPF at least had kind of been in limbo for years.
There's a roadmap.md on github showing MS's intentions for WPF -- first and foremost, porting to .Net Core. So there is, at least, active (and I'd say significant) development. But...
Not trying to sound facetious, but does WPF need any other significant work? It's a UI framework for Windows desktop apps (narrow and specific scope), it's stable and "just works", it's well-documented, it's officially supported, etc. Does there need to be anything else, or are we looking at it from the POV of more "modern" UI frameworks, where no active churn == languishing on the wayside?
Not trying to sound facetious, but does WPF need any other significant work? It's a UI framework for Windows desktop apps (narrow and specific scope), it's stable and "just works", it's well-documented, it's officially supported, etc. Does there need to be anything else, or are we looking at it from the POV of more "modern" UI frameworks, where no active churn == languishing on the wayside?
Also, the relationship between UWP XAML and WPF XAML is a lot closer than (for example) Win16 versus Win32 or MFC versus WinForms. Even if WPF is "just in maintenance mode", UWP is seeing active development. Some of UWP XAML additions have even back-ported to WPF, and "XAML Islands" even mean support for putting UWP XAML directly inside WPF XAML.
Hmm. This is a very common functional programming pattern in languages like Haskell and Scala. You define an AST representing your domain, using native, simple types, usually structured as a tree. Then you just write code...
So how is it different from React and JSX?
JSX is an external DSL implemented in and interoperable with JavaScript.
SwiftUI is an internal DSL implemented in Swift and thus allowing the full power of Swift’s rich type system to tag along.
See https://martinfowler.com/books/dsl.html for more discourse on the difference between internal and external DSLs.
SwiftUI is an internal DSL implemented in Swift and thus allowing the full power of Swift’s rich type system to tag along.
See https://martinfowler.com/books/dsl.html for more discourse on the difference between internal and external DSLs.
You can use TypeScript with JSX and you get all the checking (required properties, types of values, types of children, etc.) and everything.
In fact, "TSX" is an official built-in part of TypeScript.
In fact, "TSX" is an official built-in part of TypeScript.
Reminds me of Cappucino, which professed to let you build a single-page webapp using "Objective-J," a strange hybrid of Javascript and ObjC.
https://www.cappuccino.dev/
https://www.cappuccino.dev/
Whatever happened to that project? They were one of the early guys trying to do full blown "modern" JS apps on the web around the time when backbone.js came out, but with a more desktopy approach.
Edit: I forgot, they were one of the first YC companies. Looks like the parent company got acquired by Motorola and somewhat shutdown their 280slides/Atlas projects. One founder also later started RunKit which was bought by Stripe. https://en.wikipedia.org/wiki/280_North,_Inc.
Edit: I forgot, they were one of the first YC companies. Looks like the parent company got acquired by Motorola and somewhat shutdown their 280slides/Atlas projects. One founder also later started RunKit which was bought by Stripe. https://en.wikipedia.org/wiki/280_North,_Inc.
They hit 1.0 in April of last year.
https://www.cappuccino.dev/blog/
https://www.cappuccino.dev/blog/
Cappuccino had promise early on, but fell into the trap of trying to reinvent way too much, and doing a horribly bad job of it. The end result looks terribly ugly, and utterly unusable in general.
Ugly: it looks like a bad imitation of the appearance of Mac OS X from a mixture of 2002 and 2007, regardless of the fact that I’m on Windows in 2019; and due to pervasive use of 1× raster images instead of vector graphics, gradients, &c. is even more ugly on a high-DPI display. (This use of raster images without complete preload causes rendering issues when a control state is achieved for the first time, too, just like the rollover effects of the era, long since obsolete.)
Unusable: it implements scrolling from scratch, which I have never seen work well, or even almost well—it’s just something that you should never under any circumstances do; in this case, I can only get their demos to scroll at about 1% of normal speed on my Surface Book’s touchpad, and touch-based scrolling doesn’t work at all.
It tried to be Cocoa on a platform that is not Cocoa at all, with what was even a mediocre implementation a decade ago, let alone now. (I remember being excited about it when it was first announced, until I actually tried using it.)
Ugly: it looks like a bad imitation of the appearance of Mac OS X from a mixture of 2002 and 2007, regardless of the fact that I’m on Windows in 2019; and due to pervasive use of 1× raster images instead of vector graphics, gradients, &c. is even more ugly on a high-DPI display. (This use of raster images without complete preload causes rendering issues when a control state is achieved for the first time, too, just like the rollover effects of the era, long since obsolete.)
Unusable: it implements scrolling from scratch, which I have never seen work well, or even almost well—it’s just something that you should never under any circumstances do; in this case, I can only get their demos to scroll at about 1% of normal speed on my Surface Book’s touchpad, and touch-based scrolling doesn’t work at all.
It tried to be Cocoa on a platform that is not Cocoa at all, with what was even a mediocre implementation a decade ago, let alone now. (I remember being excited about it when it was first announced, until I actually tried using it.)
It is still actively developed and the problems you are talking about are long gone. It is a amazing framework if you know how to develop Mac OS X applications as they have been able to mimic almost all the functionality for use on the web. You can use the Interface Builder in the latest version of the Xcode and quickly create user interfaces. It has been around for more than 10 years and is very stable and mature.
I still remember paying $20 for the Atlas early access but never heard anything after. It was kickstarter before kickstarter. Truly ahead of its time in more than one ways.
Their demo and look were mind blowing
This is insane. It’s bringing the arguably typing of Swift with the flexibility of designing a web app. It may not be feasible (yet) to build a non-trivial web app, but I’ll be watching this project from time to time. Very cool.
Wow, what an interesting project. I wonder if you could reroute the connection over a websocket and serve an actual webpage off of it? It'd be a great demo to have the SwiftWebUI page served using SwiftWebUI ;)
Also: it would be really nice if SwiftWebUI used actual HTML elements rather than styled divs.
Also: it would be really nice if SwiftWebUI used actual HTML elements rather than styled divs.
Learning Swift is something that I considered when the “TensorFlow in Swift” announcement was made. That project is still in the early days but if eventually the turtles all the way down Swift TensorFlow implementation is complete and mature, then it would be very compelling to have one good programming language for most work. Right now I jump around between using Haskell, Common Lisp, and Python. Perhaps in a year Swift might be a reasonable language for everything I work on - I will wait and see.
It's weird that there are 49 comments and not a single mention of React.
SwiftUI is basically React implemented in Apple's proprietary language rather than a preprocessed JavaScript-XML hybrid [1]. More options is a good thing, but it hardly seems revolutionary.
[1] This works much better than it sounds like. I'm a long-term C/C++/Obj-C programmer and was very sceptical of JSX, but React is actually very nice to use. The toolchain is kind of byzantine but seems to be settling slowly on reasonable defaults.
SwiftUI is basically React implemented in Apple's proprietary language rather than a preprocessed JavaScript-XML hybrid [1]. More options is a good thing, but it hardly seems revolutionary.
[1] This works much better than it sounds like. I'm a long-term C/C++/Obj-C programmer and was very sceptical of JSX, but React is actually very nice to use. The toolchain is kind of byzantine but seems to be settling slowly on reasonable defaults.
well, to be fair, react wasn’t exactly completely new with its idea either... what’s old is new again
I find using React is a strictly better experience from ClojureScript. There's way less code, no JSX, the toolchain is straight forward, you get reliable hot loading for free, and it actually outperforms plain React in some cases.
https://github.com/ClojureTO/JS-Workshop
https://www.freecodecamp.org/news/a-realworld-comparison-of-...
https://github.com/ClojureTO/JS-Workshop
https://www.freecodecamp.org/news/a-realworld-comparison-of-...
> Apple's proprietary language
While it is heavily funded and used by Apple, I would never call it "proprietary". It's open source.
https://swift.org/about/#swiftorg-and-open-source
While it is heavily funded and used by Apple, I would never call it "proprietary". It's open source.
https://swift.org/about/#swiftorg-and-open-source
> SwiftUI is basically React implemented in Apple's proprietary language rather than a preprocessed JavaScript-XML hybrid.
This is completely false. Not one shred of truth in it. The similarities between React and SwiftUI end at both being component-based UI libraries, just like plenty of others (Cocoa, Vue, Ember, Ext JS, Svelte, Qt, do I need to go on?—some of which provide various components out of the box, others of which don’t). Beyond that, they work in radically different ways and the way you will achieve things is radically different too. Just look at the avocado toast example and see how true this is.
This is completely false. Not one shred of truth in it. The similarities between React and SwiftUI end at both being component-based UI libraries, just like plenty of others (Cocoa, Vue, Ember, Ext JS, Svelte, Qt, do I need to go on?—some of which provide various components out of the box, others of which don’t). Beyond that, they work in radically different ways and the way you will achieve things is radically different too. Just look at the avocado toast example and see how true this is.
I honestly don't know what you mean. The SwiftUI avocado toast example looks very similar to React but very different from e.g. Cocoa or Qt.
It looks more like React than the likes of Cocoa and Qt, but if you’re comparing that aspect of its style then it looks like at least Vue, Ember and Svelte too. The way it works is very different, and the way it’ll make you write code is fairly different too, inasmuch as it essentially has its own layout and rendering model, and doesn’t use HTML and CSS. (SwiftWebUI renders to HTML, but being SwiftUI stuff it’s not using HTML simply rather than that being what you work with in your UI code; and styling works in a radically different way.)
React is independent of layout and rendering models, it's not in any way tied to HTML or CSS.
AFAICT the way SwiftUI works is basically the same as React.
AFAICT the way SwiftUI works is basically the same as React.
You’re right in that it looks similar to React, but it is also true that this kind of API is (declarative component tree composition) now very wide-spread and popular, and React was not the first to implement or adopt it (I feel like the person referencing Qt maybe meant Qt Markup Language specifically).
The way all of these frameworks differ from each other is both very slight in superficial details (think two-way binding or slots) and very, very strong in the basic implementation (i.e. the diffing or reconciliation algorithm).
So, yes, a lot of these look similar these days. But saying that they work the same is oversimplification in my opinion.
The way all of these frameworks differ from each other is both very slight in superficial details (think two-way binding or slots) and very, very strong in the basic implementation (i.e. the diffing or reconciliation algorithm).
So, yes, a lot of these look similar these days. But saying that they work the same is oversimplification in my opinion.
When I referred to Qt I was meaning Qt in general, rather than QML. If you want a similar style of how you write code, then yes, QML is closer to this area than general Qt.
Yes, React is nominally independent of HTML and is independent of CSS. SwiftUI is not independent of these things, but implements its own thing altogether.
This reminds me a lot about ASP.net Webforms. Maybe this is better conceived but trying to program the web like a desktop app created more problems than what it tried to solve.
It’s a PoC, the endgame could be running it directly in the browser with WASM.
It is hopefully something more like Blazor. That would at least run one day in the browser.
> Unlike some other efforts this doesn’t just render SwiftUI Views as HTML. It also sets up a connection between the browser and the code hosted in the Swift server, allowing for interaction - buttons, pickers, steppers, lists, navigation, you get it all!
Sounds like Phoenix LiveView, and IMO it’s a very good approach. We need more things like it.
Sounds like Phoenix LiveView, and IMO it’s a very good approach. We need more things like it.
This is super cool! I built the airpptx.github.io project - which similarly uses powerpoint elements to translate to html. The challenges are in the translation of native elements to web elements. I'm going to take a look at your codebase and see if I can help.
This seems to me to have a serious architectural issue. If I read it right, the app is rendered in the browser but is processing state changes and doing HTML rendering of the state tree on the server side? How is that going to scale?
This is a really neat adaptation of the SwiftUI API to the web but it seems like the guts of it needs to run in the browser to be practical.
Perhaps we'll eventually see the Swift compiler support a WASM target?
[edit] Like Qt is doing? https://doc.qt.io/qt-5/wasm.html
This is a really neat adaptation of the SwiftUI API to the web but it seems like the guts of it needs to run in the browser to be practical.
Perhaps we'll eventually see the Swift compiler support a WASM target?
[edit] Like Qt is doing? https://doc.qt.io/qt-5/wasm.html
It would be great if one of these efforts gets us to something that actually works well as replacement for html/css; the ones that work (what you build is how it will look) feel like Flash (you lose SEO, copy/paste, accessibility etc) while the ones that try to fix that really do not work because you cannot really get the result you were aiming for design and feature wise. Webassembly did not fix (as far as I know) the SEO issue. This will all happen and for me, it cannot happen fast enough!
Maybe Apple should bless this project, by letting it use the name WebObjects?
I'm looking forward for a connection between SwiftUI and GTK or Qt, so we could have a fully functional user interface on Linux.
Offtopic:
Always Right Institute LOL
Is there a way to join this institute? I would love to have this on my CV and professional profile.
Is there a way to join this institute? I would love to have this on my CV and professional profile.
This is great -- I was sorry not to see the web target at WWDC, especially given Apple's WebObjects history.
So this is basically Flutter but for Swift?
Not really. Flutter has its own layout rendering engine, and uses low level APIs in the browser to circumvent the default rendering. This is what allows Flutter to do, say, efficient table views on the web, which is kind of a holy grail of web rendering.
SwiftWebUI currently seems to rely on normal rendering:
> SwiftWebUI tries to replicate common SwiftUI layouts, but doesn’t fully succeed yet. After all it has to deal with the layout system the browser provides. Help wanted, flexbox experts welcome!
SwiftWebUI currently seems to rely on normal rendering:
> SwiftWebUI tries to replicate common SwiftUI layouts, but doesn’t fully succeed yet. After all it has to deal with the layout system the browser provides. Help wanted, flexbox experts welcome!
> Flutter has its own layout rendering engine, and uses low level APIs in the browser to circumvent the default rendering.
Does this mean that Flutter on the web is really Flutter on Chrome? Or does is support other web browsers well?
Does this mean that Flutter on the web is really Flutter on Chrome? Or does is support other web browsers well?
It's still in tech preview, so there are likely to be bugs on various browsers, but Flutter for web compiles to standards-compliant JS/DOM/HTML/CSS so should work in any compliant browser.
It works fine in Firefox and Safari too in my experience (just a small pet project). Not on EDGE though. But it is a technical preview after all.
See https://flutter.dev/web. They claim use of DOM and CSS, but the demos I just looked at are rendering completely to canvas, with an empty accessibility tree and effectively no CSS.
Seems like it. Text is not selectable in the latest version of the flutter web preview, for example. But it's an early tech preview version, so I'll judge it more harshly when it's 1.0 :)
It has excited me and invigorated my creativity in a way that I had not felt since Microsoft's WPF/XAML, but unlike WPF+XAML you don't have to work in 2 different languages for the logic versus the declarative UI, and unlike Microsoft I don't have to worry about it being museum'ed and forgotten after a couple short years.
See "What's New in Swift 5.1" [0] around 31:15 where they show an example of how you might use full-featured Swift to output HTML. You can immediately tell that it's a hint of something huge and possibly disruptive to come.
SwiftUI and its live previews and device-agnosticism are already insanely powerful. There's no reason why that tech shouldn't be applied to web dev as well, and hopefully even ported to Windows/Linux/Android to output their native GUIs.
[0] https://developer.apple.com/videos/play/wwdc2019/402/