>> 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]