 Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green and joining me today are Sam Bazoo and Ed Charbonneau. Hey guys. Hey Robert, thanks for having us. Sam and Ed are developer advocates with progress. And I've asked them to come and join me today so we can talk about modern web development. And this all started from a conversation that we've been having about the state of the web. And we're going to approach this today from a couple different angles, one of which is somebody who's doing web development, web forms and MVC and probably keeps up with the latest version of Visual Studio. But there's a lot that goes on in the web. And this concept of modern web development, there's a whole bunch of things that you should probably know about if you're doing web development. The other side of it is somebody like me who is traditionally a client developer. What happens if I want to or find that I need to start building web apps? I mean, I know about ASP.net. I know about web forms and MVC. But I haven't really kept up on all the things that have been happening since then. So what am I in for? It's quite a ride. It's a gigantic thing to dive into. So we're going to, in a somewhat ambitious episode, cover what you could spend all day talking about in one episode of Toolbox. And we'll try to keep this to a manageable length. We'll do. All right, again, thanks for having us on the show here, Robert. So like you said, I'm Sam Basu. And you're at Cherubino. We are both developer advocates at Progress. And I think we have a really cool job. We get to evangelize Telerik products, which many, many developers love. So he's the resident web expert. So I'm mostly fluff. He's the stuff. So we'll talk about some of the overviews and we'll let him kind of dive into some of these demos. But essentially, like you said, modern web is a gigantic thing. And you might be scratching your head to figure out where do I start. And even if you're doing web development today, are you doing the latest and greatest, are you keeping up on top of it? So we'll try to kind of take a broader overview, look at things, all the different frameworks and tooling, and how that applies to Microsoft Stack. If you are coming from a Microsoft background, I think all three of us here share like a .NET experience and desktop experience. How does all of that translate, if at all, to the modern web world? And I think a lot of it does. So the green text here with the ad symbols, that those are our Twitter handles. So feel free to grab us anytime. And both of us blog at developer.telerik.com. That's where you'll see a lot of A-SWIT.NET content and a lot of .NET content. So if that's of interest. We'll put links to all of those in the show notes. Yeah, absolutely. So I know we are developers, so we'll keep the slides to a minimum. We'll jump into kind of demos. But just to kind of get the feel of it. So the web is I think the only thing that's ubiquitous. It's everywhere. It runs on every mobile device, every platform you can think of. So how can we make the web nice and great and welcoming to everybody? So let's talk about some frameworks. Let's talk about some tooling as to what the modern web looks like. So what does it really mean to be a modern web developer? And I think this definition could kind of go either way based on if you're talking to an enterprise .NET developer who is doing 9 to 5 A-SWIT.NET in Visual Studio versus a complete hipster in skinny jeans with his Mac. So the definition really depends. But I think there is something to be said on both sides of the field. And I think there are similarities we can draw and their best practices are from both that we can take. And I think most modern technology stacks that do web, you'll see a mix and match of some traditional server-side .NET stuff and then some JavaScript. So let's kind of dive into this. So a little history lesson for the kids. Ed here is old. He possibly started his life with GeoCities and stuff like that. I don't go that far back. But if you look at like the early 2000s when A-SWIT.NET or A-SWIT Classic first launched and then we had A-SWIT.NET. So at that point of time, it was very much a server-side web. We rendered everything on the server side and then we shipped it off to the client, HTTP. We shipped off our HTML. And then on the client side, the browsers weren't very smart. So the user did anything on the browser. It came straight back to the server and we were doing more churn, more processing on the server before getting back. So that was okay, but it doesn't scale really well in the modern world because browsers have come a long way. And I think where Microsoft fits into is we started off with ASP when we were doing a lot of desktop dev. So we tried drawing some similarities and we tried taking some of our experiences doing WinForms onto the web. So the web forms were designed to be familiar to a WinForm developer. Similar paradigm, it wasn't supposed to look like something dramatically different. Right, and it worked for the first time. Under the hood where things ran was different, but the development experience was purposely designed to be very simple. Since we're talking about history too, you have to remember that JavaScript didn't run the same in all the browsers either. There was like almost no standardization. So writing JavaScript back then was an absolute pain. Mm-hmm, yeah. So I think along the way with ASP.NET. And it's not a pain now? Yeah, well. It's a different pain. It's a different pain. It's a whole different pain. So I think along the way with as ASP.NET evolved, as the web evolved, you also saw .NET evolve for not just the web, but everything else. So starting with .NET 2.0 all the way until like 4.5 where we are before 4.6 came in, we have a very rich ecosystem in .NET. And there's something to be said about that. Our tooling in Visual Studio is top notch and we have a very strong ecosystem of support utilities and frameworks and some of the best tooling that's out there. The one thing to pick about .NET is it still was one giant monolithic framework. So the .NET that runs your WPF apps versus the .NET that run the web is the same. Right. So that gave the IT admins some pain because upgrading the .NET framework wasn't easy job because you were always scared of breaking things. Yeah. So those were some things that kind of went into this thinking of we need to reboot and we need to do better for the modern web. And I think this is one of Scott Hanson's quotes. The JavaScript is the assembly language of the web. It's really hard to not do JavaScript because it is everywhere and browsers have come a long, long way. You can literally look at a browser as a mini VM that does everything it can install apps on its own. It's got its own store storage and app life cycles and everything. So that's where the web started. And this is where we are at today. And it's complicated. It's very complicated because we have dug ourselves quite a bit of a hole on different fonts. But it's all for the good. The intentions were good. It's just the implementations and the pure number of frameworks sometimes kind of bogs us down. Yes. Choice is a good thing except when it becomes too much choice and then we are not sure what we should pick. So I think server side web is still a thing. Mm-hmm. It can very well coexist but gone are the days where the user clicks on a drop down and you have to come back to the server because we want things to be much more interactive fast. So the browsers have come a long way. Let's do more on the client side. And that does mean JavaScript frameworks because that's what the client side is. Most modern technology stacks I think are kind of a mix and match of some server side and some client side stuff. JavaScript frameworks like I said, it's a lot of JavaScript frameworks. Like every morning there might be a new framework but some of the core, the big pieces are there and they're there for a reason because they solve very specific problems and we as developers should not be trying to reinvent the wheel because the large frameworks have already done that for you and they can happily coexist inside of Visual Studio, inside of your... So which one is the largest? We'll talk about it. Okay. There are things like Angular and React and Ember, there's a lot of it and they can all coexist. Okay. All right, so my two cents would be just pick something that really works for you, something that you understand because we also see this in the enterprise and some hipster worlds where people pick up a framework just because it's cool and everybody's doing it. I don't think that should be the reason. It should really solve a thing that your technology stack is demanding and then you're picking up a framework that really solves a problem for you and take it from there and your experiences as a team kind of go into this decision of what your technology stack looks like because otherwise you're going to be signing up for things and maintaining the code base that you don't like. So MVC is that a framework or is that a pattern? What would you call that? I'll let you answer. It's a little bit of both. So MVC itself is a design pattern but the .NET MVC or ASP.NET MVC is a framework that's built on that app. And is that a server side framework as opposed to a client side framework? Yes, it's very much a server side framework. So you're rendering the HTML on the server and sending that down to the client. So all the HTML renderings done there and you're passing some JavaScript along as well that runs on the client. So was that not... But everything's coming from the server. So was that not modern web? It's modern now but it's not the future of the web. So the future of the web is more client centric where all of the client processing is taking place and mostly you're just calling back to web API endpoint and just getting data. Okay. I think MVC still has a solid place in the modern web. I think it's just how you use the framework is what defines your stack. So maybe you use MVC to expose like web APIs from your server side and you come back from the client side to just access those APIs. And some of the bigger pieces like things like a grid, if you put that on a page, there's no reason why you cannot do it from the MVC side because the grids have JavaScript embedded in them so they can do client side stuff. Okay. There's trade-offs with all of this. I mean if you put too much on the client and you have a device that's not very powerful, then you're gonna run into a lot of poor performance. So like Sam said, if you're sending this huge grid down and all the logic for the grid is in there and all the API calls for the grid is in there, you're not gonna have great performance. So sometimes it's good to render those things on the server and send them down or sometimes it's good to do a little bit of both. Yeah. All right, so let's kind of dive into I think the more things that are more pertain to us like as dotnet developers, like we both come from a heavy dotnet background. So what is Microsoft doing about the modern web? Where is dotnet? Where is ASP.net headed? I think you'll enjoy the things that Microsoft is doing to kind of get ASP.net developers up to speed so that we are doing the right things and we are not even understanding the language that the hipsters are speaking. We should be doing similar things. So I'm really fond of where dotnet is heading, I think. You'll see that there might be a few forks in the road with the different dotnets right now, but if you look at just pure dotnet core, which is the new version of dotnet, it's really wonderful. It's a big endeavor on Microsoft's part to kind of reboot something that is so intrinsic to so much of enterprise business, but dotnet core is lean and it's modular, so it's not a giant thing anymore. You literally pick and choose what you need for your applications. Less dependencies, you can package of the whole framework with your app, so it's easier to update your app and the framework. And for the first time, it's cross-platform, right? So we also want to broaden the funnel and invite everybody else into the dotnet and ASP.net stack because why should a college kid with a Mac not be welcoming the ASP.net line, right? So let's invite everybody. So along that way, you'll see some command line tools. We can come back. The JavaScript hipsters, they do command line all day. We were a little afraid of command line because Visual Studio for the last decade, it has kind of shielded us from command line. It did stuff in PowerShell when you did like a package manager console, but for the most part, we didn't have to. But if you look at what's common between Windows or Mac or Linux, if you're truly doing development, it's command line. It's the same thing that works everywhere. So dotnet actually supports a very nice command line interface so you can get started on any machine, really. So here's a quick look at the different dotnets that we have today. So dotnet framework, as we know it, that's the giant thing that still exists and it will do forever. And it runs all of your dotnet applications, your desktop, mobile web, everything that runs on dotnet. That's full API canvas and it runs just fine. Dotnet Core is the new kid on the block and right now it's got console, ASP.NET Core, UWP, few pieces running on it. You will see more and more efforts. Like with dotnet standards, 2.0 coming along the line, you will see a lot more parity between the APIs on dotnet framework and dotnet core. And then there is Xamarin, which was something Xamarin joined Microsoft earlier in the year and I think this is fantastic because it helps you complete that dotnet story. For the first time with dotnet, you can target everything, iOS, Android, Windows, Mac, you name it. So I think this is a great time to have this nice structure around dotnet so you can target so many things. Along the lines comes dotnet standards library, which is more of an API canvas so you can have standardization between your different dotnets. So there is no reason, like if I'm building a Xamarin app, which does not have device dependencies, there is no reason why he cannot use one of my libraries in his web app. So that's what dotnet standard brings in. It's just a standardization. What's the difference between that and a portable class library? So a portable class library had the right intentions. You literally chose which devices you wanted to pick and you started with the lowest common denominator. Like you picked, the more devices you picked, the lesser and lesser your API became and then it was the common thing that was across all. This is more of a standards definition. So if I say my application is built on dotnetstandard1.0, I'm not saying it's tied to specific devices, but any device that can host dotnetstandard1.0 and above should be able to utilize my library. So it's not more of devices, but it's more of the families and kind of making it a standard for every application to kind of share and make things portable. Is it still gonna be only include the things that run across all those platforms? Do you wanna speak to that? So it depends on what version of the dotnet standard library you're running. So if I wanna go for all the devices that Windows phones and all of those devices, I would choose a lower version of the dotnet library because it's gonna have the most compatibility across all those platforms. The higher up you go in the versions of the dotnet standard library, the smaller the set of devices that you're gonna support. But the difference between portable class libraries and dotnet standard is like, what is it that we are standardizing? In portable class libraries, we tried shipping libraries and frameworks that were tied to specific devices. While here we are saying, let's generalize dotnet as a whole. And let's figure out whichever device runs whatever version of dotnet. If you're talking my language, then I have access to your APIs. Got it, yeah, okay. All right, so moving on. So now we come to the web part of it because ASP.NET is moving right along. And I think ASP.NET for the big part is the driver behind some of these changes that you're seeing in dotnet. So we are really dotting the funnel. ASP.NET 4.6 is the next iteration of, or the next production version of ASP.NET. This is the full ASP.NET as we know it, runs everything from web forms, MVC, the whole stack. And it runs on dotnet 4.6, which is again the full dotnet framework. ASP.NET Core 1.0 is again new. We're actually at 1.1 right now. This is a slightly older one. So this is again new and it's lean and it's meant to be cross-platform. So you can now do native ASP.NET development on a Mac, on Linux, which is great. And you have support for containers like dockers and things like that. And it runs on either dotnet 4.6 if you wanted the full framework or dotnet core if you just are okay with the leaner version. So you get some flexibility with ASP.NET as well. And we'll show you some of this code and how it looks like on my Mac versus on Visual Studio on Windows. So JavaScript, the big kid on the block. This is where I'm gonna toss most things to Ed here. Don't resist. That's my one mantra because it's gonna be everywhere. All right, so you cannot resist JavaScript. It powers the web. Yes, it powers the web. But you can mix and match. Choose a tech stack that you really understand and it works for you, right? So I'm gonna try to maybe boil down some things that modern web developers do or care about and we're gonna try to maybe break it down. So first is some core frameworks. And these are not small frameworks, these are big frameworks maintained by big companies or individuals, most of them are actually open source. The reason why these things exist is they solve very real problems. Like how do you do data binding? How do you do model management? How do you do view state? How do you do routing? Navigation, all of those things are very real and it's stuff that most modern web developers need to care about as they move between pages and manage state and so on. So I'll let him talk about Angular in more detail. I think he's got some demos, but I think most of them solve similar things like knockout and backbone and they were mostly about following the MVVM or MVC type patterns, right? And Aurelia and React and Angular are new. React kind of, there's more to the component model. So you're building web components with HTML and JavaScript and reusing them and creating your stack from there. And I'll let him talk about Angular. You wanna quick shout out? So Angular, again, you mentioned the MVC pattern. Angular is an MVC pattern. So you've got an MVC pattern on your server with ASP.NET MVC and then you also have an MVC pattern on your client with Angular. So Angular has models, views, controllers, routing, all the things that you need to build that client application. So this is where we see a lot of just calling back to ASP.NET Core for web API endpoints and a lot of the stuff being handled by the server. So I think next up comes some of the sort of smaller frameworks, but they're super useful. And I call them UI frameworks because they largely solve the UI problem on the web. I mean, gone are the days. So before we move on to those core frameworks, do they all work with Visual Studio or some working better with Visual Studio? If I had to choose one of these, I'd wanna know which ones are the, is it easy to use? Is it popular? Can I go learn about it? And does it work well in Visual Studio? And I guess, is it gonna get knocked out of the lead by another one anytime soon? By knockout, maybe. I'd say right now, Angular 1.X is going to be your most popular JavaScript framework that Visual Studio developers or .NET developers are using within Visual Studio. And you're not gonna see any kind of hiccups or rough roads with that, but Angular 2 is brand new. So it just came out of beta late last year, 2016. So the tooling is under development right now. And we're gonna show some demos of how that works today, but it's very early in its stages. So some of its beta or its preview releases of the tooling. So it's not 100% perfect, but it's got some really cool things that they're making that possible in Visual Studio that I'll talk about. The next biggest one would probably be knockout that's been around for quite a while, and knockouts one that was based off of some MVVM patterns that were used in .NET. So .NET developer actually came up with the knockout. Now keep in mind, Visual Studio isn't one thing anymore. So the Visual Studio that we are used to on Windows does JavaScript just fine, actually. You get beautiful intelligence if you have your references right, but Visual Studio is also VS Code. Visual Studio is also Visual Studio preview for Mac. So those things handle JavaScript beautifully. And I mean, most of these frameworks, we are talking about just bringing in references and writing JavaScript. So you should have a decent experience in almost all of them with Visual Studio, some a little better. So next up are some UI libraries. And these are popular ones, of course, jQuery, gone other days. I mean, people will exaggerate that jQuery is dead, but I don't think it is. I mean, we don't want that cross browser incompatibility anymore. We want our controls to look exactly the same and behave the same in all browsers. I think jQuery, when it first came out, did just that. We have Kendo UI. Most of it is actually open source and free for you to use. So don't reinvent the wheel. Stuff about the UI, modern controls, they have all been done and they are open and free to use. So pick up what you need to. What does Ionic fit into this? Because I know the Taco guys, the Cordova guys are pretty big on Ionic. Is that, should that be one of these? I'll let you maybe correct me if I'm wrong. What Ionic is more of a mobile framework. So they are doing hybrid mobile apps with web technologies. So they're picking up on Angular and they're rendering components and they're making things work mostly for the mobile devices. Okay, so that brings up an interesting point then because you build a Cordova app with HTML and JavaScript. You build a modern web app with JavaScript. Is the JavaScript the same in if you're building a mobile app versus a web app? The language is the same but the APIs are going to be drastically different. Okay. A lot of times the frameworks that you use would be drastically, would be different as well. Most of the time, yes, because you're interacting with different sets of hardware. So you might be writing against plugins that talk to an Android device, to the camera, to storage and things like that. Whereas when you're writing JavaScript on the web, you're interacting with the DOM or rendering templates. Okay. Now, having said that, I will say there might be some overlap actually. So for example, with Kendi UI, we have like a dozen or so mobile specific controls because when you're building hybrid apps, what you're essentially doing is rendering your apps instead of a giant web view. Right. It's one giant browser. The user doesn't know it and if it's packaged up right, they won't notice. Right. So with some of these like modern UI frameworks, you can render the same controls on that web view and some of them are customized to be nicer on mobile devices because they fit better on a mobile device form factor and you go from there. I mean, your app model might be different but you can reuse some controls for sure. Okay. Yeah, and things like Bootstrap, I mean, they've been around. So if you are just making a vanilla mobile web, you don't have the time to make an app, not even a hybrid app. If you just want your app to work on every mobile device, do something about it. It's 2017. I mean, there is no reason you can't, I have to like pinch and zoom on your mobile app, right? So there are frameworks that will render your controls according to what device you're on. Okay. So we can read the browsers, what browser it is and render accordingly. So do something about it. While you're on the subject of Bootstrap as well, you mentioned, you know, jQuery is not obsolete by any means. Bootstrap still runs jQuery and even the newer version of Bootstrap that's still in, I think it's still in alpha, Bootstrap 4 is also based on jQuery. So it's not going anywhere anytime soon. And Visual Studio Templates will actually drop Bootstrap and jQuery for you. Yeah, in most modern ASP there are no applications. All right, so those are some of the bigger frameworks and pieces, but essentially, when you talk about modern web, we are looking for tooling that really works everywhere, right? So we talked about CLI, how that is kind of common across different platforms. What we also need is some flexibility. We cannot be just doing Visual Studio and think that there is nothing else. Visual Studio is absolutely awesome, but there's a lot of other stuff around. So they tell me. So they tell me. So they're lightweight editors. Like VS Code, for example, it's very lightweight. It's just a few megabytes compared to gigabytes of Visual Studio download. And it's an atom shell that's bundled in into an electron shell to make it a desktop app. And the lightweight editors, maybe they don't have as much features as Visual Studio does, like not the whole testing deployment, not the whole gamut of things, but just to write code and have unit tests run it somewhere. It's actually nice. It's nice. So I have to address the elephant in the room. If you haven't done Visual Studio, like HTML and JavaScript development since like VS 2012, things have gone a lot better for developers doing web development. You've got IntelliSense and the HTML. You've got IntelliSense and JavaScript. You've got auto-completion of HTML tags. It's nothing like it was years ago. So if you haven't picked up Visual Studio in a while, it's time to revisit it. Yeah, and we are hitting 20 years, Visual Studio 2017 launches in a few weeks. That's awesome. All right, so the next thing you kind of- 15 years of .NET too. Absolutely. Yeah, that's big. So the next kind of big things that you have to target whenever you talk about modern web is your dependencies because you will rarely have one framework that solves all of your problems. You will have to bring them in. And that's where we talk about package management. And this is where I think we have a big hole for ourselves because when we use a package manager to get another package manager and things get made up very quickly. So Nougat is what we are used to as .NET developers, right? It's the place that hosts everything. I think Nougat's intention is changing up a little bit as you go along with .NET. So we'll talk about what .NET Core does, but essentially .NET Core broke down .NET into smaller pieces and Nougat is one that brings it down into your app. So Nougat is going to kind of pivot itself to host mostly .NET stuff, DLs, and stuff that .NET developers care about. And for the longest time, Nougat used to host some web stuff, but I think for the most part there were like shims over stuff that was hosted elsewhere. So I think they're gonna get away from that. There was a lot of repackaging. And with ASP.NET Core, you're gonna see that go away. And the client side package managers like Bower and NPM are gonna be providing those web frameworks instead of Nougat. So NPM, Node Package Manager, it's the comparable thing to Nougat. It's where you go to get your libraries and your frameworks. Bower is where you go to get all of your web stuff, all of your JavaScript stuff, because NPM serves some server-side stuff as well. And then do you wanna talk about webpack? Yeah, so there's a lot of packaging tools that you have listed there. You've got grunt and gulp. So these are like build tools where you bundle up lots of JavaScript dependencies and put them in a single file so you can access them from your application. So webpack is another one of those, but it's a little more advanced. So it's able to go through and resolve all of your dependencies. And it can find out if you have duplicate instances of those dependencies and it does things like tree shaking to resolve those. And it gives you a nice small bundle of exactly what you need in your application. Do you see why these things are needed, though? Because if you are building an ASP without an application, remember there are lots of things you do before it's deployed. You minimize your JavaScript, right? You clean up your CSS. You bundle things up, your images and stuff like that. So those are things, some of it is built into MS build as we are used to. We just know ASP.NET takes care of it. The moment you step outside of ASP.NET, you don't have those things anymore. So you need something to get the job done. And this is what JavaScript developers do. Just on the server side, we're used to having the compiler do all this stuff for us. And in JavaScript, there's no compilers. So things like Webpack will go through and wherever you have import statements in your JavaScript, it'll go back and resolve those dependencies for you just like the compiler would with import statements in C sharp. Okay. Questions so far? Be good. So this is kind of a rundown of most common things that one needs to keep in mind. I'm not listing all frameworks because there's literally dozens and dozens of other frameworks, but just broader things that you need to keep in mind to build up your technology stack for a modern web application. All right, so let's move on. Visual Studio. This is something that's red and butter for all of us. What can Visual Studio do for you? Turns out it's several different things now. We have Visual Studio for Windows, which is the giant thing. We are hitting Visual Studio 2017. I like these other two things because I'm on a Mac. Visual Studio code, it's beautiful. It is absolutely beautiful. It's lightweight and it does ASP.NET beautifully. It does node beautifully. It does debugging and all of those things very nicely. We had Xamarin Studio for Mac. If you're doing Xamarin development on a Mac, but Visual Studio for Mac is in preview. I think at this point, it does similar things to what Xamarin Studio does. But I think, I mean, who knows what the future holds. So I think Visual Studio has a family. Well, it also does the web stuff, which Xamarin Studio does not. Exactly, ASP.NET core. So I think you'll see Visual Studio also kind of adopting the modern web and developer mindsets, not being the one thing that everybody has to adopt. It's targeting to different audiences and letting you pick what you need. So we already spent quite a bit of time on slides. Let's jump into some real action. So I'll let him show all the Visual Studio stuff and then at the very end of it, I'll switch back and show some cross-compiler stuff. But before we start or get going in the demos though, we work for progress and we make the Tilleric product line. DevCraft is our entire.NET bundle for all things.NET developers. It's not just web desktop, it's also mobile and we have also done not just.NET, but we have native apps for native controls for iOS, Android, and Xamarin and so on. But this is where everything starts up, DevCraft. Then particularly for web UI suites, I kind of circle that. You see the breadth of what the modern web looks like. Just in our DevCraft portfolio, you have Kendo UI which is plain JavaScript HTML, and then you have wrappers that render Kendo UI from the service side, from be it MVC, be it JSP, PHP for the two people who are still doing Silverlight. We got this sweet for you. Then Ajax and Webforms, I don't think it's dying. It's not a part of.NET core, but it's got a long shelf life because billion-dollar enterprises and businesses run on Webforms. So just in our portfolio, you can see the breadth of what modern web looks like and we try to make sure you have UI controls for whatever you're doing. Cool. All right. So just another quick rundown. So you'll see that our Ajax and MVC suites were for 4.x, and then for ASP.NET core, we have a whole other suite that just target.NET core. So Ed, I'll let you take away. Okay. So what I really want to show today is how Visual Studio really helps this modern web development cycle. So one of the first things I want to do is, is just fire up a brand new ASP.NET core application. Okay. So I've got my new project dialogue open, and I'm just going to go in and select ASP.NET core web application. Just hit okay on this guy. So is a.NET core application automatically a modern application? It's going to be a definitely like now application. This is modern as in today current stuff, and then there's some more stuff that I'll show you later on that's kind of the future of web development with Angular 2 and Webpack. Okay. So this is kind of like the tip of the iceberg, it's a good transition. Modern web apps without using Core, right? Oh, absolutely. Yes. This is a good transition point though, where we still have all of the server-side rendering. We have jQuery on the client, and anybody that's familiar with ASP.NET MVC today, should be able to start on ASP.NET core application and just pick up where they left off with just a little bit of learning. So you'll notice right away if you're a former ASP.NET MVC developer, there's a lot less choices here. So they've combined a lot of things in ASP.NET core. Web API and ASP.NET MVC are now one thing. We still have two project templates for those. This is specifically if we're just going to be developing web endpoints and just sending data back. If we choose web application, this is going to give us our server-side rendering of HTML views. So I'm going to choose that and I'm also going to choose some individual user authentication. I like to do this when I demo it because it spins up a little bit of NAD framework, and it shows you the file structure that comes with NAD framework. It also gives you a way for users to log in, you can see how authentication is done. So we'll go ahead and spin this up. While this is creating, I'll go over the project structure because it's changed quite a bit since ASP.NET MVC four and five. So we have some new things in here. So if I open my solution explorer, you'll see right now it's still restoring some packages. So it's going out to Nuget and pulling some things down. Which is a change by the way. We are not dropping the whole dependencies right in your project. We are just going off a list of things that your app depends on and pulling them down. Okay. So if you're used to ASP.NET MVC four or five, right now you might be looking at this project tree and wondering where some of the files went. So we're missing some things. Some of the things that are gone are the content and scripts directories. Those are actually moved a little bit. Another big one is the global ASAX file. So this is where all your startup routines used to be. This is gone and I'll start walking through some of these and show you where these things have gone. So a new folder here, www.root. We used to have a content folder, and this is where the client application stuff used to live. So our JavaScript, our CSS files, those are under www.root now. So you can see we have CSS folder, JS folder, and this is all of our client deliverable stuff. Okay. We also have a new dependencies node. So this is where we mentioned very early on in our conversation that Nougat was kind of phasing out some of this web client stuff. So Nougat is going to be.NET centric now. So we're going to get DLLs and .NET frameworks from Nougat, versus getting web frameworks from Nougat. Since those were just repackaging of things that we found through NPM and Bauer anyway. So if we look under our dependencies node, we have a Bauer folder, and if I open up this tree, you can see I have Bootstrap and jQuery, which we talked about. So those are coming from Bauer package manager instead of Nougat now. So you can see already Visual Studio is pivoting, because we realize that modern web does bring in stuff from Bauer. So why let you go and forcibly get them from Nougat? Go get them from where they're actually hosted. Yeah. A lot of it too is dry. Like, don't repeat yourself, right? Why take something that's hosted in GitHub and through Bauer and NPM, and then put it in yet a third place that has no way of updating itself. These update when the projects update in GitHub. So we have our dependencies here. There's actually some management tools underneath of this node as well. So we can come in here and we can restore packages, and we can also open up. Which is nice, by the way. Like if you have a dependency, it can just restore itself and bring up to what the actual package looks like. So I meant to right-click down a node. So if I right-click on Bauer, I can do manage Bauer packages, and then you'll notice I've got a nice package manager screen, just like I would get for Nougat. Right. Okay. So we have those dependencies. Notice there's no NPM in the dependencies tree yet, and I'll get to that in a moment. So we have some things that we're fairly familiar with. The model view controller pattern is still here. So we have controllers, we have our models, we have a new data folder. So NAD framework has changed quite a bit. I know Julie Lerman was on the show prior to us coming, and she talked a lot about NAD framework and the changes. Migrations have changed, so you'll find a folder under the data structure, or data folder for the migrations that are now code first. Okay. So we have models and views is still here, and these are our server-side rendered HTML pages that go out to the client. So we have a new file under here called bundleconfig.json. So bundleconfig, we can bundle our CSS and our JavaScript, but the more common way to do this on the web might be to use something like gulp. So I'm gonna go into this bundleconfig, and I'm gonna right-click on it, and one thing that's really cool is Mad Christensen's got these web extension tools that are gonna help me convert this bundling and minification to something that's more web-standard, which is using gulp. So I can come in here and say bundle and minifier, convert to gulp. So it's gonna warn me that it's gonna create some new files and it might remove some things. I'm gonna hit okay, and it's actually trying to change the file that I have open, so I'm gonna hit yes to all. And then now it's gonna go out to NPM, and it's gonna download the gulp dependency and wire everything up for me to do bundling and minification with a gulp task pipeline. So we're gonna have some new tooling that comes up after this. You can see the status bar down at the bottom. It's going out right now. And what you're bundling and minifying is your JavaScript files? Your JavaScript files, your CSS files. This can do, you can plug in preprocessors, so you can write things like LesserSass, or CoffeeScript, or TypeScript. Anything that needs to be transpiled down to JavaScript if you have something to do with all of that. So anything that is prior to you deploying your app and building your app, it's what you're automating. And I think what you see with ASP.NET Core and Visual Studio Tooling is Microsoft completely adopting the modern web standards and not reinventing the wheel because the rest of the JavaScript community is doing it. Let's kind of have you do the same things in Visual Studio. And you get an option of doing either what MS build will do normally, bundling and minification, or you can do it with grunt and gulp, it's a choice. So we looked at our dependencies note earlier, we just had Bower in there. Since the conversion tool that I ran needed to get some things from NPM, you can see that I have an NPM tab under here now. And you can see there's gulp and all of the things that I need to make gulp run can do bundling and minification. So now that we have a gulp pipeline in, that means that we have a JavaScript task runner. So we can feed this thing tasks that can execute node packages. So if we wanna manage how this is happening, we have a new window or frame. So let's back up, what does that mean? Why do you need to do this? Why do you want to do this? What are you doing? So just like on the server side, we have compilation and we're building our server side application. There's things that need to be built on the client side as well. And since JavaScript is really part of this ecosystem now, we have things that need to be built in JavaScript and bundled dependencies resolved. And we have tasks that run, much like the compiler runs on the server side code, we have tasks that run on the client side code and do this for us. Sometimes they're moving files or transpiling from SAS to CSS or a coffee script to JavaScript and things like that. So let me ask what to a experienced web developer will sound like a ignorant question? Why doesn't BuildSolution just do all of this farming? I think it's because you're coming from two different worlds, right? The client side development world is very JavaScript friendly, open source community where as in the past, the C sharp in server side, you're used to having a compiler and all of those things and they're two different worlds really. They do a lot of similar things and it's good to make analogies back and forth but they're actually very different tasks when you get down to the actual things that are happening. MS build will have to recreate a whole bunch of things on what JavaScript frameworks are already used to doing. So we're just bringing over what the rest of the world does outside of your studio. Okay. And you and I are good. Thank you word for it. You know obviously people that know this stuff are way better than me have built this all. So I'm just curious as to why it requires so many additional steps. Because I mean, so gone are the good old days that we miss where we used to have like three tiered applications, the UI, the middle tier and the database, right? Now the front end, the client tier itself has multiple technology stacks and each of them need their own little builds, each of their own little pre-processing things. So those are the things that, I mean, .NET and Visual Studio do very nicely with the server side of things, with your middle tier stacks and your data side of stacks. It's the front end that needs a whole bunch of new processing that we don't want to reinvent with Visual Studio. And a lot of the things that are on the front end were born outside of the Microsoft ecosystem. So you're not gonna find a lot of MS build hooks and things for at least in the past for things like this. So the reason build solution doesn't just handle this all for me is because there aren't necessarily the hooks into these things that would give the build command the ability to automate these things and run them, is that what you're saying? Currently. And it also wouldn't be as configurable as you can do with a task runner, where you can literally choose, pick and choose what your pipeline looks like and what exactly gets thrown where and so on. Another thing is we talked about cross-platform earlier. MS build doesn't exist on other platforms. It's coming, but it's not there right now. So if you're doing ASP.NET on a Mac, you don't want to be stuck with the build system that only works in Visual Studio. You want to adapt to what Morton Web does and just do it the way it is in Visual Studio. Okay, got it. So we have a new task window in Visual Studio. This is part of the preview tooling. And what the task runner explorer does is it lets you run these JavaScript or node scripts. So you don't have to go out to the command line and do run npm, gulp, whatever, and execute the gulp task. So you can see I have some npm tasks by default. I have npm install and update. And then I have my gulp.js. So I can go in and add tasks in either one of these task runners. So a couple of examples of what a task might be. One thing might be calling to a SAS compiler to compile SAS into CSS. Another thing might be after that runs. So the gulp task runner, it's a pipeline. So you start with something like pre-compiling SAS. The next thing might be to pick up the file that it drops and bundle that and minify it. Got it. And then after that we may actually want to move that bundled file somewhere else so it can be sent to the client. To the www.root folder in a lot of cases cause that's like the new repository for all things static. So you want these things to be bundled, minified and shipped to that folder so it can be served up. A few minutes I'll get to a demo here where we'll actually do some of that with webpack. So that'll be very interesting. So this is a lot of things that have changed and we're using for modern development in ASP.NET Core. So let's talk about some of the modern server side stuff. So let me fire up a Telerik ASP.NET Core application where we have all of our Telerik UIs and we can show some tag helpers about that. So maybe we also want to explain what tag helpers are. So that's a new concept in ASP.NET Core and it's a way of writing better, it's for better readability of your client side components that you're throwing together. So I'm gonna just go through the menus here real quick. I already have it spun up and I want to show you guys where this is found. I'm gonna do file new project. When you install the Telerik UI suites you're gonna get some new templates. So if I go to web I have a Telerik ASP.NET Core MVC application. So when I hit okay on this I'm gonna get some choices here. I can go with a blank application, a standard or a grid and menu. So all of these templates are gonna give me ASP.NET Core plus all of the Telerik dependencies that I need to run Kendo UI in ASP.NET Core. And you don't have to start this way if it's like a green field project you can just bring stuff into your existing project. But if you're starting up the getting started experience are nicer with templates. So I've already gone ahead and spun this up so we can make this demo run along a little quicker. And let's go, it closed it for me here. Let's go open it, open that project up. So let's do it from our start page here Telerik ASP.NET Core app. There we go. So I'm gonna just hit run here so I can show you what you get out of the box. So I did the grid and menu template. So when the grid and menu template comes up we've got all of ASP.NET Core plus we've got Kendo UI and a demo to show us how to wire up these controls and give us the great UI components like the grid. So it comes out of the box set up with filtering so I can go in and set custom filters up. It has sorting and you'll notice this is all Ajax so it's not doing a full page request. How do I know that? You won't see the page when I sort. You're not gonna see that big flash with the entire page reloading itself. So that means it's being done on the client. Yeah, if you open up DevTools you won't see anything going back. Okay. So when I click one of these sorts all it's reloading is that piece of HTML that is the grid and it's doing that all through JavaScript. Okay. And also this may be a nice segue to mention like MVC or like even web forms. Doesn't mean that like web forms in particular doesn't have a space in modern web, right? You could totally make an application that is rendering its initial things from the server side but then in Ajax you find more and more, right? So you're not coming back to the server. You're doing more and more things on the Ajax. You're only coming back maybe for some data back to the server. So I mean MVC and all of these like grids and other things are classic examples of a rendering engine which starts off doing some of its server side and then lets the browser do most of it. Okay. Because it's a fine balancing act, right? So we talked about like spas, single-page application. So spas are great because you download the spa once with all the code and all the JavaScript on the client side and you don't immediately need interactivity and connectivity. You can work a little bit. You can do some local saves. But the balancing act is you also don't want that initial load to be gigantic because that's gonna break your mobile devices, right? So it's a fine balancing act. Some things make sense to be rendered on the server side sent over and then do the interactivity on the client side. Okay. So let's talk about some of that server side stuff. I'm gonna go over to the about page because it really is fairly blank, right? And then let's go back to the code for this application. So I'm gonna go into views and I've got the about page open here. And in ASP.net MVC, if we wanted to add some controls to this page, we might do something with an HTML helper, right? We might do at HTML dot and then we might add some inputs or things that build up UIs. So if we have something like Kendo UI, we do at dot Kendo and then we might add something like a date picker. And you can see we have rich intelligence for this and it chains off into this fluent API and lets us set up a date picker. Well, people that do web development are gravitating more to this component style of web development where they want everything to look like HTML and act like HTML. So we have this new concept that we were talking about called tag helpers. So instead of writing an HTML helper like this, we can actually use a tag helper which uses HTML like syntax with ID or with attributes and HTML type of a syntax here. So we can type in opening brace and say Kendo, which is just like saying at HTML dot Kendo. And then you can see with the IntelliSense we have all of our controls that are available. So we could start up that date picker and we could do something like give it a name. So we get IntelliSense for the properties for the control here. So I can say my date and then I can just close that brace. And that's all I need to do and I have a date picker. So I'm gonna save that and go back to this page and refresh and there's a nice rich date picker. So I think ASP.NET Core gives you about a dozen or more of these tag helpers built in but you can easily extend them to render out your controls if you like. And the idea is not to get back the spaghetti land of mixing up server side and client side codes. Like every time you say an at the razor engine says, oh, this is server side, I gotta do something else. Well, this is a little more fluent because you can hand this off to a designer and they will know that this is HTML ish and it renders server side stuff. Another nice thing is if you have a container type of a control for like, let's say a window, for example. If I have a window that's written with HTML helpers, so the at HTML type syntax and then I need to write a container control. So I need to put multiple, nest multiple HTML helpers that syntax gets wild really quick and out of hand and you end up having to do like some abstractions and stuff to kind of help that problem along. So one thing that tag helpers do really well is I can just come up above this tag that I have for the date picker and I can say kendo-window and let's give this guy a name and I'll call it my window and then if we want this date picker to be a child control within that window we can just do that like we would in HTML. Without all those squiggly at symbols and that whole fluent syntax getting in the way. So now if I go back to my page and refresh this, you can see I have a nice window control here that I can drag around resize and my date component is inside of it. Yeah. The other beautiful thing I like about ASP.NET Core and this is where you see Microsoft kind of looking at what the modern JavaScript developer does to debug their applications and kind of bringing that over to the.NET land. We are used to a web application that we have to kind of restart every time we change our code. Especially if you touch any of the server side like ASPX.CS or any of the server side code, the code behind files, you immediately have to rebuild the whole application and deploy it. That's gone and that's no longer the case because it's very fast debug cycles. So this is all powered by Roslin so you can touch any code behind file and it's just going to auto compile just that piece of it and hold it in memory and all you can do is just refresh your browser and it picks up. Cool. Yeah. So I have one more project that I want to demo. So we've talked about ASP.NET Core with the file new ASP.NET Core project. We've talked about tag helpers and the modern way of doing tag helpers and HTML rendering on the server side. Let's talk about one where we want to be client centric and let's do a little bit of Angular 2. Now, some of this stuff is still in preview. So by the time you see the video and try it yourself some things may not work exactly the way you saw them on the video. So there's going to be a little bit of that. So what I have is I've installed some templates and this is called the ASP.NET Core template pack and this has extra templates in it for Angular applications, React applications. This is something that Steve Sanderson his groups were working on. So I can come in and say file new project and then I can choose ASP.NET Core Angular 2 starter application. So I've already got this spun up. You've got this extension from the gallery. Yeah, so this is in the visual studio marketplace. Excuse me, it used to be called, I still call it the gallery. The visual studio marketplace. Okay. And if I were to run this, I'd get the Angular, ASP.NET Core application with the Angular client side part of the application built in. So I've already got that spun up and let's take a look at the file structure again because it's again a little bit different than what we might be used to seeing. So in the tree here, I've got this client app folder. So this is going to be a big departure from what we just saw where we're writing tag helpers and HTML helpers. In this model, in this approach, we're writing Angular 2. So it's going to be a web component style of application development. So we're using TypeScript and we're using HTML templates and Angular 2 is driving everything. This is scary to me for you and me. So, this is like hardcore web stuff. So ASP.NET Core takes more of an API seat in this relationship. So it's feeding all of the data to the client application. The client application consumes it and processes it and displays the UI. So in client app, you're going to see something very different than what you're used to. You've got components and each component is broken down into a template. And then you can see this nice nesting we're getting in Visual Studio that's got the logic for that component. And then the HTML is the template and any CSS that might style that component. So it's all compartmentalized. It's all abstracted in these nice little modular bits. So let's fire up this and see what we get. Actually, I have that already running here. So this is what you get out of the box, okay? You get this little counter demo so we can click on this button and it'll increment. This is all working with JavaScript. There's, it's all a spa type of an application or a single page application. So we're not hitting the server for a complete view every time we increment the counter. We're just getting back the bits that need to be updated. We have a nice data example where we're pulling back a dataset. And let's go into that code real quick. And that's, yeah, this is the right one here. So we're looking at the data fetch example here. You can see in the URL here, we have fetch data. So if we go back to this application, we're looking at this fetch data component. I accidentally dragged and dropped. So it's giving me a little warning there. But this is the HTML that makes up that page. And then this is the TypeScript that powers that page. Now you can see in this constructor here, we have an API call that's calling out to API sample data weather forecast. This is where ASP.NET comes in. So if we go to our sample data controller, this is where the data is being pumped into that front end part of the application. So Angular's making that call back to this controller. The controller's populating the data. So then when you publish this, the server side obviously runs on the server, contains the client app. And when you hit that URL, the client app is sent down to the client and then the client app on the client, why it's called the client app, calls the server. Is that right? Right. So this will be sent to the client as JavaScript. So the TypeScript gets compiled into the JavaScript. And then when the client accesses the site, it's gonna pull in the HTML and the JavaScript and CSS for the application. And all it's doing is making a call out to the API for the data. All of the other processing and data binding and all that is done on the client. So that's the two components of the application, the server and the client talking to each other. So let's look at some of the tooling that's involved in all this because remember we have TypeScript now. So we're talking about compiling TypeScript. And then we also have Webpack, which is another bundling and minification type of a system where Webpack is a little more advanced than some of the other ones like Gulp. It does something called tree shaking where it'll go through and resolve the dependencies it needs and look for duplication and things like that. So it's a pretty advanced project. This is more future leaning than it is current. So we have a package.json file in here, which is our node package manager manifest. So these are all the dependencies that come from node or NPM. And these are all node modules that we're loading in. You can see all of the angular dependencies here. So one of the really cool things that they've done with the tooling here is we actually have full IntelliSense now. So if I had a NPM package that I wanted to add in here, let's say underscore JS, for example. What does that do? So underscore is going to be there's the IntelliSense there. Underscore is kind of like the link library for JavaScript. So compare that link and C-sharp, underscore JS for JavaScript. So it's going to give us those functional type of programming methodologies like map, reduce in iterators like those. It also speaks to the richness of the ecosystem that we are in. .NET, you have so many things just built in that we just assume are there. It's not there when you step out to the big world or you just bring things in. So usually if you go out to a site, you'll see something on a site like underscore JS, for example. For installation instructions, you'll see NPM install dash S or double dash save, and then the name of the package to get that into your dependency tree. So when you run that command from the command line, what it's actually doing is it's going to be into this package.json file and inserting the dependency and then bringing that dependency down. So foreign visual studio and we don't want to go out to the command line. We can if we want to, but we don't have to. We can just simply type in the dependency here. We're going to get IntelliSense. When we hit save, it kicks off that NPM install for us. So we can completely circumvent the command line if we want to. I actually want to do that. I want to take and install some additional UI components. So I can come in here and below this line, I can install Kendo UI for Angular, which is a Telerik product. So I can come in and paste in these dependencies and hit save and I try to do this quick so I can catch it. If we look up in this dependencies tree, you can see it says restoring. So it's going out and it's pulling in those dependencies and installing them in our application. Now you'll notice there's a little yellow flag here that says not installed. That's actually currently a bug. So like I said, this is bleeding edge stuff that's being worked on right now. So there's still some quirks. It's a bug in what? It's a bug in the preview tooling. Okay. So the dependencies are actually installed. There's some warnings that come up. The ASP core preview tooling. Yes. Is that correct? Okay. So there's some warnings that come up in NPM for one of the packages that's in this Angular dependency tree. It has to do with cross-platform. It's something that's installed, I believe, on a Mac. That's not on a PC. And it's just a warning. So it comes up as not installed, but it actually is. So that's something that's being worked on but you'll see that and it's nothing to be worried about. So I can actually reopen this tree here and I just added these progress Kendo grid dependencies. That's what I pasted in here. You can see that it's actually been installed by opening this tree up and looking underneath. So I've taken and I've installed something without going to the command line. The next thing I wanna do is plug into Webpack. So when I installed the Kendo UI components, we have some CSS brought with it. And I need to go out and get that CSS right now. This CSS, actually, let's open this up. We can come to the dependency tree over here where I have Kendo theme default. Okay, this is our default CSS theme. If I right-click on this and I do open in file explorer, you can actually see where the dependency's been installed. So you can see this long, long path right here is where the actual files installed. And what I want is in the distribution folder, this all CSS file. So I need to tell Webpack that this file exists under this tree or this directory, I mean. And when Webpack runs, I want it to take the file and put it in the bundle that it's using for the theme on the application. Right now, that would be what's called the vendor.js file. And the vendor.js file is resolved with the client app. And if we open up our Webpack config, actually our Webpack config vendor.js file, you'll see everything in here is going to get resolved to a vendor.js file. So it's bundling all the JavaScript up, that all the stuff that is in this vendor array here and placing it in one single JavaScript or CSS file. So this will become vendor.js or vendor.css. You can see the file name up here. So I want to resolve that package, that Kendo UI package. So it's under default dist all.css. So now that I've added it to this array, I actually need to run Webpack and pass in the Webpack config.js file. So here's where we can use some of the new tooling to avoid the command line once again. Not the wrong with the command line, but some people don't like it as much as they like being inside of Visual Studio. You see the struggles here, like on a Mac, we are perfectly comfortable with command line, not so much in Visual Studio. So I can see both sides of it. So, oops, wrong file. I want the package.json file because this is our node package manager file. And from node package manager, we can run scripts. So I'm just gonna come in here and type scripts. You see I'm getting some IntelliSense here. And then I can add a custom script file here. There's some built in ones that you can see me getting IntelliSense for right now, like install. Those are scripts that NPM understands out of the box. But we can create our own. So let's do one called Webpack Vendor. And what we wanna do is we want this to go out to the command line. And we want this to call Webpack with double dash config. And then I'm gonna call that config file. Webpack config vendor js. So normally what I'd have to do is open up my command line and run this. This is what I have highlighted here. Instead, I can put it in here, hit save. And notice when I go to my task runner, I have this new custom element here. Let's actually zoom in on this here. Cause this is really cool. So I have this custom node here and I have Webpack Dash Vendor. So if I double click on this, it's gonna go out and run that command line. You can actually see it running right here. So it actually went out to the command line and ran. And it completed successfully. So you can see that it has output vendor js and vendor CSS. So we can see it right there in the output. So even though we're in Visual Studio and we've avoided the command line, it's still somewhat repetitive to keep going down here every time we make a change to this vendor config file and rerunning the script. So let's do something to make this a little more automated. So let's go to task runner and on this Webpack Dash Vendor script, let's right click and do bindings. And now every time we build, we can run this. So you can see back in my script file here or my npm package.json file. We've actually added a little vs binding in here through the tooling. It's just added this in as text to our package.json file. So it says before build, run that script. So now every time we run our build, it's gonna go out to Webpack and call that first and make sure our JavaScript and CSS dependencies are resolved and bundled up for us. Cool? I think one question that we can kind of get from developers is I want to be inside of Visual Studio and I want to be building modern ASP.applications and ASP.NET Core is the most modern web technologies that you'll get from the Microsoft stack. So the question is do these JavaScript frameworks belong in your ASP.NET stack? And the answer is it depends. If it solves a genuine problem for you, it depends and it can coexist. Like you showed like your Angular 2 or your React or any of the JavaScript frameworks and the client side core frameworks, they can coexist with ASP.NET. You might still use MVC to render some of your views and then you can revert to using the JavaScript frameworks to render other views and you can do mix and match of the routing. And it's all about how much you want to do on the client side. With MVC you can render them once and then you can exify it while if you are really doing much more heavy lifting with JavaScript where you're really maintaining like models in JavaScript land or views and view models with JavaScript, that's where you kind of fall back to using some of these JavaScript frameworks because they can do some of these renderings for you. And Visual Studio will try its best to help you out to make sure, I mean, they're adopting all of the modern web standards to get you some of these tools so you don't have to recreate. With the Angular component model too, it makes things much like they are on the server where I had a tag helper. Now that I have Kendo UI installed and all of the CSS ready to go, I can come back to this forecast table, this one here and I can replace this with a Kendo UI grid and I just want to show like how robust this is. So initially we're rendering it an actual table in HTML. And we're having to template every single item in here. So with Kendo UI, and this is reliant on the Angular component model, I can come in and type Kendo grid and then we'll do the data property of the Kendo grid. And I'll pull in forecasts, which is the data property that is part of that component and save this. And then I, because I did so much with adding new packages and all that, we're just gonna give this one clean reboot here. And then when we go back, we should have a Kendo UI grid in there. So that's all we need is to point it at the data and it can understand the data structure and I must have typed in something, something incorrectly. It's not a blue screen it used. Yeah, it's not a blue screen here. Some things not being, oh, I didn't add the component to the actual application. So we didn't import it to the actual application yet. So we resolved the dependency, which is like going out and fetching it from NuGet, but I haven't added an import statement to the application yet. So it doesn't understand what that is. So we'll see some intelligence in here again. So I'm gonna add my grid module and this is coming from progress. It's gonna be the same name as the package that I installed. And then now we'll see the intelligence come up here. I need to actually register this dependency here. And you can see grid module came up. So it understands what that is. And if I were to have typed this wrong, you'd see, let's just throw some garbage in there. You see some red underscore squigglies come up in there? Right there, there we go. Cause they can't find it. So we can go back here and correct that and save that. And let's rerun our application. That squiggly will go away. It takes a second or two. And then hopefully we resolve that error. So just by passing the data property, the collection of data, Kendo you ought to be able to go out and figure out what data it needs to bind and there it is. So just a little bit of configuration. I just put the component on the page, showed it where the data was and it's generated all of the rows and columns that it needs. So I don't have to go through a template and render it out manually like we were doing before. And then we have full control over the column headers and all of that as well. So I've actually got a little snippet I can go back and paste in. So we can go grab these. So these are actually sub components of the grid. And we can go back to our fetch data component. And inside of the grid we can paste in those. And this should be render on its own. But I'll give it a little kick in case I typed something wrong. I may have those in there backwards. But we can use those properties to name the fields where they come from and set the titles of those columns. So yeah, that's a lot of Visual Studio goodness as you can see. So I think the messaging is Visual Studio is fully embracing all of the modern stuff. So you got more stuff or should I switch over to some cross-platform stuff? So let me end things with a little bit of what Microsoft tooling looks like on outside of Windows. And I think this is the reality. I mean, you see a mixed bag everywhere. Let's switch screens while we're at it. There we go. All right, so let's kind of switch back to the Mac side of things. The same experience can be had on Linux, for example. And this is new. We have never had .NET run outside of Windows. So this is pretty amazing. So I think if you go out to .NET, it results to Microsoft.com forward slash .NET, right? And this kind of shows you all of the different .NETs that we have and what it can do for you. If you hit that download button, it's gonna show you the three stacks that I showed you, the .NET framework, which is the full thing for Windows, .NET Core, which is cross-platform and Xamarin if you're doing mobile development. So choose your .NET essentially. And this is kind of a choice that we didn't really have before. So for Morton Web, pick .NET Core, because that's the one that gives you the tooling and the runtime to run your applications elsewhere. So once you get that, it's gonna give you not just the bits, but an SDK, which includes the command line tooling. Because I'm on a Mac, I don't have Visual Studio, like the full-on Visual Studio, but I do have Visual Studio code, which we'll get to. So here's a completely different look at .NET and Morton development with ASP.NET, but on a Mac. So what I have here is just a file system, just a folder here, and then I'm gonna pull up my terminal here, right? So let's actually make a directory here. This is gonna go back to our DOS days, but the thing is this works the same way across all platforms. So let's just call it an ASP.NET Hello World app, right? So I just made a directory, you see it show up right there. So let me actually go into that directory, right? And then I can do things like .NET, new, which is command line, because it's using the SDK. A new thing means new up a new .NET application for me. So if we didn't do anything else, it'll just give you a console app. But you can say off the type, minus T, and then web, at which point you are saying, spin up an ASP.NET application for me. This is Morton web with ASP.NET stack. So it's gonna go and do that pretty quickly. This used to be empty, but now you can see it actually has some stuff. If I open this up, I think you'll see the solution structure being very similar to what Visual Studio will give you on a file new project. Some things are different, but the whole concept of MVC, the model views, everything else is very similar. And now I can do this .NET restore. So at this point, it's saying, oh, I see that your project has some dependencies, let me bring them down. And right now out of the box, my project has no dependencies because I just did a hello world thing, I didn't even touch the project. So what it's really bringing down right now is .NET. Remember I said ASP.NET core is all lean and it's modular. So it's gonna literally go off and bring down .NET for you, just the pieces that are needed for this application. So this ran fairly quickly and it's also cached. So if I actually go over here and I can show you where it's grabbing it from, go to folder. So username and then .Nougat is where it all lives. So this is what it's using. There's a Nougat config file, let's say is go and get it from here, you can have your own Nougat server being hosted and pulled down stuff. And then these are all the packages. This is what's making ASP.NET core run on a Mac. So while we already have that, we're gonna come back to this. So once I have this, I can say .NET build to build my project, but I can also say .NET run to kind of build and then deploy the project all in once. And it's saying, oh, I see it's an ASP.NET app and I'm up and running. Application started, so now I can go back to my browser and do a local host, 5,000 is the default port. And in a second, you will see ASP.NET running. So again, I keep going back to Hanselman, but one of his like blog posts when this first came out, like your brain should like leak out of your ears. This is mind blowing. You're running native ASP.NET. And this runs not just on a Mac, but even like on Linux, on a Pi. I mean, the footprint is minimal because all you're putting in is just a couple of pieces of .NET, right? And back here with the Nougat packages that I showed you, if I go ahead and blow this whole thing away, right? Here, let me select all of this and I'm going to go and move the whole thing to trash, right? My .NET is gone because I didn't install .NET explicitly. It was just pulled down for this application. So now, if I go back in here and I do another .NET restore, you will see that it's actually going to repopulate my packages and now it's actually expanding and pulling things down into that Nougat package repository. So this is what the experience looks like. This is how compartmentalized it is and they're really embracing the modern web standards. So you start off with a basic boilerplate thing and then you pick and choose what you need, whatever frameworks you need, bring them in. And then on a Mac or Linux, you're much more comfortable doing command lines. So go ahead and do that. So let me... And other templates will be coming as well. Like the one I showed for Angular will probably be implemented at some point. So we'll get those future-leaning templates as well. Yeah, absolutely. So let me show you one other thing here. If I go back to my project here, this is a preexisting app and I haven't done much to it but let me kind of go to it and let's see where I'm at. Yep, so clear this out and then we're going to go into this Telerik ASP.NET core app. So there is nothing special about this app except I've added a couple of dependencies. So one other thing is Visual Studio Code. Yep. I don't want that 10 gig install that he has. I want it to be light and I want it to be working everywhere and the same everywhere. So I really, really love Visual Studio Code. I have it on my path variable so I can just do code dot on any folder that I'm in and it brings up Visual Studio Code. This is beautiful and it's very lightweight so it has extensions and other package managers. So it's a fine balance and you don't want it to be too heavy with tools and stuff like that. You want it to be somewhat lean but also doing things like get management if you want to push things off to GitHub repository. It can actually debug ASP.NET applications and Node.js applications pretty nicely and you have complete access to your files and folders. And then you can continue to do all the NPM and Bower and Grunt and task stuff just from the command line, right? Yes, so yes you can but also this one has, I may forget the shortcut here, but this one has some things built in. There's a command palette and this one actually has a command line built in so you don't have to step out to your command line. You can fire off commands from right here. You can type task right there too and it'll bring up your tasks. You can run all tasks, you can run specific tasks. So you've got shortcuts to all of those tools. So you can stay inside of Visual Studio Code all day and fire off your builds and compiles and things like that. Lots of great plugins too. Yeah, lots of great plugins. So this one here in particular, let's see, don't want to update right now. This is sort of changing in the next iteration but let me maybe make it a little bigger so you guys can read. So this used to be what ASP.NET Core Applications uses Shippoint, project.json. This is how we listed all of our dependencies. This broke MSBuild a little bit and I think in the next iteration it may already be there in ASP.NET Core 1.1. We're kind of going back to the CSproj world because there is WPF, there's the rest of .NET which needs MSBuild and CSproj so we cannot just break away and do our thing and break everything else. So they're bringing Mac dependencies in XML format but this one's an older project, it still has project.json but the idea is the same, just list out your dependencies. So in here, the only thing I've added here is our ASP.NET Core. This is a UI library that runs only on .NET Core, just that one liner and then I'm using Bower to like bring down my dependencies on Kendo UI. This is where it just sits all of the JavaScript and all of the styles that you need and then that's all you really need in your view import switches where you kind of subscribe to your using statements. You can just add a tag helper that gives you all the access to the tag helpers that are built in as well as that come with it. So this is the same as the second project that I should write. And then standards, like layout, CSHML which is where most, this is like a master page for most MVC applications or MVC pages. You can have your scripts and stuff like that. So just I'm referencing my JS files and CSS files. So now in my index, which is my razor view, I can do exactly what hit it from the server side. This is, I mean, I can write straight up JavaScript. Sure, but this is straight up razor server side rendering from a MVC application, but done on a Mac. So I can just say, add HTML, do Kendo date picker and I can actually go ahead and run this guy here. And those are the same 80 plus UI controls that existed for ASP.NET and MVC and are in Kendo UI and they work on Mac, Linux, PC and they render to any device, mobile tablet, big screen, small screen. It's all adaptive mobile responsive rendering. That's real, write anywhere, deploy anywhere. It's almost done, it's thinking. And now it's done so we can do, go to run one more time. This is something that you wouldn't have even thought of being a reality five years ago. And these told me that you were gonna be writing an ASP.NET core application on a Mac, running the web server, using Telerik UI controls. I would have looked at you like you had two heads. So same exact ASP.NET application, the same boilerplate thing except I just rendered I can do your date picker so you get the nice JavaScript date picker right in here. So I think the bottom line is don't resist. If you're coming from a desktop background, there is a lot to take in. So don't just dive in and try to take in all and bring all of these things in your project. It's gonna drive you nuts. But take it slow, mix and match with what you know and what you can bring in from the JavaScript world. Visual Studio is gonna try its best, not just on Windows but on a Mac or on Linux to kind of help you out and give you the right tools. And then you mix and match your technology stack and you slowly start making your, maybe you're existing not so modern web application, a modern one. You're bringing in JavaScript, you're bringing package managers in, you're doing things which you used to do before but now you're depending on stuff that the JavaScript community has already done for you and it's much more streamlined, much more configurable and so on. It's nice to have the choice too in between Command Line or Visual Studio and to be able to mix and match as much as you want. So you can go in and install things from NPM on the Command Line or you can go right into the package.json file and add things with IntelliSense there and you know Visual Studio when you hit save is gonna take care of all of it for you. Cool? Yeah. So I think that's pretty much all that we wanted to cover. Thanks so much. Hopefully it was long but, well it was long, hopefully it was good. So this was, as we mentioned at the beginning, a bit of an experiment to address the modern web in the context of this show in what for many Command Line shows was an ungodly amount of time but for this show was just a normal amount of time. So let us know, let me know if you liked this, let us know what you thought about this. Do you wanna see more types of shows like this? Want your honest feedback? Be nice, don't, you know, don't be rude, don't, you know, call us. You're asking the internet to be nice. I'm asking my loyal viewers to be nice and honest. So we love feedback. So seriously, let us know what you think about this and would you like to see this type of episode in the future, what do you wanna see about, we do a lot of, on this show, a lot of features of the product and we'll obviously continue to do that but I've been trying to branch out a little bit more into techniques and, you know, practices. So appreciate you guys coming on and giving us this great overview, glimpse into the world of modern web development. All right, we'll see you next time on Visual Studio Toolbox.