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>'
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.
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.
Makes sense, the modern frontend frameworks are pretty similar anyway, despite the amount of noise about their differences. If you find react hard you’ll probably find angular hard and vice versa.
You try and tweak how you want to break up a component and the house of cards starts to fall over.
JavaScript is a good goal... but not because there's a lack of C# viability.
But back in 2008 there were also good paying jobs for good C and C++ developers. But when I looked at the direction that the local industry was going, I could see that the age of the bit twiddler was dying locally and there were more jobs for “enterprise developers”.
I had a choice between making $20K more as a senior C++ developer or $7K more as a mid level C# developer. I took the latter even though I had 12 years (staying at one company way too long) of development experience.
So that’s what I concentrated on for the next 9 years - the Microsoft stack.
Late last year, I was the dev lead for a decent size company with a small IT department. I was looking to change jobs and once again I saw the writing on the wall. There were a few jobs willing to pay what I wanted writing C# but lots of companies wanted Node/React/React Native.
This time, once again I was offered $15K more as an architect leading a team of 10+ developers writing apps in C# on Windows servers, running Sql server and I had another job offer as a “senior developer” at a smaller company making only $5K more but would get a chance to not only fill in some technical gaps on my end - front end coding with React and back end with Node. I would also get to lead initiatives to make the company more “cloud native” and to restructure the architecture for high availability, scalability, etc. and help build a dev ops culture. But with no official reports (that’s a good thing).
Looking ahead three years, I knew what the better choice would be for my career. Sure there is money now for C# developers but that’s not where the market is going.
But honestly, the salaries for developers and even architects who want to stay mostly hands on and don’t want to go into management outside of Silicon Valley/NYC is stagnating. I realized from my last job that the real money is working for consulting companies with titles like “Implementation architects” and “Digital transformation consultants” who help companies move to the “fourth level of the cloud maturity model”. Yes typing that left a bad taste in my mouth.
So that’s really the game plan - but to speak to all levels of the organization, I need a “more modern tech stack” as one of the recruiters told me.
My decision is real simple... Microsoft has one thing most of those stacks don't: Longevity.
You can knock C# as being "old" and not as "shiny" as Node/React/React Native/Angular/etc... but C# has been stable for a long time and it isn't going anywhere.
I can't say the same for JavaScript.
> Yes typing that left a bad taste
I don't know if that would change with C#, C++ or JavaScript - you are bound to hit a ceiling as a "developer" unless you move into engineering/architecture/management/bullshit (but I repeat myself)
> need a more modern tech stack
I'm learning JavaScript alongside C# (but I'm definitely a .Net Developer) for that reason.
I personally have less faith that those techs will be as predominant in 20 years though... I think it's a crapshoot all around - things are different from 5 years ago and C# and JavaScript will be COBOL in 20 years - alive but not really...
We'll be working in mines for our robot overlords who can program themselves at that point.
But seriously... I have more faith that Microsoft will be consistent and supportive of technology than Google or Apple - Google has dropped more technology than anyone and Apple is still a 1 trick pony. Facebook is pissing people off and companies like Amazon are like Blackberry and Palm - even the giants die eventually.
Not sure if that makes sense... but rambling aside, you can pick a channel - C#, Java, JavaScript, etc - and have a successful career as long as you are able to learn the bigger picture and move if/when the writing is on the wall.
JavaScript has been around longer than C#.
But if you want to compare how long framework of the week has been around, Microsoft frameworks have been anything but stable - Linq2Sql, Webforms, WCF, Windows Forms have all but been abandoned and the .Net Core versions of WebApi, MVC, and EF are mostly different from their older versions.
But seriously... I have more faith that Microsoft will be consistent and supportive of technology than Google or Apple
There is this story of VB6 and Classic ASP...
And all of the abandoned mobile efforts. MS abandoned Windows CE/Windows Mobile in 2008 when there were still millions of devices running specialized vertical market apps using it.
I don't know if that would change with C#, C++ or JavaScript - you are bound to hit a ceiling as a "developer" unless you move into engineering/architecture/management/bullshit (but I repeat myself)
Well, 10 years later, I can’t find any C/C+* jobs in my local market making $60K+ more what I was making back then. Honestly there aren’t too many C# jobs that are making 60K+ what I was making back then in my local market. I was able to negotiate a slightly higher than median salary because of my architect/Devops/AWS skills. There were plenty of jobs for the JS/Node/React/Docker skillset making what I make now - but I wasn’t qualified for them.
The ceiling for .Net developers is lower than that of the Javascript $cool_kids_stack.
But yes, it’s all about knowing where to jump on and off the hype cycle.
The larger companies where C# is more popular aren’t as willing to throw money at developers and honestly they don’t have to. C# developers are a dime a dozen.