
SwiftWebUI - tambourine_man
http://www.alwaysrightinstitute.com/swiftwebui/
======
Razengan
SwiftUI, and the underlying system for embedded DSLs that it's built upon, is
pure genius.

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/](https://developer.apple.com/videos/play/wwdc2019/402/)

~~~
mda
This all looks like Flutter to be honest.

~~~
dep_b
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.

~~~
mda
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.

~~~
akmarinov
Isn't Flutter just a reimagining of React Native anyway?

~~~
hajile
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.

~~~
gurkendoktor
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.

~~~
zapzupnz
> 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.

~~~
gurkendoktor
> 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](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.

~~~
zapzupnz
> 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.

~~~
gurkendoktor
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.

------
ben1040
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/)

~~~
dmix
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](https://en.wikipedia.org/wiki/280_North,_Inc).

~~~
mpweiher
They hit 1.0 in April of last year.

[https://www.cappuccino.dev/blog/](https://www.cappuccino.dev/blog/)

------
applecrazy
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.

------
saagarjha
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.

------
mark_l_watson
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.

------
pavlov
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.

~~~
andrekandre
well, to be fair, react wasn’t exactly completely new with its idea either...
what’s old is new again

~~~
yogthos
Sure, but it is one of the most popular way to develop web apps today. So it
seems kind of relevant to contrast against it.

------
dawkins
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.

~~~
mtrovo
My first thought also. Also I remember some of the design documents of JSF, it
was designed to enable views to be rendered everywhere (Java ME, web,
desktop). It only added complexity and in the end nobody used it because the
paradigms are so different.

~~~
ZitchDog
It also scaled poorly.

------
dmitriid
> 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.

------
catchmeifyoucan
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.

------
davidkhess
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](https://doc.qt.io/qt-5/wasm.html)

------
tluyben2
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!

------
thomasfl
Maybe Apple should bless this project, by letting it use the name WebObjects?

------
cerberusss
I'm looking forward for a connection between SwiftUI and GTK or Qt, so we
could have a fully functional user interface on Linux.

------
rebelnz
Coming from a job working on a WebObjects behemoth this is terrifying for me
...

~~~
mattl
What was the job?

------
ragerino
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.

------
gumby
This is great -- I was sorry not to see the web target at WWDC, especially
given Apple's WebObjects history.

------
pabl0rg
Looks like vaadin or kweb

~~~
chii
and the OG of them all, GWT.

------
skocznymroczny
So this is basically Flutter but for Swift?

~~~
augustl
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!

~~~
kenshi
> 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?

~~~
chrismorgan
See [https://flutter.dev/web](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.

~~~
augustl
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 :)

