This is on track to become a "built-in feature of ASP.NET Core 3.0" – recall that ".NET Core" runs on Linux, etc.
Much C# development is still for internal business applications. For these applications, the overhead of shipping the .NET runtime to the browser in WASM - which https://blazor.net/ sadly does not seem to mention - may not be a big deal, especially if they can be cached with service workers.
Keeping engineers fungible and cheap to hire & train is a priority for enterprise software divisions. Software ecosystems that rely on the patience and curiosity of developers to explore an uncoordinated constellation of packages and design their own architecture (eg; Java, React ecosystems) can be suboptimal.
.NET's historical "all batteries included, all applications the same" promise has been key here. But for rich frontends, Angular (their current choice) has, ah, high training costs.
If Blazor works well, .NET Core may become the first truly full-stack, integrated, get-it-all-here, framework for modern web app development.
As an uninvested bystander to enterprise software development, I'm curious to see how this goes.
Does it? You need to know typescript (which you arguably should be using regardless of frontend framework) and what dependency injection, observables and components are. Plus some syntax for the templating language, which is fairly intuitive. That’s enough to get you going, I don’t see it as being much more of an investment than learning a react stack.
It also has the benefit of being all in one, like .NET, so there aren’t multiple different packages for every function that could be used, depending on who your team is. That all in one factor is probably why it’s a natural complement to .NET.
That's highly debatable. We moved back to ES after using Typescript for years and couldn't be happier. We're much more productive than we were with Typescript, and that's with people that know the language. We get much of the benefits of Typescript by just using a jsconfig.json file in our project and using VSCode. The Typescript language service will typecheck JS code if you want it to.
And there is a big upfront cost for onboarding developers with Typescript and Angular.
Very much agreed. And I also agree that, at least in a corporate context, training for a React stack would also be expensive, potentially more so.
And there are plenty of people out there who have no problem picking up Angular.
Looking at job market data alone, though, Angular commands a premium to .NET-only. Anecdotally, folks who feel comfortable with .NET, but who find eg; React+Redux bewildering, also feel constantly confused by Angular and can get themselves into trouble without close guidance.
Angular needs a bit more training because you are heavily encouraged to do things the "Angular" way which requires a lot of abstraction and componentization.
This seems to have a React-ish architecture with familiar C# templating (Razor):
Razor syntax is the JSX-equivalent, which has been used for C# templating for years: https://docs.microsoft.com/en-us/aspnet/core/mvc/views/razor...
Blazor Components: https://blazor.net/docs/components/index.html
Their docs are pretty scattered, especially for someone coming from React, but it seems to have similar features and lifecycle methods, albeit a bit more ersatz.
onClick => onclick (etc)
componentDidMount => OnInit / OnInitAsync
componentWillReceiveProps => OnParametersSet[Async]
componentDidUpdate => OnAfterRender[Async]
shouldComponentUpdate => ShouldRender
componentWillUnmount => Dispose
You don't seem to be able to define multiple components in a single file (which in my experience leads to bloated components).
Routing seems to be defined within the .cshtml file rather than centrally, which can get messy in my experience.
I don't see anything to support state that is shared across far-flung leafs of a deep UI tree (eg; Redux, Context), but maybe there are standard .NET constructs for that which I'm not aware of.
I don't think this is going to win anyone from the React world – some design choices seem not to grok some key insights of React – but I can imagine it taking off amongst folks who were happy with server-side Razor templating and have been unhappy with Angular.
I can't help but feel this is a cleverly worded put down of Enterprise software developers. Having worked on both sides of fence, there are significantly differences but it mostly comes down to the type of end product rather than whether developers are "fungible and cheap".
For example, at the company I work for now we develop at least 12 different fully deployed products year. When I worked for a startup, we developed a single product over 5-10 years. Most modern frameworks are definitely geared more to the latter than the former.
Blazer is definitely not geared for the single highly optimized application. But I could definitely see using it to get much better results for our internal applications with much less effort. We could probably absorb the run-time cost.
The current JS frontend frameworks are great but they all require a tremendous amount of work to get going for any complex application. The tooling, build chains, libraries, boilerplate code and general verbosity of JS really needs a cleanup and Blazor is incredibly attractive in that regard.
> Early Blazor prototypes used a compact .NET runtime (including assembly execution, garbage collection, threading) that compiled to a mere 60KB of WebAssembly. Blazor now runs on Mono, which is currently significantly larger. However, opportunities for size optimization abound, including merging and trimming the runtime and application binaries. Other potential download size mitigations include caching and using a CDN.
.NET's most common use case, based on my research, is enterprise applications, but certainly not its only.
Thanks for calling this out.
* SPAs: Microsoft has a vested interested in porting a lot of code to SPA applications. Teams being the latest example.
* Windows is dead, long live Windows: A desire for a lighter version of Windows in the near future running on ARM and you suddenly have existing dev tools and code moving to a Chrome OS like environment with little fuss.
* Edge: Is jumping over to chromium and wishes to support existing chrome extensions. What blazor may also allow are some pretty sophisticated download-once applications also coming through that 'store(?' with first class support.
* Linux Love: If linux is the rural America of 2016 then MS is Trump. OSX and Google seem to be locking people in and MS is trying to give more choices.
* Windows is Dead, part 2: Can't stress this one enough. Giving enterprise developers and teams a way out of the legacy sandbox seems to be key.
tl;dr - Re-cut the Star Wars scene of 'Luke I am your father' to Nadella and myself. Change the response to 'Yesssssssss! <hug>'
I can see Blazor being really useful for back office systems where people are in them for hours, not so much customer facing stuff which people are dropping in and out of.
I think anything that can challenge JS (which tbh is looking increasingly more like C# with every new release) on the front end side can only be a good thing though.
Caching is also a helpful idea beyond the size of the initial download. Future compilers (cranelift), will have time to make multiple optimization passes on the instructions and save them for later.
The only thing that Microsoft is doing that’s getting any real traction is Azure. Don’t get me wrong, I’m not abandoning C# and there is no way that I am going Java, but I am focusing more on Jsvascript and Node.
What wasm might be able to do in addition is having a carved version of loaded runtime available in order to reduce startup times.
https://github.com/dotnet/corert/blob/master/Documentation/h...
Edit: wow, downvotes. Not that I really care, but it shows the "stick the head in the sand and don't care about bloat, ignore everyone complaining" mentality that pervades the community...
That said, I do see current frontend technology being replaced by something in a few years, probably wasm.
I've used and built many fast and lightweight webapps using .NET and other frameworks. Like most things, the tech has little to do with it.
Echo chambers downvote anyone who points out the echo chamber behavior.
Microsoft have had great success with Visual Studio Code and are now the custodians of Electron since they brought Github this year. Also, now that Microsoft are going all in on Chromium for Windows (and dropping Edge in the process) I wonder if they will introduce Blazor into Electron for better cross platform applications.
I just get the feeling there is a play there (in some fashion)
The component model (Razor Components) for the UI is already committed to ship in .NET 3.0 so it can be used in server-side views, but the client-side WASM framework doesn't have a release date yet.
Blazor is interesting in that respect but you can already use Electron today with JS and .NET Core powering the backend.