Choices in Desktop Development

>> There's a lot of ways
to build desktop apps,
and on today's Visual Studio Toolbox,
Sam Basu will share his thoughts
and help make sense of all
of the options. [MUSIC]
>> Hi and welcome to Visual
Studio Toolbox, I'm your host,
Robert Green, filling in
for Leslie this week,
and I am very excited to
have as my guest today,
Mr. Sam Basu. Hey, Sam.
>> Hello, sir.
>> Sam is a Developer Advocate at
Progress and also is
half of the answer to
a trivia question which is who are
the only two people
who never worked at
Microsoft to host a Visual
Studio Toolbox episode.
>> That's very true.
>> It's Mr. Sam Basu
and Ed [inaudible]
>> I loved the Channel 9 Studios.
I loved being there and we're
missing out, but hopefully someday.
>> Yeah, someday.
>> Until then, we're at least
online, we get to hang out.
>> Exactly. Today, we're going to
talk about desktop development.
Now, we've heard for years
and years and years that
the desktop is going away,
but somehow, it never does go away,
it's still here, and
there's a lot of options.
In only 15-20 minutes,
we're going to review the choices and
the options and you're going
to give us your take on it.
I know there was a .NET focus
on Windows about a week or so ago.
How about maybe you could give us
just your high level overview
of what's going on in
desktop development and
what are all the options
and what should people do
when you think about doing?
>> Sure. I think it's
a fun time actually.
Let's bring up my desktop so we
could talk through some
of the options here.
First off, we're
talking about hitting
the desktop as a .NET developer.
There are other ways and
the things you can do.
But to me, right now,
this is a lot of flexibility,
but I also understand
why it brings it
a little bit of confusion
because, we developers,
love a lot of choices until we have
too much choice and then we're little
crippled and we
second-guess ourselves.
The good news is everything
you know and love,
it's going to stay the same,
and then you can learn new things
as you target newer things,
like you said, like desktop power
so many enterprise workflows,
it's not going to go over anywhere,
we're just making the story better.
Let's wrap on Windows.
How can you build
Windows Desktop Apps?
There's lot, the traditional ones,
those are still there
and running strong.
Windows Forms, that's probably
about 17 years old now going
strong, very, very productive.
WPF, probably about 15, and again,
super-rich XAML,
C# based code base
that you have, an
ecosystem and the tooling.
Both of those things are so strong
and they don't need to
be like the old school,
10-year-olds WPF or WinForm sub.
They could look more than fresh and
they run on .NET Framework full
which is where they have always done.
But you can run them on .NET Core,
you can run them on .NET 5,
and moving forward .NET 6.
There are some .NET upgraded
systems that are in the
works so you can bring
your older applications
to the modern world and
utilize all of the APIs and all of
the beautiful new UI that you have.
All of that is here to stay.
Universal Windows
platform, that is to
know the way for you
to build desktop app,
and that's not again going anywhere,
but this reaches to
HoloLens and Surface
Hub and all of the
other Windows devices.
Then if all of it is confusing,
I can see that because, again,
the same term has been
interchangeably used.
We also have Windows UI,
which is very exciting.
WinUI 2 was a different thing.
It was a UI stack just for UWP,
but WinUI 3, which is actually at
the time of we are speaking here.
It's still in preview,
it's meant to come
out by the end of March in 2021,
and then flourish and
go GA after that.
That is a whole UI stack
that actually promises
to run on both Win 32,
so .NET Runtimes and .NET 5 and 6,
but also UWP, which is .NET Native.
You got the best of both worlds.
You can bring in C#,
you can bring in C++.
That's all the Windows
and XAML [inaudible].
>> You can also bring in the Uno
platform and go cross platform?
>> You could, if you wanted
to take the Windows XAML,
if you are really tied to it,
then yeah, Uno platform
is your choice.
but let's hold onto the
cross-platform story because I
think that is getting a
lot more loved this year,
in particular with MAUI.
But just we're going
to wrap up some of
the other choices you
have because, again,
as a developer working
on an enterprise,
you're likely not just
building one thing.
I always say take a look around
as to what else are you building,
where can you share code,
what else is your team
comfortable doing.
So if you're into web stuff,
you should be looking at web stuff.
You can build progressive web apps,
which are essentially
web applications,
and that you can install
them on a desktop.
You don't quite all of the features.
You're still within
the browser Sandbox,
but it is a start.
Then Electron is also
a very good option and
it's been battle-tested,
it's been around for a while.
If you look at some of
the major applications
like Teams, and VS Code,
and Slack, and Figma,
all of those are essentially web apps
running beautifully on desktop.
That's through Electron.
It gives you that shell and it
gives you some deep OS integration.
Now, if you did not need all of that,
what you can get away with and
what Electron makes you do
is bundle in Node.js and
the runtime and Chromium,
the browser engine so your app always
has the confidence knowing
exactly what it's running on.
If you didn't need that,
maybe you can get away
without doing it.
That's where some of the other
newer options are coming in.
If you still wanted to do Xamarin
or XAML essentially but you are
not so tied to the Windows XAML,
then Xamarin Forms has
always been an option.
You could reach UWP
with Xamarin Forms,
you could reach WPF apps with
Xamarin Forms because essentially,
you're rendering native UI
from a Xamarin Forms UI Stack.
But the two nearest things that I'm
actually personally
most excited about
are what's called Blazor
on desktop or .NET MAUI.
To your point, Robert,
Blazor gets a lot of love,
and again, you can
build web applications
that are now running on
desktop but not through
the Electron Shell.
We are using the most modern
web views in every platform.
That's web view 2 on Windows
and then WK web browser on Mac.
You're essentially spinning up
a Blazor application just
like if we run on the web,
except now it's within
a Window Shell.
Then .NET MAUI, that is
cross-platform stories.
Uno platform is great
for what it does but if
you want to have all the confidence
of .NET backing you to go
confidently to Windows and
Mac and iOS and Android,
then .NET MAUI is the story,
which is, again, still
very early days.
We are at preview one right now.
In November 2021, you will
have that fully baked in.
Essentially, it goes to
Windows through WinUI,
so you are absolutely
native on Windows,
so I think it's just a lot of choice.
>> You say it's true
that there's still
basically two ways you
can approach the desktop.
One is you're doing WinForms
or some variant of XAML,
whether it's WPF, or it's UWP,
or it's WinUI, or in Xamarin Forms.
It's four different types of XAML.
But XAML is XAML,
if you know one, you
can print the other.
>> Exactly. Well said.
>> Everything you need
to know to do WPF,
or UWP, WinUI or Xamarin forms.
If you are only on WinForms,
you got to learn XAML, you got
to learn something sometime,
or you come at it from
the standpoint of
you do well and now you've
got Progressive Web Apps,
Electron as Node.js or Blazor,
primarily aimed at web folks.
Is that a true statement?
>> It it absolutely true.
Essentially, pick your poison.
Do you want to web stuff or do you
want to do.NET and XAML stuff?
Either way, you're going to be fine.
That's a good happy story.
>> Me, I've been traditionally
a desktop developer.
Of course, I've dabbled in web stuff,
mostly for demos, but
I don't really know
the web stuff all that well.
I know the desktop
stuff and I've done
every desktops when forms was
invented because I'm that old.
But I can build awesome applications,
I can build cross-platform
applications,
I can do pretty much
anything I want to do,
building on the same skill set
that I have had all along.
Then similarly, for a web developer,
there's all new things you
can do including Blazor that
leverage the skill set you've
always had so you don't have to,
as a desktop developer,
learn a web stuff to me current.
If you're a [inaudible]
that desktops stuff to
be current. It's still true.
>> Yeah, very much.
It's not just Blazor.
Maybe you are coming from
a completely different
JavaScript background,
angular view react,
all of the spot traditions,
they're all welcome.
They will run just fine.
Again, so far, what we have
talked to is just the Windows,
which is majority of desktop apps,
at least from our .NET ecosystem.
But if you want to
bring up my screen one
more time, there are others.
You can actually very
easily reach macOS now
and Linux for the hardcore folks
who were under the desktop.
This is all .NET as well and
this is all web as well.
If you want to do web,
Electron is welcome.
If you want to do XAML and C#,
then Xamarin.Mac has
always been there.
You also have some macOS renderers
that sit on top of Xamarin.Forms,
which is simply what plays a Mobile
Bindings is doing right now.
But eventually, they will
sit on top of .NET MAUI.
One other thing that they
are talking about opening up
is .NET MAUI but
through Mac catalyst,
which is essentially Apple's way of
running iPad apps on the desktop.
Because Apple has a similar problem.
They don't have a lot of
folks wanting to build for
their Mac desktop so they're wanting
to get iOS apps to run on desktops.
Probably another way for
.NET MAUI to help out.
Again, if you're running on Linux,
then you do have renderers again.
I think as a .NET developer,
this gives me a little
bit of joy that
my codes just goes to so many places,
and like you said, you pick whether
you want to do web stuff
or you want to do .NET.
>> Yeah. It's interesting
that we still make the
distinction between
desktop and web and
mobile when if you think
about it, it's just apps.
They're apps, they have a UI,
and they talked to
some data somewhere,
and there's code that
links the two up,
and then you have
various screen factors,
whether it's your surface
machine or your Mac,
or your phone, or your other phone,
or someone else's
phone, or your iPad.
I've got Windows, and iPhone,
and iPod, an iPad, and an Android.
I've got those all in the house
and I want the apps to run on
everything because if I'm
sitting here on my phone,
I want to be able to call it the app.
Right now, this is an Android
phone but I am thinking of
switching over to an iPhone
as my primary phone.
But it's still my phone,
it's still a computer, it
should still run apps.
>> Absolutely right. Most
of what you're saying,
we can do right now,
I mean apps are apps.
You can put things in a shell
that you can run it on desktop.
You can put things in WebAssembly,
run it on a browser.
I think where do you see
some of the edge cases
is what exactly is your app doing.
If you are really into
somewhat touch features,
you might want to
choose something that's
a modern platform
that runs as touch on
touch friendly devices or as
mouse and keyboard on desktop.
Or do you need a very fast rendering
engine for a modern browser,
you might want to get a new web view.
But if you think Robert about some of
the really intense
desktop applications,
like graphics applications,
those are actually
little intensive on your CPU and GPU.
They're very busy in terms of the UI.
Some of that is still a
little hard to do on the web.
It's not undoable, but it's
just takes a lot more work.
So I think desktop is here to stay.
Enterprise line of business apps will
always power workflows
and through desktop.
>> Totally, definitely here to stay.
But the more you can,
let me expand the types of
apps I build without having
to throw out stuff I already
know or learn something.
Now, of course, I'm always interested
in learning something new,
but I got a lot of years and a
lot of us have a lot of years and
experience and knowledge
in building desktop apps.
I don't want to start
from scratch and
become a rookie web developer
when I'm experienced.
I won't call myself an expert,
but an experienced and
the stuff I already know.
>> That is the good
news. Your expertise,
your investment, your
knowledge doesn't go away.
You need to be open
to a little bit of
evolving of your knowledge to
targets and new frameworks.
But like you said,
like if you do XAML,
like as a developer,
like I get the annoyances that
XAML dialects are different,
but like how difficult is this,
it's just pure XAML and maybe
some namespace there different,
maybe some things that
called differently.
But a XAML codebase is a
XAML codebase with C#.
So I'm glad.
>> I think about all the
people that learn C#.
I was a VB guy and then I learned C#.
I learned C#, I can XAML,
I can learn a different XAML dialect.
You learn an entirely new
programming language.
Then learning XAML, which
particularly if you know
HTML or played around
with HTML because they're both MLs,
they're both markup
language because they
both essentially do the same thing.
Then you know if one variant of XAML,
you can pretty easily move
over to the next one.
>> Exactly. Again, if you
have your fundamentals
in place, like if you,
a lot of like XAML and
C# based code bases,
you use like MVVM design pattern,
which is design patterns but
nothing to do with the
specific framework.
You'd known one and
you're good to go.
You can switch it on
with other things.
You can have the sanity that
you want in your code bases.
>> Obviously, some of these
are getting more than others.
I don't want to put this.
Let's switch. Some of
these things are new,
like blazer, for example,
give us an overview of its evolution
in the past year or so and
where you see it going
and what types of
scenarios it's going
to be optimized for.
>> Blazor understandably
is very exciting if you're
a.NET developer doing
any type of web stuff.
Blazor is super exciting because
you are either server-side,
laser enabling line-of-business
applications over a signal,
or a bridge, or your true client
side with WebAssembly running
everything in the browser.
So it's obviously exciting and
the Blazor ecosystem is pretty rich.
You have folks like us building
Telerik UI for Blazor.
There is a lot of help with UI and
tools and ecosystem. It's very rich.
We can bring all of that
knowledge and all of
the folks who do web
stuff into other things.
Because we talked
about desktop today.
It's not just desktop
or we can also run
Blazor apps on mobile as well.
I see this as an
exciting opportunity.
Like folks on the Blazor team
and.NET teams are
obviously excited about
this because it enables
all of that Blazor code,
this C# and Razor syntax to now
just suddenly run very nicely,
very smoothly on desktop and mobile
and we can also mix and match.
You can now also render native
stuff with some web stuff.
It doesn't need to be
completely a hybrid app
that is just running web,
you can mix and match.
>> Where do you see
it a year from now?
>> I would say a year from now,
Blazor is going strong on the web,
but the desktop model has
been a lot more flushed out
and we're able to go past
some of the wrinkles.
Performance is solid and the
thing we don't always talk about,
some of the pinpoints
are on the edges.
If you are running a
Blazor app on desktop,
where is your child script
bridge or your interrupt?
Because what if you
brought in something
where you have some JavaScript,
maybe it's a web app
that you're bringing it
in and you want to enable that on
desktops and where's
your JavaScript bridge
is the runtime optimized
to do touch over that web
browser, the web view.
So there are some
nuances that need to
be flushed out, but it's exciting.
So a year from now I
want to see Blazor
fully working and being super
performant on desktop and mobile.
>> Then last question, what about
the XAML spaces WinUI, the
one XAML that rules them all.
>> It's hard to say. I think that's
what the team is hoping to do.
But again the reality is like,
there are too many enterprise
apps that are still being built
on WPF there is nothing
wrong with WPF.
There's nothing wrong with
Xamarin Forms either.
So I think if you want
to like my two cents,
if you want to stick
to Windows with XAML,
pick either WinUI or WPF,
you're going to be fine either way.
If you want to go cross-platform,
you get .NET Maui.
>> Then is that Xamarin
Forms, is that WinUI.
>> It's Xamarin Forms. But again,
that's just one slice
because .NET Maui
wants to open it up to
other things as well.
Essentially, Blazor
running on desktop and
mobile is essentially
running om .NET Maui,
there is MVU C# pattern that
is also welcome to build apps.
So .NET Maui is not just C# and XAML,
but if you are doing C# and
XAML, it is Xamarin forms.
>> Cool. We did it
less than 20 minutes.
We summed up the wonderful
world of desktop development.
>> I think it's exciting.
>> It is. Of course, as
you mentioned before,
there's still the rich third-party
ecosystem of the control vendors,
you guys, the others.
Lots of good opportunity for
people to build modern
and very exciting apps.
>> Absolutely. Look around
is what I always say.
Before we started greenfield project,
look around into what else are
you doing, how can you co-share.
Always look around to make
sure you have the right tools,
the right UI you
choose the ecosystem.
Then once you've made the
decision, go all in. The good news
is the tools are so good on
almost every stack that you
are set up for success.
>> All right, thanks so
much for coming on and
sharing your thoughts with
us, Sam. Appreciate it.
>> Thanks for having me.
>> Hope you guys all enjoyed
that and we will see
you next time on
Visual Studio Toolbox.
[MUSIC]