Cover image for How Blazor Is Going to Change Web Development

How Blazor Is Going to Change Web Development

jeremycmorgan profile image Jeremy Morgan Updated on ・5 min read

Getting Started with Blazor (3 Part Series)

1) Build and Deploy a Blazor App Without Touching a Windows Machine 2) How Blazor Is Going to Change Web Development 3) Containerizing Your Blazor Apps

A couple of weeks ago I wrote an article about building and deploying a Blazor app without touching a Windows machine and realized maybe I should take a step back and explain what Blazor is and why anyone would use it. It's still fairly new to most in the front end development world, but it's awesome and you should check it out.

So what is it, exactly?

Blazor is a framework from Microsoft that you can use to develop interactive client-side Web UIs with C#.

In their own words:

Blazor lets you build interactive web UIs using C# instead of JavaScript. Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS. Both client and server code is written in C#, allowing you to share code and libraries.

Pretty cool right? You can download it here and get started. 

The old way

Remember the old way of developing web applications? 

What is Blazor

For the longest time, we built applications that ran solely on the server, using things like ASP.NET, PHP, etc and they generated an HTML file to be pushed to the browser.   

We've always had some bit of interactivity with JavaScript and AJAX but for many years most of the business logic is handled on the server itself, spitting out HTML pages to interact. The browser for many years was just a glorified document viewer. It worked, but we knew we could do better.

There are some downsides to this pattern that we're all aware of:

  • The server needs to be configured with software to run the web app. ASP.NET, PHP, etc. Backend processors or runtimes have to exist on the server. 
  • Most of the processing power is on the server. 
  • Page loads are annoying and slow. 

So we found a new answer to it. 

How we do it now

With the rise of the Single Page Applications we have a new pattern, with frameworks like Angular, React and Vue:

What is Blazor

Now we're building full applications in JavaScript that run on the browser. This splits the business logic, so that some runs on the browser, and some runs on the server. JavaScript applications run client-side and use messaging to communicate with the "server". You can easily replace "server" with a service or application in the cloud, but the model is still the same.

This is an excellent improvement on what we had before, which essentially manipulating HTML and tossing it back and forth. Now we have real applications running in the browser, and page loads are mostly a thing of the past.

But Blazor improves on that pattern further. There are two main ways to develop with it.

Option 1: Web Assembly Method

When you choose to build a Blazor Web Assembly application it looks like this:

What is Blazor

Blazor uses Web Assembly which ships in all major browsers now. Web assembly is a binary instruction format that runs a virtual environment in the browser.

So what does that really mean?

Now the browser acts as a host for your application. Files built in a Blazor Web Assembly application are compiled and sent to the browser. The browser then runs your JavaScript, HTML and C# in an execution sandbox on the browser. It even runs a version of the .NET Runtime. This means you can execute calls to .NET from within the browser, and it's a fully-fledged application in the browser. It can even be run offline.

Why this is cool:

  • You can run it on any static file server (Nginx, ISS, Apache, S3, Heroku, etc)
  • It runs JS as bytecode, and runs C# at near-native speeds.
  • You can use C# to develop rich front-end applications.
  • Web Assembly ships with all major browsers
  • Reuse .NET components
  • Use Microsoft tooling and debugging

This is great for low latency applications such as games. There's no need for communicating with a server if you don't need to. You can download the application and run it offline in a browser. This is great for games and other things you need to run lightning fast in a browser.

Some downsides:

  • The .NET Framework and other runtime files need to be downloaded (one time)
  • You're restricted to the capabilities of the browser
  • All secrets (credentials, API keys, etc) downloaded locally
  • Not all .NET Framework components are compatible

So this may not be ideal for all applications. The good news is, there's another Blazor pattern we can use.

Option 2: Blazor Server

If you decide to build a Blazor Server application, it looks like this:

What is Blazor

This is closer to the model we're using today. You build an application and have a server that's powered by .NET Core, and you send HTML and JavaScript to the browser to act as a client. This is a great way to make screaming fast thin clients. 

Why this is cool:

  • You get the full power of the .NET Framework
  • Everything rests on the server, small downloads
  • Web Assembly is not required
  • Your secrets are safe

Some downsides:  

  • No offline applications
  • Requires a server running .NET Core or a service
  • Can be high latency with lots of network traffic

So how do I choose which one to use? 

If you want powerful client-side applications that can run offline and served from a static server, choose Blazor Web Assembly. If you want the full power of .NET and want to run a model with thin clients, choose Blazor Server.

Why is this such a big deal?

Blazor patterns open up big opportunities for development. Whether you want to build a powerful service with several thin clients, or some cool interactive game that runs in a browser, Blazor enables rich, interactive application potential.

Web Assembly is the way of the future. It enables near-native speeds in a browser, and uses a common interface. You will find Web Assembly on PCs, Phones, and tablets. If you have a bunch of C# developers on your team who don't do front end programming, they are now empowered to do it in the language they love.

It's pretty awesome, and I'm excited to see how Blazor progresses.

Where can I learn it?

You can learn more about it from Microsoft's Blazor Site.

I recently wrote a tutorial about setting up and deploying Blazor apps without touching a Windows Machine

If you want to dig deep and learn Blazor, Pluralsight has some modern courses that will get you running quickly:

So try it out! Let me know what you think of Blazor and share your experiences in the comments!

Getting Started with Blazor (3 Part Series)

1) Build and Deploy a Blazor App Without Touching a Windows Machine 2) How Blazor Is Going to Change Web Development 3) Containerizing Your Blazor Apps

Posted on by:

jeremycmorgan profile

Jeremy Morgan


Silicon Forest Developer/hacker. I write about .NET, DevOps, and Linux mostly. Once held the world record for being the youngest person alive.


With our technology skills platform, companies can upskill teams and increase engineering impact.


markdown guide

Too bad MSFT took 20 years to figure this out. Once they killed Silverlight (because Apple wouldn't allow browser plugins), it sent a huge negative message to those loyal to them.

Later confirmation of ridiculous descisions they made: 1. They fractured their own desktop environment with UWP. 2. Abandoning WPF while denying it. 3. WPF never was fully able to embed their own browsers. 4. Their ridiculous IE and Edge browsers.

In the meantime, NPM, Node, Electron, Angular, React, Vue and Chrome captured the frontend along with huge open source contributions.

Jumping on the Blazor bandwagon, to me, is regressive. How many Blazor jobs are there on LinkedIn?

MSFT throws their developers under the bus too often and are untrustworthy in that regard.

I'll stick with Typescript for now only because it's superior to Javascript and compiles to Javascript. I'll use Angular for now and Electron in 2020.


I replied to a comment of yours on another article but since you probably haven't seen it, I'll reproduce it here.
Your original comment:

"Growing up on .NET, I became a bit biased. I love C# and ASP.NET core. In the meantime Angular and React took over the front-end world, and Node and Express are working to create the Isomorphic stack. If I were a new programmer I'd skip C# and Java and learn server side Javascript using Node and Express."

My reply:


Latest TechEmpower results as of the time of posting this:
As you can see, Node.js is so far behind ASP.NET Core in all tests, it's not even a contest any more.

As for front-end C#, here's an example: n-stefan.github.io/diabloblazor
It is a port of this: d07riv.github.io/diabloweb
replacing React/JavaScript with Blazor/C#.
Being static it doesn't use a server at all, but server side prerendering (initial rendering) is baked into Blazor and can be used with sites that are hosted by an ASP.NET Core server. There's also server side Blazor, which doesn't need WebAssembly and still behaves like a SPA/PWA - no full page reloads, uses differential rendering, etc.

Edit: added further benchmarks
.NET Core/C# wins 10/10 tests vs OpenJDK/Java:
At the same time OpenJDK/Java wins 9/10 tests vs Node.js/JavaScript:

It should be noted that both the TechEmpower tests and these benchmarks were run on Linux. On Windows .NET Core/C# would likely be even faster."


Those benchmarks look very wrong. There is no way node is 8 times slower than ASP.NET on the same hardware.

Most likely they ran one instance of node on an 8 core machine. Node runs on a single core, while ASP.NET takes advantage of all cores.

You need to configure node as you would in production, using something like PM2 or StrongLoop Process Manager with an NGINX load balancer in front. This allows you to run 8 instances of node so that all 8 cores are used.

The results in this configuration will be very different.

Please tell us more on how node utilizes all cores. An article perhaps? I confess my lack of knowledge on getting Node to run on all cores.

Process managers like PM2 and Strongloop PM start multiple instances of your app, each of which runs a single thread. By default, they start a number of instances equal to the number of CPU cores.

If any of the instances crash, the process manager will restart them.


You can run an NGINX instance as well to load balance between multiple instances running on a single machine or across multiple machines as well. This is only needed in production. You can run your dev instance with just PM2 or Strongloop directly if you need to test performance. You usually only need to run one instance for most dev work though, which means you can just run node directly.

There is also the node "cluster" module, which you can use directly in your node server code to run multiple instances of your app. I haven't used this recently, but there were some performance issues with it before. Not sure if this has been improved.


Node also supports manually firing up threads for whatever purpose you may have. This is often used to create worker threads for any long-running CPU-intensive tasks. The main node thread and the worker thread can communicate, if necessary, using IPC.

It is very important in node to avoid blocking the main thread since no other requests can be handled in that node instance until the work is complete. Worker threads are a good option here.

They are not wrong.

Server config: 14 physical cores, 28 logical cores (HT), 32 GB RAM.

The Node.js plaintext code is running as a cluster of 28 processes.

So yes, ASP.NET Core really is that much faster, time to wake up.

Excellent information Ken. Looks like I have some major 2020 studying to do.

Thanks for the links @n-stefan. Good to know they are using clustering.

I still think something is not optimally configured in the node case though. I could believe a 2-3 times improvement, but 8 times still makes me very suspicious. Benchmark results are notorious for being sketchy or having one configuration optimal and another sub-optimal.

It would be interesting to see the number of requests that each node instance handled to make sure the distribution is fair. The fact that there were 89 errors makes me think that perhaps the distribution was not even, and so some requests errored out.

It would also be interesting to set cluster.schedulingPolicy = cluster.SCHED_RR; mode to see if that helps.

A comparison against PM2 or StrongLoop would also be good to see (might try this out if I have some time in the next few weeks).

The difference is smaller in the 5 other tests.

You could open a PR, if it's good, they will probably accept it. I'm also interested in having Node.js (and all others for that matter) run at its (their) true potential, unhindered by bad configuration and the like.


There's no doubt: the power of C# outshines all Javascript stacks in every way. (For now).

Will Blazor make it? Perhaps but there are no jobs.

There's too many questions like: Will it be the wave of the future? Is it a market disrupter? Will its eco system trump NPM and Javascript? Will MSFT start supporting thier adopters? Are they now all of the sudden loyal?

Will they rewrite VS Code in C# WASM? Never, Electron and Typescript work beautifully for millions of developers daily.

Chrome, the browser that won, will remain a Javascrpt friendly stack.

Many large corporate websites are aleady running Isomorphic Javascript stacks? Need more power? Spin up another server.

Node is making progress on CPU agnostic design. Compiled Javascript in WASM will happen.

Both Java and Javascript are more popular than C# in 5th or 6th place.

Finally, most of people who only grew up on Javascript dislike MSFT passionately. Their only view of MSFT was the inane Internet explorer and Edge. MSFT caused them as much pain as their desktop crowd.

Of course there are not many jobs YET, server-side Blazor launched with .NET Core 3.0 only this September, while client-side Blazor is still in preview and will launch in May 2020, if all goes according to plan.

It is possible to host Blazor on Electron for desktop apps:
However, they haven't stopped there:
It does away with Chromium and Node for significant download size and memory footprint savings.

The newer IEs were arguably much better than older ones, while Edge was better still and now there is Chromium based Edge, so nothing left to complain about.

One of the main selling points of Node was a relative speed advantage: no longer true. Another was enabling same language development across front- and backend while others didn't: also, no longer true.

Hell, Python is most popular now and it's a slow, niche language, only ideal for ML/AI. Already for webapps there are many alternatives that are far better and for game development you can forget about it.

Oh yes, some people hate and will hate MSFT no matter what, and that has nothing to do with the quality of .NET Core/Blazor.


I'm junior, but reading the article I thought great for C# guys, I mean welcome to the web, but maybe I'm ignorant on this assuming that we basically have this with JS/TypeScript? Why move off that ecosystem that's only exploding with more opportunities to something that's catching up. With all that's going on in JS I'm just not sure there would be a problem Blazor solves that's not already solved... Am I wrong? I am just speculating on this latter point, so please share your wisdom Dev crowd. :)


We'll know the goodness of blazor once the jobs show up. Today they're not around.

But yes, I agree with you, why Blazor? We already have it all.

For me blazor for the web it's like Xamarin for mobile, I'm an old MS developer, and I can create a functional app in 2 days after starting with blazor. I don't know how much time would take to do the same if I start with angular.

Yes both React and Angular have ramp up time but the data binding concepts you know from Razor are the same.

You'll have no problem learning React and Angular. The need for React and Angular people exceeds supply which is good.

Are you serious, the JavaScript ecosystem is a bloody nightmare, it reinvents itself every 2 years. That Typescript your on about is a MSFT product. The front-end is ripe for languages like C#. Blazor has a bright future.

We'll see and prove it by job openings and salaries.

Yes Typescript is MSFT, in particular, Anders Helsberg, the C# architect. His work has always been excellent.


While I'm also less than enthusiastic, I would counter that MS open source has been very good overall. Silverlight was never floss. .Net Core has seen some really great strides and it's a decent option.

I still prefer node and react, and for web assembly find rust+yes more compelling. I wouldn't about C# as an option on the backed, I just don't like Blazor.


When I speak about C# open source being dead, I'm comparing it to NPM. NPM alone is a million times more robust. Right now, Blazor open source contributions are laughable. I don't feel that will change much. MSFT has been sleeping while they built Azure. They are 10 years too late.


I get this, and I see your point. Like every other aspect of engineering, it's all about balance. You don't want to jump on the latest thing just because it's new. But if you're building something new, or doing a major rewrite it's useful to look at newer technologies.

The key is focusing on what problem you're trying to solve. If the new technology can solve the problem with a low enough amount of effort, why not? If you have a tried and true system and it can solve the problem without negative side effects, choose that.

I like to keep an eye on emerging technologies and have another tool in the toolbox if needed.


I don't know about Blazor, but Web Assembly itself is officially the 4th language supported by browsers. This will be the future, whether we like it or not.

In my opinion, of course.


Paraphrased arguments against Blazor...

"JS gives us everything" -- I think the JS ecosystem is a morass of command line tools. That you need 15 different things to make a web app is just horrible. I don't dislike JS as a language, but I like even more the ability to write front-end code AND back-end code in C#. No need to recreate the same class as C# version and then JS version, etc.

"Microsoft is bad/proprietary" -- I've been a Mac zealot from the 80s but am embracing .NET Core and Blazor wholeheartedly. They're both open-source and cross-platform friendly. I write Blazor at work on a Windows machine and then come home and write Blazor apps on my Mac.

"No work for Blazor devs" -- learn Blazor and you've also learned .NET Core, (probably) Entity Framework Core, Razor, C#, etc. Lots of call for those skills. It's not like learning Silverlight in that respect.

I'm working on rewriting an existing app for our organization as a "test" for where we go from here, and while we still have maybe 30 days before we ship (it's server-side Blazor, not WASM), I imagine the next project we start will be using Blazor, too.


It's funny, I remember listening to a podcast about this in late 2017. Blazor has a lot of potential and they are running with it full steam ahead. As some one who really enjoys C# and all the awesome extensibility of it, I really hope this catches on the job market.


"The .NET Framework and other runtime files need to be downloaded (one time)" that sounds to me like the Java in the web of old.

As a Linux user I wonder why in the name of Zeus and all that's holy would I want to put .NET (assuming that I could) in my system just to use a webapp? having modern JS, Typescript and now Wasm?. If some webapp ask me to install something besides my browser, personally, I'm out. And bringing back the old browser/runtime incompatibilities, platforms with less support, etc. when the industry as a whole is trying to standardize and minimize the footprint, this really looks like a huge setback, the comeback of IE only web.

Also I'm not sure the licensing situation of .NET nowdays but just the fact I'm wondering seems absurd to me; why would anyone (who is not forced to) choose to develope in a restricted platform? specially when there are so many amazing choices?.

Is there something amazing I'm missing here or this is just a tool for those already involved in the MS ecosystem?


If some webapp ask me to install something besides my browser, personally, I'm out.

That's not how this works.

They've ported the .NET run-time to WASM - so this will download and run transparently to the user, just like any other JavaScript framework.

This doesn't bring back any "old browser/runtime incompatibilities" either - as with any JS framework, you'll deploy (or link from a CDN) the version of the framework required by your app.

The framework itself isn't very big compared to most of the bloated mess that gets deployed using bundlers with plain JS today.

when the industry as a whole is trying to standardize and minimize the footprint, this really looks like a huge setback, the comeback of IE only web

No. This is just a framework, built on that same stack of open and standardized technologies.

Also I'm not sure the licensing situation of .NET nowdays but just the fact I'm wondering seems absurd to me; why would anyone (who is not forced to) choose to develope in a restricted platform?

What restrictions?

This is based on .NET Core, not the old .NET - to my knowledge, this entire platform (framework, libraries, tools) is open source with pretty liberal licensing.

Is there something amazing I'm missing here or this is just a tool for those already involved in the MS ecosystem?

Yep, pretty much.

Though what could make this interesting in the longer term, is access to a wide variety of languages (besides C#) that can compile to .NET bytecode.

It's also just interesting to see the kind of fusion of worlds that's happening here - being able to deploy a VM kernel to WASM, just as you'd deploy any normal JS framework or library... It's kind of exciting to see walls between client and server language worlds coming down in this way.

Front end developers have been forced to eat some flavor of JavaScript for decades now - it's just kind of liberating to see something different being added to the menu, finally 😉


Ohh I get it, when I saw "The .NET Framework and other runtime files need to be downloaded (one time)" it felt like when Frodo puts the ring, and I saw The Lidless Eye and it looked back, but I'm not using Windows so that's ok.

I'm glad that is just something related to MS devs, I got rid of Java runtime years ago and I'm not planning to replace it for another.

And yes, I'm also dreaming with a world where you can live without JS. :D

Thanks for the clarification :) , I can go back to my cave now and rest...


This sounds very similar to GWT (though, modernized to run using webassembly and using C# instead of Java). Am I wrong about that?

Several things killed GWT:

  1. GWT applications were hard to debug since the generated JS was minified.
  2. GWT applications tended to have lots of spaghetti-like interactions with the server because it's easy to make RPC calls when everything is written in the same place, in the same language.
  3. The skills and thought processes required to create a good front-end application are quite different from those required to create a good back-end one (regardless of the technology you use).
  4. Google lost interest in the technology.

#1 might be made irrelevant if sourcemaps are supplied. #4 is probably irrelevant since MS seems lately to be a better steward of OSS.

#2 and #3 really are big issues with this kind of tech. Though, I'm interested to see where this goes.


I worked on several projects around 8 years ago using GWT and from my experiences the biggest drawback was the lack of the open source community support and boilerplate code to make it more manageable. Like adding a new place had big overhead. Wiring places, activity mapper adding view, we had to at least touch 10 Java classes just to add a new view.

I somehow couldn't agree with some of your points:

  1. GWT application are not hard to debug, classic / super dev mode imho doesn't make much different to me. I prefer to use the super dev mode, debug directly using chrome devtool.

  2. Depends how you make your application. We were using activity and places that was introduced in early 2013 or something was a big help. We followed Model View Presenter pattern and used UI binder. Basically each UI Component is isolated and doesn't have any business logic, it just call the presenter on user interaction (button pressed, value changed, etc).

  3. We had it separated between the client and server code and any of our programmer could work on one UI part and never care about the presenter / activity part. Tbh I see the similarity with dumb and smart component pattern in angular / react.

  4. We had hot reload without restarting server. We used standalone tomcat + GWT plugins in eclipse. Once we start the tomcat the gwt dev server started on itself. Launch setup is not much different than any other spring boot based project and dominating our software landscape atm.

GWT was dead because noone liked it, it was complex and hard to use, gwt 3rd party library was near to non existence. We also used RPC which only useful for that application. We couldn't leverage it. I wish we used rest backend already.

Sometimes you will need to use native javascript, so what you do, you write javascript code wrap it to your own java class using JSNI. I tbh dislike JSNI, it shows the limitation of GWT.


Good point about the lack of community around GWT. It was never properly supported by Google and once they lost interest in it, GWT was as good as dead.


I don't know... not really convinced here. All of this sounds awfully familiar to GWT - just for .NET. And we all know the fate GWT has met. It struggled with API compatibility ("Use full Java! ... except..."), the server restarts were a pain (just to see a minor UI change you had to restart the whole thing) and HTML integration was not nearly on the same level as it is in "native" JavaScript.

I would prefer C# over JavaScript any day so it would be nice to see this succeed at large, but I wouldn't bet on it.


I said that Blazor and similar frameworks would be the future of web development when I watched Steve Sanderson's talk a couple of years ago. I'm really glad MS got behind this in a big way.

Blazor front end development has a way to go yet before it's ready for prime time (especially the debugging story) but I think it's all coming together we'll and soon. I can't wait.


Other than the initial payload size, my biggest issues with Blazor (and ASP.Net MVC) projects is that they're largely mirrored trees, making it harder to navigate the controller, models, views and styling together even though you work on them together. I tend to favor feature oriented structures where things are together by feature, not type of tech.


Nothing is stopping you from organizing by feature instead of by type. Might require a slight change to some configuration, but it's possible and even encouraged.


We need better documentation and books, the only book we have in near future will be on sale on May of current year...


Microsoft is known for their outstanding documentation. You can find break downs of every service, operating system and API they have available. I doubt that the documentation for Blazor is that shallow.


I agree. Documentation has accelerated a lot recently, and Microsoft has provided information to really get you going. The courses at Pluralsight have been updated very recently to keep up with the current version. There's information out there, but we certainly need more.

More than once I've run into things I wanted more information about and found nothing online, forcing me to improvise the best way I see fit. Within the next 6 months, I think that situation will improve.


Thanks for the article! How do you think we'll be talking about Blazor at the end of 2020? Do you think Blazor will be widely used in production?


I think we'll see significant adoption by the end of 2020. We'll see a lot of Web Assembly industry wide, and .NET folks adopting Blazor to get there.

But I think "widely" used in production will take a few years. One thing Blazor has going for it: it's an add on technology, not completely from scratch. It's a small step for ASP.NET developers and a smaller step for .NET Core developers. This will spread adoption as they have the skills they need, and "backend" developers can more easily build front end applications.

One thing it has going against it is the fact that it's Microsoft and there's still some developer aversion to that platform. Also at this time, an ASP.NET Web API coupled with React or Angular works great. There may not be enough "pain" in that process to push people towards Blazor.


That's great that C# developers have a new toy and everything, but I can't keep myself from objecting that

This will spread adoption as they have the skills they need, and "backend" developers can more easily build front end applications.

is a major understatement about what kinds of skills you need to build front end applications. It's not just the languages you use.


Thanks and that makes a lot of sense. For developers already in the Microsoft ecosystem, it will probably be a no-brainer to adopt Blazor. I agree with you that winning developers over from other platforms probably won't happen as easily. But it will be great to have even more excellent choices for web development!


I am very happy about all the Blazor roadmap, in fact, I am very happy about all things Microsoft has done, and are doing ... Microsoft is different of the past long time ago ... But always there will be haters based in the past. Microsoft bring .NET Core, after that improved it bringing .NET Core 3 with Windows Form and WPF to help those with solutions made in old .NET bringing all together to move on. Microsoft made ML.NET for .NET Developers be at home, and now Blazor ... I am very happy about Blazor and now I can see it right here working ... And I will try it and I'll give support ... Other thing MS made great is new Edge based in chromium, I have used since the beginning and I've given support and it is my Default Browser,and I am liking very much, I use firefox Developer to code since CSS Grid, beacuse I don't like Bootstrap, in my viewpoint CSS Grid with a little flexbox in some one direction and Vanilla JavaScript I can create what I need with less code and less bloatware (but is my way of thinking), and Fiferox is my second preferred web browser and I don't like chrome, is just about do not like ... C# is my favorite language, is beautiful, C# 8 changed switch in a very good way ... I like to code JavaScript too if is worth it is my second language, I don't like jQuery or old versions ES5 ... I enjoy JavaScript ES6+, I like Node runtime and React Library ;) I think that Blazor will give me more flexibility, but I'm sure that somethings will be smart to build in JS and other in Blazor ... But one thing I am very sure, Microsoft is making a excelent work and it deserves to be recognized for this ... And this is good for everyone ...


I think the step after that would be streaming websites. Zero code runs on the client side, everything happens on the server. All the server sends back is a visual feed / pixels. Much like the cloud gaming service Google Stadia where the game is rendered at the server and send back to the user. This might be a bit too far fetched today, but I'm sure it will happen eventually.

Pros: It will resolve many issues like compatibility and performance. Also you no longer have to wait until the browsers add new feature supports, you can make them yourself. You can use ANY language your server supports. Doesn't even have to be HTML. Websites will no longer be constrained to traditional scroll-the-text-and-pictures. The possibilities are truly endless.

Cons: It will probably use up more bandwidth (or not) and users will no longer be able to block ads (this could be a pro for the site owners though).


Blazor - .net equivalent of java's GWT, Vaadin. Nice to see that they are jumping into WA compared to all the other "open" languages/libraries/frameworks.


WebAssembly, unlike Blazor, has nothing to do with .NET. Microsoft is merely taking advantage of a developing technology.

In addition GWT compiled forever and produced fat & heavy JavaScript, again nothing like WebAssembly.

The major question going forward would be how bloated the relevant webassembly files generated at the end would be.

So far C#, as well as C++, are showing near native speeds.


Probably reinventing all the history and evolution of development for the computer itself - First very close to the machine and with time - further and more bloated, with the slight difference - the target platform/environment is the Web (Browser).


What are pros / cons compared to Node?


sips whisky and waits for the web assembly revolution

It's not quite here yet. Close. Blazer takes it a good couple steps.


Not quite but it's gaining momentum and I wouldn't bet against it. I wouldn't build a "golden goose" application with it yet, but it's maturing quickly.


So basically, from what I understand, it does the same thing ActiveX and Java Applets did back in the day?

And don't we already have Unity and various other WASM frameworks for browser games?

Basically the way I see it, this is the same thing .Net does with everything. Instead of devs learning a language they incorporate it poorly into the framework (see React.NET).

Not to be the one carrying the pitchfork but I don't really see a (near) future where we start packaging JS as binary.

There's also a host of other issues ranging from browser compatibility to security settings that disable wasm features and things like chink splitting which JS already does well enough. Though that last one I presume should exist as a loader mechanics.


Seems nice. C# code gets converted to JS using the WebAssembly?


Well, sort of. C# can get converted to JS that makes calls into the .NET runtime, and it's possible to make interop calls between JS and .NET, and vice versa. It's still a work in progress.

You can just write C# to do everything you'd need to do but I'm not sure that's the best approach. It depends on what you're trying to accomplish. From what I know at this point, a well designed Blazor application will use components based on the problem you're trying to solve. Does it need a lot of server processing, or client processing? That will determine not only the type of Blazor app you create, but that will dictate the composition of the code as well.


I have my doubts and I'll definitely be sitting on the sidelines for this one, but I think the big thing going for blazor would be the apparent 'difficulty' in reverse engineering the bytecode, which I can see many a decision maker wanting to protect their Intellectual Property in this fashion. Although this has an equal and opposite reaction, which would be the difficulty of debugging, but this is based on the traditionally way of debugging using the browsers' dev tools. Perhaps this will be a total moot point in the near future.

Regarding client side speed tests, and please forgive my ignorance on this matter, but does Web Assembly have access to the clients' multicore processors, if so this would be another plus as my understanding of JS, <ignorance> is although you can thread using 'workers', they are running on one core.</ignorance>


I love C# and am gonna try that out


I think only use of Blazoris that we can create JavaScript like client side application without using JavaScript but by just using C#. Is there any better use case to use Blazor?


Thanks for the articles on Blazor. I am curious how you would describe the Uno Platform as compared to Blazor? A comparison article would be helpful. Thanks again.