>> Hi! Welcome to
Visual Studio Toolbox. I'm your host Robert Green
and this episode is part one of what winds up being
a two parter on Blazor, which is an experimental
technology that could revolutionize the web
development world. I had Sam Basu and Ed Charbeneau, here a few weeks back. They were here for the
Visual Studio Live Conference which was on Microsoft campus. I taped a bunch of
episodes with them and they wanted to do
an episode on Blazor. Unfortunately, I had a conflict and Dmitry wasn't available, so I left them alone
in the studio. They were so excited. They spoke for an hour, so we're going to cut that in half. This is the first half of them explaining to us what Blazor is. >> Hello. Welcome
to VS Toolbox show. My name is Sam Basu. Robert Green is busy, so I'm filling in for
the day and with me, I have Ed Charbeneau and we're going to talk about
something very exciting, especially in the ASP.NET land with Blazor and
WebAssembly, right? >> Yeah. So, I'm a huge fan
of Blazor right now. It's an experiment that's being worked on by
the ASP.NET Team, Daniel Roth and Steve Sanderson. They're working hard, experimenting with
this new framework. So, I'm happy to have
the opportunity come on Visual Studio Toolbox and kind of share that story with everyone. >> Awesome. Tell us more about. >> So, my name is Ed Charbeneau. I'm a Developer Advocate with Progress or you may
know them as Telerik. Sam here is a pro- a Developer Advocate
at Progress as well. Co-worker of mine and
we've kind of invaded the Visual Studio
Toolbox episode here, to talk about Blazor. So, I am an author,
I do some writing. I have a podcast
called Eat Sleep Code and if anybody ever wants to
reach out and get in touch, just give me a shout on Twitter. >> Okay. All right. So, let's dive in. What's
the hop loud sounds like? There are some very sharp
minds behind this at Microsoft and other places.
You should tell us more. >> So, as a web developer
that specializes in C#, one thing that I've
always wanted to have is the ability to write C# and create Client-side
applications using it. >> Okay. So, to kind of backup. So, with ASP.NET, is it entirely Server-side or we can do somethings Client-side but
it's all in JavaScript? >> Right now if you want to write an application that's
running in the browser, you're going to have to leverage JavaScript but there's
some new things that have come around with
WebAssembly, which is a- >> Okay. >> A way of natively writing
code for your browser, that it understands
using Web Standards, it's a bytecode format. >> Okay. >> So, it's similar to
an assembly language, but it runs natively inside the browser and the browser
understands it. So, we're starting to step away from the days where JavaScript rules the browser only and we're allowing some new
things into the ecosystem. >> Okay. So, from what
I understand like every browser has
a JavaScript engine right, V8, or Chakra, or WebKit and is these engines
that run JavaScript natively in the browser,
Client-side. So now we're saying there's something more that
the browser can run and that's the Web Standard that
you've talked about. >> Yeah. I want to point
out, this is a Web Standard. >> Okay. >> Because we've tried
some things like this before and well
things have changed. >> Things have changed.
So, maybe to backup. So, I'm actually a big fan
of Silverlight back from the days Flash was a plug-in. Sure, it had
some vulnerabilities. I think Steve Jobs kind of wrote a scathing letter onetime to say. So, essentially when you
run Flash on Safari, it makes your tiny iPad heat up and that not
something Steve liked. So, he essentially kind of kill the plugins model
and along with it, like, we never said
Silverlight is done but, we kind of stopped
talking about it and maybe the plugins model just
didn't scale for the web. So, now we're saying
"We're not going to do plug-ins. This is different." >> No. No plug-ins and
don't get me wrong. These were things
that were necessary at the time and people
were doing the best with the best tools
that they could, to build amazing applications. I'm sure there's some just phenomenal Silverlight
applications out there that people have built but now's the time to start
moving onto something else. >> Yeah. >> We're going to drop
all those plug-ins and just use things that the browser
understands natively. >> Yeah. With Silverlight though, I mean it wasn't
just the plug-ins model. Like people who did Silverlight, we just enjoyed
the Dev experience. The rich ecosystem. The data
binding with C# and Xamarin. I think as developers,
all of those skills, I mean they move forward with, be it UWP, be it WPF,
or Xamarin.Forms. So, you can build
cross-platform apps with the same skill sets. >> Absolutely. >> We're just trying
to see how we can bring that Dev module bag, the ease of using Visual Studio and C# but do it differently
in the browser, right? >> Right. >> So, let's start off
with no WebAssembly. >> Okay. >> How does the browser
work without it? So, normally we feed the browser HTML and
JavaScript pages. Those things go
through a parsing and then they're kind of precompiled. They're turned into
a JavaScript tree and the JavaScript engine inside
the browser interprets that into a bytecode. >> Right. >> So, it gets JIT compiled, turns into bytecode and then things happen
within the browser. >> Okay. >> So, that's kind of
where WebAssembly happens. What they've done is, think
of this kind of like, for lack of a better term
dependency inversion of control, right? >> Okay. >> So, we have this part of our browser that
understands this bytecode. What if we took that part
of the browser and exposed that to where
developers could target it? So, this is WebAssembly. So, we can target
this bytecode now and give that to our browser
and your browser understands how to
execute that bytecode. >> Okay. >> So when we do that, we open up that input to things like C++, Rust, Go, and our favorite C#. >> Okay. So, now you're
talking about like higher level
programming languages, been able to write things that we're going to compile down. Maybe not compilers. Maybe not the right word but, bring it down to that
low-level assembly ish code, which the browser can
execute on its own. >> Yeah. >> Okay. >> There's one more
clarification to make here. This isn't bytecode that
would run on your machine. >> All right. >> So, this isn't something
that's going to get loose and have security issues. >> All right. right. >> For example, library
that you send down, isn't going to be able to
access your system registry or run natively on
your Windows desktop. >> Okay. So, it is
still running in the browser shells, so to speak. >> It's very much sandboxed. >> Okay. >> The bytecode is only going to be understood by the browser. It's not something that's
used outside of the web. >> So, why should I
trust WebAssembly? Is this like a standard that the web community has accepted? >> Absolutely. >> Okay. >> So, this is a Web Standard. It's in all the evergreen
browsers and then, also if you have
another browser that's same, maybe on a mobile device. Some manufacturers that like to ship their own web browsers and those don't always have standards that are up
to what we expect. There are polyfills. >> Okay. >> That can polyfill
in WebAssembly. >> Okay. >> So, it will be compatible
with those as well. >> All right. So, you
mentioned like modern browser, so is that like Edge,
Safari, Chrome? All of their latest bits
will support WebAssembly? >> Yeah. So when we say something like an evergreen browser, that's one that doesn't
have a hard version number. >> Right. >> That we're tracking. >> It auto updates
from [inaudible] >> For example, like IE 7/8/9. >> Right. >> Or Edge. You're always
on the latest version. >> Okay. So, Apple is
on-board with this. Okay. >> Edge, Safari. >> Yeah. >> Chrome, Firefox. The big ones that many
of the users use, those are the ones that
you'd expect to have the native use of WebAssembly. Then the other ones like I
said, the polyfill works. >> Right. >> There's a little bit
of a performance gap obviously with
that type of approach, but at least your app works. >> Okay. All right. >> So, this is where Blazor
enters, the picture. Now, there's a couple of
modes of how Blazor can run. One of those is very new. So, we'll talk about that
in just a little bit. But, what I want to
focus on right now is the experience where you're
developing for the browser, the client and you're running the application
on the client. >> Okay. >> There is an opportunity
to run it on the server, and this diagram doesn't
quite fit that model. So, right now we're
talking client side. >> Why Blazor? What's
with the name? >> So, the Blazor name
came from Razor. So, we're going to use Razor to create our markup
for application, and then the Blazor part
of it comes from the- >> Is running it in the browser? >> Yeah, in the browser. >> Okay. >> So, browser, Razor, Blazor. >> I see. Okay. So, like
Razor is the syntax that we use to build
ASP.NET applications, be it MVC or ASP.NET Core. You're saying we're going
to use the same syntax, but it's going to just run
try inside in the browser? >> Yes. So, if we look at the diagram here what happens is, remember that model we had
before we're going to feed the browser HTML and
JavaScript only, now we're using
the Blazor framework, and the Blazor framework, it renders those
Razor CSS HTML files. Those get turned into HTML, which the browser understands. >> Okay. >> Then we take Mono. So, Mono the runtime that can
target multiple platforms, there are now
targeting the browser. >> Okay. So this is
Mono under the covers, and I mean Mono has been known
that is not a new thing. I mean Mono has been around
since .NET has been around. So it's the port of .NET
to other platforms, and that's how Xamarin apps run today on iOS, Android,
and other platforms. So, you're saying,
we will use Mono to bring your C# down
to WebAssembly? >> Yes. >> Okay. >> So, Mono is compiled
to run on WebAssembly, and then Blazor is a framework
that sits on top of that. Now Blazor is able to take, and load your DLLs
directly into Mono, and Mono is running those in an interpreter
into the browser. >> Okay. So, it's being
interpreted at runtime now but eventually we might have
a little more static compilation to make things a
little more faster? >> Yeah. So right now, this
is the way it's happening. I have spoken with
Daniel Roth and there are ideas around maybe collapsing this stack at
a final compilation stage, where all of
your application gets compiled into
WebAssembly directly. So, when it loads into the
browser it's at native speeds, and there's nothing inhibiting that direct pipeline
into the browser. The way this works now, this is a great development
experience because when we compile we're
compiling it to DLLs, and then Mono is handling that WebAssembly
interpretation for us. So, the compilation
time is very short. If we were to take our entire left application and compile it, that compilation time would
take quite a bit of time, and our development
process would be slow. >> Sure. >> So, this is a very fast way to iterate on an
application and build it, and then in the future
we may have that longer compilation to get the final package
tightened up and ready to send down to our users. >> Okay. I see a blazor.js, and mono.js, what are those? >> So, those are
intermediate layers for the browser to help do
things like JS interrupts, so we have a JavaScript
interrupt layer. So there are things that
WebAssembly doesn't support yet. So, there might be times where we need to fall back on JavaScript, so we can actually talk to JavaScript from
within WebAssembly. >> So, from .NET code, you're
going to call JavaScript, and back and forth? >> Correct. >> Okay. >> So we can actually do
that bidirectionally. We can call JavaScript modules and functions from within Blazor, and then we can also from JavaScript invoke .NET functions. >> Okay. >> So that's one reason those two JavaScript
files are there. The other part is just
loading the application hub. So, the mono.js takes and loads bootstraps up
the the Blazor assemblies, and then Blazor has
those interrupt layers, and communicates down through mono.js into those
interrupts directly. >> Okay. >> So we've got a nice
stack workflow here that we can build some pretty interesting applications already. Now it's worth saying
that Blazor is an experimental project still. >> Sure, for now. >> We are in release
0.5.1 as of recording. The first 0.1 release
was just in March. So it's only six months
old, it's a baby. It's got a lot of growing to do. >> But I here it's come a long
way. Its come in tooling. >> Quite a long way.
They are making some good investments in
producing this experiment, and it's nice to have this experimental phase because they're able to think
outside the box, and do some creative
experimentation with it, and not have to worry so much about breaking
changes at the moment. >> Then the community
gets to weigh in, we developers get to try
it out and see what works, and where the pain points are. So, back on this diagram. I mean this is
all client-side, right? >> This is absolutely
all client-side, and Blazor it can
run out of process. So we don't need to necessarily
be tied to WebAssembly. We can do it on the server, and we'll get into a project. This is actually something
that shipped in 0.5.1. >> It was very, very new. >> How we can run the framework
on the server side. So we don't have to
compile it down, and then send it into
the Mono WebAssembly runtime. We can use the regular .NET
runtime on the server, and then what we're going do
is open up a signal or hub, and communicate across
the hub to your browser, and do diffs between the browser and the updates that
we need to send. We'll get into that more, we don't want to get
too much going on. >> You'll mention
going on. Let's lock in the client-side first. >> So client-side, we've
got our Blazor framework, running on top of Mono, we're able to load DLLs
directly into the browser. >> Okay. >> Which is something
very new and unexpected. >> Well, it's curious
if I might say. >> Yeah, we will pull up the network traffic here,
and take a look and see. >> So what exactly
are you shipping from the service side when
you do Blazor apps? >> All of it. We are
shipping DLLs down to the browser and
the browser is able to understand how to run those DLLs, thanks to the Mono runtime. >> Okay. Hopefully, we're doing some work with linkers
and some tree shaking. So we are shipping only what we need and the client-side. >> That is stuff that is in
the works that's coming, yes. >> All right. >> So right now,
we're shipping down full assemblies but
soon we hope that Steve and his team will
come up with a way to create smaller DLLs and
ship those across the wire. >> All right. Let's hear this. >> So before we get started, we'll talk a little bit about the Blazor framework itself. It has a lot of those things
you expect out of a single-page application
framework or SPA framework. It has a virtual DOM. So DOM manipulation has
very taxing effort. So things like jQuery that
directly go in and modify, manipulate the document
object model in the browser, those things are sometimes
pretty inefficient. So, Blazor has its own shadow DOM similar to other SPA frameworks
like Angular and React. >> This almost sounds like a very SPA client-side
framework with some of the features like routing and layouts and dependency injection. >> So we interact with
this virtual DOM and then Blazor does diffing
between the actual DOM, and the virtual DOM. So it's only changing what it
needs to change rather than repainting that entire DOM
within the browser. >> Got you. >> So we have efficiency there, we have a component model. It's very Model-View-View-Model
type thing. This is something that developers from other .NET frameworks
would appreciate. Things like UWP, and
WPF, and Silverlight. It's not identical, but it has some similar type
of ceremony too. >> This is what we liked about
Silverlight development. This is the ease of doing data binding and XAML
tools, the ecosystem. If you're saying we can
bring some of it back, then yes. Let's do it. >> We have some layout
capabilities in there as well. Dependency Injection,
none of the box. Something that we'd expect
from a modern .NET framework. So, we have that as
well. We have routing. This very easily follows that Razor Pages type
of construct, where we can open up a page and have
an at page attribute. We'll show some of
that in a moment. Then, again,
the JavaScript interrupt is part this as well. So, we'll show that too. >> Okay. >> So let's jump straight
into Visual Studio. Now, I have some tooling
that I have to install. If you want to
install this tooling, you go to Blazor.net and just follow the step by
step instructions there, and you'll have the same tooling
that I'm showing now. >> Okay. >> So in Visual Studio, I have a file new project
experience for this. I am going to click on the ASP.NET Core Web Application
project template, and we'll just do "OK" here
to spin up a new project. Notice I have three
new projects in here. I have a Blazor, Razor ASP.NET Core hosted,
and Blazor Server-side. So, let's dig into
these really quick. >> So, before you do
that, this has to be ASP.NET Core 2.1
release and forward? >> Yes. >> Okay. >> As of now. So, as of
recording that's what it is. Visual Studio 15.7 or 8. >> Okay. >> Those instructions, again, are on Blazor.net.
You'll find those there. They may be updated
after this video airs. So make sure you
keep an eye there, but you do need to install these. You are not going to come out of the box in your normal
.NET Installation. So, our first project. Think of this Blazor app as
a client-side only template. So, if you were to
do this in, say, just normal JavaScript terms, it would be HTML,
CSS, JavaScript. Static files you've run
on your client only. Okay? So, now talk about
server interaction. You can still have
server interactions, but you do that through
web APIs and things like that. They're not included
in this project. >> Sure. >> The next one over is the
Blazor ASP.NET Core hosted. I like to call this
the full stack template. So this has the previous
project template, but it also includes ASP.NET Core and some web API end
points that we can hit. >> So that's like your backend
then for your app? >> Yes, and ASP.NET is actually hosting the application as well. With the first example, you don't even
really need a host. You just need somewhere
to stick your files, and it's just stuff
the browser understands, so it can pick it up and run it. >> Sure. >> Just like in HTML, JavaScript, CSS project you could
put it on GitHub, Pages and host it there. >> Any FTP server can just
put up to put down and run? >> Exactly, Azure storage. You can host your application
from using that format. The second one here though, this actually ASP.NET Core hosting the application for you. It also has a web API endpoint
for you to be able to hit, and it also has a concept
of code sharing. Remember, we're using
the same language now on the browser, client and the server. >> Yes. So, that's interesting.
So, folks doing Node.js, we are used to doing like
JavaScript front and back, and now we can do C# front and back essentially, right? >> Absolutely. >> Okay. >> So, that's where
that one sits. This is a brand new project. So, this is where, I talked about it
a little bit earlier, this is a server-side model. No web assembly involved, where the Blazor framework sits on the server
as an application, and the server connects through web sockets down to
the browser using signalR. >> Okay. >> Those packets with signalR are sent through a binary transfer. So, it's actually taking
the diff from your updates, your interactions, and sending
that up to the server, the server then processes
the changes in Blazor, and then Blazor knows
the diffs to make, sends that down the wire
in a binary packet, and then the signalR client picks it up and replaces what it
needs to in the browser. >> Interesting. >> So, it's a very
interesting approach to doing this type
of development. >> Yes. If you talking
about like server-side now, you're in Node.js territory, and you can think about
what this might mean for electron js apps maybe
that run on the desktop, but we'll get to that. But this is interesting, that we can actually host Blazor outside of the web
browser's process, and just do it all on
the server or desktop. >> Yes. It's extending
that UI thread across the wire instead of doing it right there in the browser,
on the client. >> Sure. >> So, let's actually jump into this first Blazor template. So, we can actually
show some code and how this stuff is structured. So, I'm going to spin this
up, File, New Project. Looking at our solution explorer
to see what we get. Some of these things
may seem very familiar out of the box
because they follow conventions that we already
use in ASP.NET development. >> In particular,
this looks familiar if you do any Blazor Pages. So, you don't have to
Model-View-Controller pipeline, you'd have pages, and that's where you
render things from. >> So, we'll start top down. We have our WW root. >> Okay. >> So, this is just like
you would find normally, this is static resources
for our application. >> Okay. >> We go to pages. Like you said, Blazor Pages,
same idea here. We have all of the features
of our application. People like to talk about
apps and features now like we want to
have, in this case, our component feature and
our fetched data feature, and we can dive into those files
here in just a moment. Then, our shared libraries, our shared views,
same concept is ASP.NET. We have things like templates in our main layout and we can
even have a view imports file to do those global using statements and bring in component libraries,
and things like that. >> Okay. >> Another familiar concept
is the startup in program.cs files that you
find in .NET Core projects. Those are the things that
bootstrap your application and configure
dependency injection, and all those great things. >> Okay. >> So, let's give this guy a run. We'll get this started and
kick it off in the browser, and then we'll go look at the code behind it and
see how this works. >> So you're running
how this in IS express, but you just said it may
not need any of that. >> Yes. We don't really
need to do all that. We could host this on
GitHub Pages if we wanted to. These are all static files
that we're using here. So, we get our Hello World app. We have a couple
of features here, we have our counter component. We can click and
increment a counter. >> You're not coming
back to the server. >> So, no. There is no server. >> Okay. >> We're not doing
any data transfer across anything right now. We have a fetched data, but it's all being
handled locally. So, we're just grabbing
a JSON file and just pumping the data
into the application. So, we're grabbing
that static JSON file. It's not coming
from a web service or anything at this point. So, right now it looks like
an average application, but let's see how it's built. So, let's dive into some
of the features here. Let's open the counter
component or the counter page. You'll notice right
away the Blazor syntax. It's a .cshtml file and it uses
very familiar conventions. >> It does, yes. >> At the very top,
we have a router. So page is at
the counter endpoint. So if we go to counter in a browser that's
where we end up. >> That routing is built-in. >> No, routing is built
into the framework. So, now we have
just simple HTML here. We have our header tag, and then we have
our current count. Then we're using Blazor here to display a value
of currect count. >> Sure. >> We have a button to click, and then we have a event
binding to the on-click event. Then we have
a function block here that has our functionality
for this page. So, there's our current count
that's being bound up here, and we have our event handler
for the increment. >> Okay. When you
say at functions like that's C#, right? >> Yes. This is Blazor, and everything inside of
this block is C# code. >> Yes, yes. >> So there's no JavaScript
at all on this page. When we click the button, it invokes this increment
count function and its data bound to this
current count value. So that's the view
that we see here when we click this button. So we're able to do that
with very little code. There is no post backs
going to the server, it's all being handled locally on the client in a very easy
to understand fashion. >> Okay. So, if you go back
to the browser for a second, so you said it has a Shadow DOM but
there is a DOM out there. So, if you right click,
you'll actually see HTML. >> Yeah, absolutely. >> Okay. >> So, those CSS HTML files are being rendered
out into the browser. So, we use bootstrap rows, your links and your buttons
and all those good things. Let's actually jump
over to our network tab while we're in here and just
do something interesting. Want to do Empty Cache
and Reload. When this comes down
across the wire, notice that we're
actually sending DLL files from the server. >> Little scary. But
it's here. Lets see. >> These all get loaded
in through web assembly and our applications spins
up and it's all client side. >> Okay. >> So, we're actually
running these DLLs locally on the client. >> That's very interesting. You literally shipping
.NET DLLs to the browser. >> Absolutely. >> We would figured
out at runtime. If you look at the sizes, this is where you're saying
it'll get better. Like we'll ship smaller
and smaller as we go on. >> Yeah. Right now you
can see that we're shipping the .netstandard
dll and mscorlib, all these things as
a whole across the wire. I would imagine, I'm not on the dev team just
for clarification. But I've had discussions
with Daniel Roth, the PM on the team
and he's ultimate about making these things smaller and more compact when
they go across the wire. >> Sure. >> So let's jump back
into code again. We'll take a quick look
at the fetch data. This is the view that, if we click ''Fetch Data'' here, we have a little bit of a grid showing some data
that's coming in. The first thing I want
to point out again, we have routing and then
underneath routing we have this @inject declaration up here. >> All right. >> So, this is
actually calling out to the dependency
injection system and it's asking for the HTTP client that's registered
independency injection. So that's going to
get resolved and then down in the
code of this page, you'll see we use
that HTTP client to go to a file on local storage. >> Okay. So, you're
not going anywhere, it's just a JSON that
you are loading. But you could go across
the network if you wanted to. >> Absolutely, we
can make requests to the backend services and
all those type of things, and we're doing it in
a familiar .NET way. We're using HTTP client and
doing a GetJsonAsync to pull in a object type of
an array of weather forecasts. So, there's JSON binding that's happening
automatically in here. So, we don't need to even worry about those type of things. >> Sure. >> Then there's our weather
forecast object right there. So, we're getting
these values and just mapping those values from the JSON into
this object and then we iterate over those in the view. >> So at this point, would you say these are views or would you say
these are components? >> So these are both actually. So we have the concept
of a page here. We're using this app page
directive with the routing, but I could actually
come into my home or my index and let's wipe
this component out for a moment, and I can come in here
and type in counter. Notice that nice IntelliSense
come up and we'll close that tag and I'll come back
to my browser and refresh. Let's go home and wait
for it to refresh. We're getting a message. I'm actually in debug modes. Let's actually run
this a different way. Let's do a Ctrl F5. So we'll run without debugging. So we can refresh
this experience. Now, remember this is
an experimental project. >> Oh, I see. Okay. >> So, the debugging experience right now is little lackluster. There's some work
being done to make debugging available
in the browser. We can actually at
current state, set breakpoints. >> In C#? >> In the browser, we
can set breakpoints. We'll look at that
in a few moments, because I don't want
to get too off track. So, at some point, we'll be able to debug
C# code in Chrome or IE. >> Wow. >> At current states not quite there, but
it's getting there. So back to talking
about the components. >> See you have the counter. >> Take that entire page,
use it as a component. >> I see. That's not something you are able to do
at all in ASP.NET, MVC, or Core, or Blazor. >> That is right.This is
a new component model. >> It's literally
a component. So, this is like in some ways like
Angular and React, you just literally plopping
a component down into a page. >> Absolutely. It's very similar
concept to those things. You could say it was inspired
by or borrowed from those. Which those things inspired by and borrowed from
things like WPF. >> Absolutely. We rediscovered the same problem
so and over again. >> So let's have a little fun with the counter
component that we have. We'll go back to this page here and let's set up a property. So we actually have
a shortcut for this now in the tooling and we can say
instead of prop tab tab, which we might be
used to do this, we can say parameter tab tab and now we get
the Parameter attributes, and then we can expose
a property on our component. Let's call this CountBy. So this is an integer that
will set to be CountBy. Instead of just incrementing
this internally, we can just say,
plus equals CountBy. We might want to set
a default value here. >> What if someone does
not pass in the parameter? >> So we'll do that. >> Okay. >> I saved it. We'll go back to our index and now
we can say count. I may have to recompile here. Let's do a build, and now we
can do CountBy. There we go. >> Very interesting. >> Now are IntelliSense comes up, we need to build
that library out. I can set that to an integer of five and we'll save this
and we'll refresh our page. >> So, if I'm getting this right, so these are
individual components? So the actual counter should
still increment by one, but this one should
pick up the parameter? >> Right. So, the instance of the counter on my index page, counts by five and
the instance of the counter on the counter
page is only counting by one. >> Sure. >> But now we've extended that component out and
actually made it a little more robust where we can have a developer experience
where you can type in and get IntelliSense and
set variables and properties on the object
or the component. >> This is very cool. >> So, very simple component
model to understand and it's absolutely simple
to get up and running. So, let's take a look at
the other project type. >> So, that's the first half of a four hour of Sam and
Eddie, talking about Blazor. The next episode of
Visual Studio Toolbox, will continue on with
their conversation.
