We're going to continue in more creative uses of Go.
Most people use Go, microservices, Kubernetes stuff, servers, whatever, but usually not
user interfaces. Every year there are a few crazy people who come to talk about some crazy
new front-end thingy built in Go, and I personally always like it.
So I also invited Andrew this year to talk about Logoad graphical interfaces in our
favorite language Python. Go!
And I'm a boss.
Thank you very much, Dave Matcha. So yeah, I'm going to talk to you about Logoad graphical
applications. So on two levels there's not going to be much code on screen. I think I
actually have less code than John's description about how to get involved in contributing
earlier. So let me see how I can do it. However, what's a pretty picture, so hopefully I can
keep you engaged in that way.
So yeah, hi, my name is Andrew. I am a software engineer, working various startups. I've written
a couple of books, and occasionally appeared on podcasts and interviews talking about graphical
app development with Go. It is exciting to be here on stage at FOSDEM. I've been coming
for decades. Having been an open source contributor for years as part of the Enlightenment Project,
Maven, all sorts of things that potentially predate and certainly stand outside of the
Go ecosystem.
More recently I started the Find Project. Perhaps a few of you might have heard about
this. It's a way to build native graphical applications using Go that are going to work
on any device. If you've never heard of it, I'll do a quick recap. If you have, just hold
on a second and I'll move on to some new stuff. I've been a Go developer for about two weeks
less than I've been working on the Find Project because we had an ambition of what we were
going to do, and then we figured out what language is going to work to deliver on these
ambitions. Hopefully everybody agrees, it goes just a fantastic choice. How did all of
that come together, and what are we building on top of it? My day job is at Fine Labs,
where we're working on products and services that help businesses get more out of the type
of technology that I'm presenting today.
Like I said, the Find Project started in 2018, and it over that time has aimed to be the
simplest way to build native graphical applications. They should look good, they should be easy
to build, and they should work absolutely everywhere. Of course, easy to build is relative. We've
had great feedback from people who have never coded Go or who have never built an app before,
but there's plenty of people out there who feel that that's a little bit overwhelming
to learn, they don't want to be a coder, they just want to build stuff. That's why I'm
talking about something a little different today, about building with absolutely no code
at all.
But before I do, here's the recap for anybody who's not familiar with Fine. It's been running
now for six years, I can't believe it's been that long, but hey, it's come a long way.
We're currently ranked around sixth of all cross-platform graphical user interface toolkits
by OSS Insights. That puts us up amongst some other names that you might have heard like
Flutter or React Native, and of course I should probably shout out to Wales as well. They're
very popular, lots of different ways to build in modern toolkits and actually in Go. So,
variety out there. Last week I was really excited to realise that we have become in
the top 1000 GitHub repositories of all time, out of, I don't know, 350 million or something,
long tail perhaps, but it's a little bit of a milestone, very exciting to be celebrating
that.
We have about eight core contributors, they come and go. This year has seen a lot of new
contributors coming in and as part of the Go community, it feels like a really welcoming
inclusive space and we have some channels on the Go for server, we have a Discord for
people to chat and there's about 2000 people across the different platforms that we are
discussing on. But that is enough about the technical side and the project, which if you're
interested to hear more about, there is a talk in the graphics dev room tomorrow afternoon
at a similar time. I wanted to talk today about not using code to build applications.
So, I'm going to introduce you to a tool called Fission. The spelling is just as peculiar
as the fine project, but why not? This basic screenshot is not going to reveal too much,
I'm going to step through a little bit of what is capable of it, but more how we pulled
it together and how it has really been enabled by the Go built-in functionality and what
we have been able to build on top of that. This is the screen that you might be greeted
with, if you do load the app for the first time, it is going to help you get started
building a project.
So what did this set out to achieve? There's so much that we could do and probably I should
have thought twice about getting into the space, I think there's 130 to 150 no code,
low code platforms out there, but if you've ever tried them, they're mostly building websites
or web technologies and if they're apps, they might be bundling them up into native
installs, they might be targeting specific platforms or they might be reliant on technologies
that I might refer to as legacy or certainly not with the same awesome modern tooling around
the Go community does. So we wanted to do something new, something that was truly building
native apps, like I said before, fine applications are going to compile and run on any device
with a screen, at least that's the ambition, we're about 95% of the way there. So we're
wanting to build native apps, but also we want to make this really easy to get started,
with easy to build stuff, so as much graphical editing as possible, as you would expect from
a low code platform, we started with the UI and the theming capabilities, so although
the application has got a long way to go, as you might see, there's something to get
started right away, it should always be building on a real code base. So if you don't like
the front end or you want to work with a team of developers just loving Go at the low level,
you should be able to work with them collaboratively through the Git repository, for example. The
applications should compile for all platforms, but also this should run on all platforms.
We're making use of our own technology, if you want to build an app for an iPhone, but
you want to do it from an Android tablet, that's cool. If you want to use Windows as
your development environment, but target only mobile devices, that's just grand as well.
Little tweak on the bus, because you know the boss was expecting something before you
get in in the morning. Of course being at FOSDAM, everything that I'm showing you today
is open source, it's going to remain open at the core, but some days companies want the
business add-ons, the plug-ins, so we're going to be using this as open core, but like I
said, nothing that I'm showing today is proprietary or held back. The repositories are evolving
and some of them are not landed in the right place yet, but I'll point you in the right
direction at the end of the talk. Like I showed you at the beginning, we're going to give
a UI that allows people to get started with templates to get their application running
really quickly, but also you could build an application completely from scratch if you
want, with the building blocks that we've provided on top of Git repository for managing
the source control. But there's so much to get started with building your first project.
I kind of don't want to say that. When I started it was super easy, you opened a text file,
wrote a couple of lines in there and then you just ran it. I mean it felt a little bit
like a script, but really good solid code. I've opened a few issues upstream with the
project team about why has modules made things difficult to get into? Workspaces are amazing,
but it's more metadata. We're going to have to manage that for you, but that's exactly
what's going to happen. You tell us what your application is going to be called and we'll
generate all of the metadata, set up the modules all for you. The metadata about the UI, about
the themes, everything you're editing is going to be stored in the source control as well.
So if you decide that you want to work, like I said with somebody else who's not on top
of this UI, you can pick up absolutely that code and work with it. But also we want people
to be able to pick up this project having worked on the code directly for a period of
time. So not like a project where you can really quickly pull together a user interface
for an application and then export it. It's amazing, you've got a React Native app out
the other end. Nobody can read it and if you want to start working graphically on it again,
you're possibly going to be starting from scratch. I don't know. Anyway, so everything
is synchronized with the source control onto the file system. So we are working on a Go
project. I did promise something a little bit graphical. So here you have the first slightly
better looking screenshot I think. We're going to be working just now on the theme. We have
a pretty crude mock-up of a smartphone device here, a generic one. The cutout is somewhere
between a magical island and a place where let's face it, cameras exist and we don't
need marketing about it but it's there. The UI is going to allow you to see how these applications
work on mobile device, smartphone tablet or a standard window, inset inside the application.
It's going to handle the scaling, the alterations that you would expect for these different
types of devices. But also we need to present in light and dark mode. So you can see a toggle
at the top of the color picker on the right hand side. All of this lovely information
is just saved directly to JSON. We've used the standard encoding package that Go has
provided to save it to the wonderfully comprehensive file that you see illustrated on the right
hand side. That wasn't easy. Go made it super easy, completely built in. But then we needed
to load that data into the application that you're building. We didn't want to do any
weird generation of things, stuff that could get in the way of working on code like you
would in a real code base. So we just store the file there and embed it into the application
using Go embed. I haven't realized how easy it was to work with this. I'm going to call
it new functionality because I work a few iterations behind the cutting edge because
we're trying to support as many devices as possible. To be able to stream this most effectively
into your application, a fine app can have its settings set to a certain theme. You just
call set theme. But it doesn't really expect a JSON file. It expects some Go code, a struct.
We provided this from JSON functionality in the package scene. You can see here illustrated
how we can provide both light and dark alternative colors for applications. Less so well illustrated
here is that you can work with fonts, icons and the different sizes. Everything that makes
an application feel the way that it does. We've got a bit of a look. You can imagine
how that file might have your brand identity or something stored in it. You can port that
across multiple different applications. Widget editing is the other thing that I feel is
actually quite an enabler on a UI like this. If you're thinking about building out your
first graphical app and you're looking at fine and you want to use Go but you're not
quite sure how to get started, something like this, just this one screen could provide you
with the graphical editing that helps you to understand how things are put together.
The functionality in the user interface here is mapping to the APIs that are available
if you're looking at this as a developer. Actually, let me just go back a little bit.
I'll show you a little bit more later. You can see basically here there's a section highlighted
on the user interface. We've selected that and down on the right hand side it is giving
you the different areas of settings that are available plus the option to insert more things
into your user interface. I feel like I've said a little bit too much about JSON already.
The fact is it's really super helpful. I don't like to read it. I don't know if it's the
win but I'll agree with the folk that perhaps suggested that XML was a little bit cumbersome
in comparison. We use it again. Actually, it is great that Go not only supports serialized
using something like a map to JSON but we can because we have a stateful widget toolkit,
we're able to serialize the entire state of your application the way the widgets are positioned,
the containers around them and the metadata for them streamed directly to a JSON file.
Again, illustrate it over there. There is also a little blank field on line four for name.
A chance to put an identifier on your widget so that you can hook it into code later because
this is a low code solution. We know we haven't solved all of the problems and you might want
to write a little bit of Go so you can hook into that through the name which is going
to be exported as a field on the application which I can show a little bit more in detail.
As part of the Find project we've created a library which did start out as a project
a little bit like this but now has shifted focus to helping more applications to load
and save graphical state. It will also allow you to understand which widgets are available
so you can iterate through. You can, at runtime, create new instances of an object based off
some textual representation or just ID of the object type that you're looking to work
with which, as you can imagine, pretty helpful if you're trying to generate at runtime a
user interface that's normally compiled at compile time.
One thing that I find really quite surprising, in fact I don't know how many people have
realized this but your objects and types in Go in memory can be written out to Go code
to reconstruct them as though they were source code. That's pretty cool. It's like stringer
but it's go stringer. Has anybody heard of go stringer? I'm really curious about that.
Right cool. So hey that's really interesting. Anything that you have in memory pretty much
can be serialized as the Go code that generates it. You may need to write a little bit of
code to make that fully functional yourself but we built on top of that. That means that
every time you save your user interface state it's not just saving JSON but it's spitting
out the Go code that will generate the application source code so that you can be working with
developers but also so you can actually compile and run it.
Which moves on to compiling applications. Now it goes amazing at the cross platform
compilation, portability building applications for anything but there are certain requirements
when it comes to building native graphical applications. Partly they want metadata around
them but partly people who own certain platforms put licensing restrictions in place and require
that you run on their hardware or with certain toolkits present so there's a little complexity
here. The project that I've presented and will illustrate uses local developer tools
so you're never beholden to anything at all. If you've got stuff installed you can build
the application that you have coded and have it run on the local system and install it
into your applications directory or the start menu whatever the equivalent would be on
Windows at the moment. For the local system that's really quite straightforward, the tools
are there. For cross compiling we've had some really great contributions to the fine project
called Fine Cross from Looker and Jacob and Cedric as well so that you can with that level
of simplicity build for any platform. It pulls down images with all the developer tools installed
that you would need but even then you still need to have it running on a Mac to do iOS
development or on a Windows box to ship off to the store so I'm not going to say this
is proprietary but if your business was interested in something that just worked in the cloud
there's going to be an option here that, good timing, there's going to be an option that
allows you to spin up basically a pipeline in the cloud. It sends the latest version
of your code and it comes back to you with the native app bundles for store deployment
or ad hoc distribution and also included in that we have support for over the air self-update
of application software as well. This little diagram here is something I created a while
ago to try and explain to people why platform agnostic development or building with a tool
chain that works on any platform makes a really big difference. If you think this would help
to convince people to use Go More in your organization there's a couple of postcards
over there next to the stickers and on the other side there's a couple of really sweet
doodles which just show how coding nirvana can be achieved so hard level tooling, cute
fields. Lastly before I actually show it in action there's a project out there called
Fishos. Again you might get the theme here with the FY starting of the name which is
a Linux desktop operating system that is built from the basic graphical level all the way
up entirely with fine and fine applications. We're moving to all of the applications being
created or editable with vision not just with source code so that you can be very well
running your desktop software and go I actually think that this could be tweaked with something
wrong here I can improve on it and you could go and edit the software that you're running,
load it in the UI, make some modifications and then install it right back over the top
of the software that you're editing before. If that sounds really interesting well we're
working in that direction you can head over to fishos.com to see where things are. There
is a beta ISO, stick it in a virtual machine nothing more and some of this functionality
is not in the version that's there yet but keep an eye out because this is all coming
very soon to a platform near you. With that I thought I might just try and show you that
this works and bring up the UI editing and application of my system here.
I have the bar of icons on my installed system here. I see this calculator app. It's nothing
special, it's a calculator, it's going to calculate some things. Clearly there's some
things in this that could be improved for some reason I think that's true. Let's actually
go ahead and look at how this is. We can edit the calculator application and it's going
to load it in the editor that I showed you. I was demoing this for somebody else just
immediately before so it's defaulting to smartphone apologies for that. Of course we're really
working in desktop software so this is the more familiar button size, text size button
size that kind of thing. This C button, it doesn't seem to be quite right, it's very
vague, I feel it should be a robust red warning. It is a warning, it should be a danger button.
Let's really indicate that there's a problem likely to happen if you press this. You might
be one of these people that thinks that clear isn't quite substantial enough so all clear
or AC might be more familiar to you. We also could look at the layout of our application
expanding down here on the containers. If I tap this, this tap here, this is a two item
grid, I think it's this container here. I could do something a little bit bizarre and
make those rows wow. That did make sense from a mathematical point because this is a new
and evenly spaced grid and I just asked it to do something a little bit daft but actually
the columns were just fine so we can go back in there. This application obviously it's
just a quick editing in line. I want my app, I want to test it, I want to run this piece
of software so I'll test, run, I'll press run. It's going to go and okay I forgot to
save the file. Sorry I should have asked if anybody realized what I'd done wrong there
and offered a prize but it's happened to me once before and it will happen to me again
I'm sure. So there you go it has compiled the application and built it natively onto our
system. That is a live native application compiled for the current system but it is
just a binary where it's a single binary as any good go application would be running
off our hard drive but actually what I wanted to do was commit my really significant improvement
to this calculator app to my operating system and so I'm going to use this other developer
button called install and it is just going to improve every day of my life now so when
I go back to my calculator app over here I now have a new version of this little piece
of software and I just feel like this has been a big improvement for me. Hopefully you
can imagine a lot more possibilities and you see the next project that you're going to
build and I would love to hear about that. Anyway let me just, oh by the way if you really
like building applications you like mark down and think it's the future of all good things.
This slideshow application is a fine application called Slides with a Y of course and it's
just marked down. Anyhow sorry I'm pressing the wrong button aren't I? There we go. If
you would like to learn more about this that I have showed you and please do check it out
any feedback that you have. It's early days but we're looking for people to get involved.
Beta testing.app is the homepage for everything that we're doing. It offers you links to,
I feel like some surveys let us know what you think is going to be useful. Sign up to
beta testing when it's available and the second link there is actually not connected to that
app website. We recently completed some user interviews and got some really great feedback
about where the opportunities might exist in this area. If you're at Intrigue we're running
a questionnaire based follow up so the second link there would be really interesting to
get your feedback. Like I said this is all open core and everything so far is fully open
sourced under the BSD license. Actually it's dual licensed with GPL as well for the licensing
of business add-ons later but it is all out there with a compatible license. If you would
like to see the source code which I didn't tell you about but honestly is there fully
available and pretty straightforward you can go to our YouTube channel. There is a video
series called Creating an App Builder I think. We used to do them weekly and then moved to
monthly. There are 11 videos there that take you through almost all of what you've seen
demonstrated earlier and the source code is currently in the tutorials repository because
we're just working on neatening up the first iteration of the actual product that I just
demonstrated to you there. But the majority of the code as I said been through the videos
is available in the tutorials repository. Hopefully that's been really interesting.
I'd love to take questions now but also like I said there's these little weird things out
there but if you're interested in building the future pick up one of these stickers and
slap it onto a laptop and tell the next person how it is that Go is going to be the next
future or the best, brightest future for graphical application development. Thank you very much.
Did you all just realise we just saw an operating system user interface completely building Go?
Yeah. Wow. I'm shocked.