5 ms·

.Net with Blazor.net is pretty neat. C# doesn’t get a lot of love on HN, but we’re launching our first Blazor app in production this week and it’s been pretty

.Net with Blazor.net is pretty neat. C# doesn’t get a lot of love on HN, but we’re launching our first Blazor app in production this week and it’s been pretty easy to use.

legulere 8y ago
Blazor is (currently) using the mono .net interpreter compiled to WebAssembly. This seems to me more of a proof of concept than something you would really want to use. With garbage collection support landing in WebAssembly we might see compilation of .net IL to WebAssembly, but that’s still out in the future.
- eksemplar 8y ago
  We found it good enough to build internal apps. Better than our current JS setup because it’s far more productive. It’ll make its way into .net core 3.0, so I think it’s more than just a poc. It’s early of course and not very flexible, if you want to build something it wasn’t meant for, it breaks.
  - singularity2001 8y ago
    what's the performance penalty of the mono VM?
    - eksemplar 8y ago
      Performance is fine, but it’s still too big for slow internet. A simple form for turning in signed data and starting an internal service is easily a few MB. Which isn’t a problem for internal solutions that never leave the administrative network, but we’ll keep doing vue and graphql Apollo for our apps that have to function on mobile networks for the time being.
- mattferderer 8y ago
  The really cool thing about Blazor is currently with a couple small changes, you can switch it to a server side "Razor Components" app. The idea behind the server side concept is that it uses Web Sockets to tell the browser what changes to make. All the logic happens on the server side. There are a lot of pros & cons here to this way. Some pros are a fast initial render & small amount of bytes needing to be sent. Cons are you need internet access & render changes aren't as fast as client side. This biggest pro I see though is being able to develop a front end app that you can later switch to Blazor/Web Assembly with the client taking over part of the logic when Blazor & Web Assembly are less experimental. For internal apps, or apps where you know the internet/network connection should always be good, this is a great way to go.
mathw 8y ago
We had a look at Blazor at work the other week. My colleagues liked it, but on my computer the tooling crashed when asked to build the standard template project. Like a lot of things these days, Blazor has a website way more polished than the actual product. It's very interesting, but I'm surprised you find it ready for use in production.

.Net with Blazor.net is pretty neat. C# doesn’t get a lot of love on HN, but we’re launching our first Blazor app in production this week and it’s been pretty easy to use.

legulere 8y ago

Blazor is (currently) using the mono .net interpreter compiled to WebAssembly. This seems to me more of a proof of concept than something you would really want to use. With garbage collection support landing in WebAssembly we might see compilation of .net IL to WebAssembly, but that’s still out in the future.

eksemplar 8y ago
We found it good enough to build internal apps. Better than our current JS setup because it’s far more productive. It’ll make its way into .net core 3.0, so I think it’s more than just a poc. It’s early of course and not very flexible, if you want to build something it wasn’t meant for, it breaks.
- singularity2001 8y ago
  what's the performance penalty of the mono VM?
  - eksemplar 8y ago
    Performance is fine, but it’s still too big for slow internet. A simple form for turning in signed data and starting an internal service is easily a few MB. Which isn’t a problem for internal solutions that never leave the administrative network, but we’ll keep doing vue and graphql Apollo for our apps that have to function on mobile networks for the time being.
mattferderer 8y ago
The really cool thing about Blazor is currently with a couple small changes, you can switch it to a server side "Razor Components" app. The idea behind the server side concept is that it uses Web Sockets to tell the browser what changes to make. All the logic happens on the server side. There are a lot of pros & cons here to this way. Some pros are a fast initial render & small amount of bytes needing to be sent. Cons are you need internet access & render changes aren't as fast as client side. This biggest pro I see though is being able to develop a front end app that you can later switch to Blazor/Web Assembly with the client taking over part of the logic when Blazor & Web Assembly are less experimental. For internal apps, or apps where you know the internet/network connection should always be good, this is a great way to go.

mathw 8y ago

We had a look at Blazor at work the other week. My colleagues liked it, but on my computer the tooling crashed when asked to build the standard template project. Like a lot of things these days, Blazor has a website way more polished than the actual product. It's very interesting, but I'm surprised you find it ready for use in production.