17 ms·

Blazor, a framework for browser-based .NET apps using WebAssembly [video]

139 points by quickthrower2 8y ago

quickthrower2 8y ago
This framework is still fledgling, however it is very exciting for a .NET developer, not because it's a shiny new thing to learn, but because it's the opposite ... it's allowing you to reuse existing skills to code for the web, while seemingly allowing you to create a React-like architecture of components / state. All using a decent language C#. This is simplifying things if you are already doing a full stack and working half the time with JS/TS and the other half with C#. I hope MS really get behind this and see it through to a production ready version.
- knocte 8y ago
  > All using a decent language C# F# is also supported, and potentially any .NET language.
- eksemplar 8y ago
  We’re a .net house, or we see to be, so I should be embracing this like you are. I’m not though, not because it’s not cool and all, but because js front end has so many things that aren’t in .net. I mean, where is the graphql and Apollo like functionality in .net? How do you make a pretty reactive frontend easier and faster with .net compared to vue/react/angular? How big does the browserbased app get when it has to load .net libraries? Maybe I’m just not seeing it, but I honestly think what laravel is doing with PHP on the backend and vue on the front end is the brilliant way of approaching web apps and I think what Microsoft is doing with web assembly is going to be a needlessly complicated mess that’s really, really unproductive in terms of time to market. And I think they are mainly doing it because Microsoft never made their own JS front end. I’ve been following it for a while too, and I see a lot of the xamarin disaster in it.
  - grokys 8y ago
    If you're interested in seeing how a GraphQL client might look in .NET, over at GitHub we've been working on an experimental LINQ-like GraphQL client for our APIs: https://github.com/octokit/octokit.graphql.net/ https://github.com/octokit/octokit.graphql.net/ It only supports the GitHub GraphQL API right now, but everything is generated from the schema so it should be possible to make it support other APIs.
    - Serow225 8y ago
      Thanks!
    - eksemplar 8y ago
      .net core really should adopt it, that would make it really competitive to node on the backend in terms of prototyping.
  - cm2187 8y ago
    First this is not just websites. It is also webapps (think universal, cross platform client apps). Then the assemblies will be cached and I understand they are working on getting them small. Silverlight wasn't that bad in term of load time. If the website really deserves a SPA (creating a blog in a SPA is ridiculous), people expects the website to take a little time to load even with javascript, and it does. My online broker trading platform does, webmails do, etc. For reactivity, I am not sure I get your point. With async/await it is going to be trivial, and .net on wasm will likely be faster than javascript.
    - deleted 8y ago
      [deleted]
  - pjmlp 8y ago
    I am yet to bother with GraphQL and Appolo, and I bet in 5 years they will be in same place as NoSQL databases are today. I honestly don't see any benefit over plain Web APIs.
    - eksemplar 8y ago
      Then you haven’t used them. They are to rest apis what rest were to soap times ten. You don’t have to take my word for it though, try it yourself: https://graphql.org/swapi-graphql/ https://graphql.org/swapi-graphql/
      - pjmlp 8y ago
        You mean like dropping the documentation and schema validation tools that REST still wasn't able to match beyond what Swagger kind of offers?
      - learc83 8y ago
        That's a very strong statement. I have used them and I dont agree with this at all. I suppose next you're going to say I haven't used them enough?
        eksemplar 8y ago
        I think you may have been fortunate enough to use a lot of well documented rest APIs. I work in the public sector, we integrate with more than 600 different IT systems. I’d say around 10% of them have the documentation they ought to. With graphql, the API is the documentation. On our own end, it’s improvee production and quality because it’s faster to build an API with it, that lives up to our standards for APIs. It’s also harder to fuck it up without realizing because it’s typed and forces schemes. The last advantage is that it allows for an easy way to get the data you need from a general query, that might not be important in a lot of places, but when you build apps for workers who use them in a rural setting, it’s kind of nice to minimize the data they need to transmit to the bare essentials. You could do that with a rest api, but it would take a lot more time to implement.
  - pknopf 8y ago
    What about tree-shaking/bundling/splitting? I don't see that happening, which means that you have to literally download the dlls needed to render every single page/component.
    - GiorgioG 8y ago
      Tree-shaking is already there: https://github.com/aspnet/Blazor/issues/1076 https://github.com/aspnet/Blazor/issues/1076
    - mattferderer 8y ago
      Blazor is an experiment. They're trying to get an MVP & figure out a solid foundation. There are a ton of performance wins they can do later. Those have little value right now.
  - recursive 8y ago
    .net was doing graphql back when it was called odata.
- xab9 8y ago
  Whenever Microsoft tried to do web frontend it was "not really good" (it was borderline catastrophic). Asp spaghetti, aspx components, viewstate handling, razor templates etc. When I worked with .net guys (which happened quite often) 9 out of 10 had been like wow, I don't have to touch frontend, because MS will solve that for me "somehow", plus the frontend is messy and crap and javascript is a terrible language and C# rocks (but F# even rocks more) and I'm not going to learn all this sillyness (because I want to reuse my skills). At least with new-angular they feel a bit better and they can praise typescript, because typescript is "just like C#". Let's just hope noone pulls an angular-one-to-two style rewrite/clusterfuck...
  - voltagex_ 8y ago
    I started professional web dev doing ASP.NET around the time of the ASP 2 to 4 transition. After looking at a Vue/Typescript/Webpack template that had 400 dependencies, give me User Components and ViewState any day.
    - keithnz 8y ago
      I was doing some work recently on an old asp.net app, and rather than rocking the boat, I just updated it with the existing webform / viewstate structure... which I haven't touched for years. Was weirdly smooth and easy to do things. There is some disadvantages to the approach... but there is definitely something kind of nice about the approach.
      - thrower123 8y ago
        It's so good that they brought it back as a first-class thing, see the newer Razor Pages stuff. I'd definitely use that for any kind of quick little internal applications, there's so much less ceremony involved.
  - jrs95 8y ago
    Razor templates are quite good as far as server side templating goes imo
- cm2187 8y ago
  I heard in previous podcasts that they surveyed large clients and that the response was enthusiastic to this technology. My guess is that they are serious about it. Now we must distinguish blazor and mono on wasm. Mono on wasm allows the .net runtime to run in webassembly. Blazor uses the mono runtime and creates a UI framework. I think the game changer is the .net runtime in wasm. Once it is production ready, I am sure we will see competing UI frameworks, some possibly even based on xaml.
  - mattferderer 8y ago
    Competing UI frameworks exist. Blazor is just one. See Ooui & Uno for others.
- mattferderer 8y ago
  A lot of people seem to be voicing strong hate without understanding what this even is. (Not the parent comment, but others) Wasm (Web Assembly) is still early in development. It's looking like it will create a high performance & excellent VM to compile code to for the browser. This is great for any language. A lot of proposed features could give it all the same features you have in JavaScript. But those features are only proposed. Lin Clark gives a great intro on this podcast - https://pca.st/5rjS https://pca.st/5rjS Blazor is an experiment at utilizing Wasm to do JavaScript like things with C# in the browser. I've never heard anyone say use it for production yet. The YouTube video here is 1 of the best talks you'll see on it if you watch it. I was lucky enough to attend in person. You can use Blazor without a server to create static sites & host them on servers like Netlify. Performance & file size isn't something they've put much effort into at all yet on Blazor. Way to early & easier problems. There are other experiments going on with .NET, Mono & Wasm . See Uno & Ooui. Steve Sanderson did an experiment a few years ago to see if this was even possible based on some interesting research he found. It grew from that. They have put a really awesome team behind it. It's gained a great following & has a very active Gitter channel that the MS team (notably PM Dan Roth) talks in. They're also quick to respond on GitHub.
dang 8y ago
Some recentish posts: https://news.ycombinator.com/item?id=16651709 https://news.ycombinator.com/item?id=16651709 https://news.ycombinator.com/item?id=16318076 https://news.ycombinator.com/item?id=16318076 https://news.ycombinator.com/item?id=14697520 https://news.ycombinator.com/item?id=14697520
jimmy1 8y ago
I really don't see how C# is decent anymore, can someone change my mind? I was all about it in the 2010-2013 days, but over time it just became more bloated and bloated. It's the new C++, where it tries to be everything for everyone. Every time a new version comes out theres a 500 page tome of all the new features added. Did we really need all those features? I would love it if I saw a new version of a language come out and it removes language features, wouldn't that be a change! It still has all the annoyances of java (the first thing you see in any C# file is a laundry list of imports), I am not convinced the profiling tooling is better. I will preface this with I am still bitter about the initial .NET core rollout which was a crapshoot and had no parity whatsoever with .NET Framework.
- quickthrower2 8y ago
  In the newer C# features there is a lot of syntax sugar, and you don't really have to use them. I don't think it is any more bloated than in 2013, and most C# code bases wont look much different to back then.
- alelefant 8y ago
  You are obviously free to dislike C#, but it seems silly to say they should stop adding features or should remove features. > Did we really need all those features? If you don't need them, don't use them. I've found the new features to be great. nameof, string interpolation, property initializers, exception filters, static imports, null propagator. And if you haven't used the language in awhile going back to 5.0 the async await features are fantastic. 7.1 introduced async Main which we've started using in console apps. I use all of these features every day. > I would love it if I saw a new version of a language come out and it removes language features Why, exactly?
  - bryanrasmussen 8y ago
    1. Some people dislike languages with a large instruction set 2. I will propose that programming languages are like anything else created by humans - some parts great, some parts not that great. Furthermore some parts of a language are used more than other parts, it should be hoped that the parts least used in any particular language are parts of that language that are not that great. Given these things it might be reasonable that some time you saw a new version of a language in which they said Feature X really sort of didn't make sense and anyway hardly anyone ever used it so we are removing Feature X. Adjust code accordingly. (probably there should be deprecation stage of a year or so with warnings)
maccio92 8y ago
This is really great! Excited to give it a try
caleblloyd 8y ago
Also https://www.youtube.com/watch?v=61qmX5eAPwI https://www.youtube.com/watch?v=61qmX5eAPwI which is a newer video and highlights some of the most recent Blazor 0.6 features. I am very excited about the possibilities this brings. Current frontend/backend solutions all seem to involve duplicating contracts in JavaScript. WebAssembly frameworks like Blazor will let us get back to programming in one language but keep the SPA-style experience for the UI.
paxys 8y ago
I am desperately waiting for Blazor to graduate from the "experimental" label so I can justify investing more time into it, but whatever little I have seen so far seems amazing. For someone who used to live and breathe C#, ASP.NET and Razor, this feels like a godsend.
wokwokwok 8y ago
There's a problem with Blazor, and that is that its not ready. Which is why they're shipping server side Blazor [0], which is all the stupid parts of Blazor with none of the benefits. Don't get me wrong, the idea of running .Net in WASM is very appealing to me... but server side Blazor is a daft idea, and it's a mistake. Here's the model: - Your component view state is rendered on the server. - A delta is sent to the front-end. - The frontend updates the DOM in the browser. - Any DOM event is sent to the server. - repeat. Seems ok? However, the problems here to understand are: 1) Every UI interaction, from mouse focus, to mouse drag, to click to button down, is sent down the wire to the server to be processed. For high latency situations, this will feel terrible. 2) Every client shares the same server cluster. As such, it scales badly; your application may perform well with 10 users, but for 100 users, you have 10x as much server work happening. Not business logic... UI logic. Will it scale? No one knows, but the money is on 'no'. The server scale-out demands will scale with people viewing the website; effectively this means the UI will lag out under load when the server is busy, the exact opposite of modern SPA applications and apps that remain superficially responsive under server load, and compounding issues generated from (1). 3) As many of the examples show, server side Blazor shows how you can execute arbitrary code on the server as part of your components (eg. fetch DB records). However, no vague consideration has been given to the authentication model for this. In fact, the stated high level goal is that razor components will 'with one click' work seamlessly on both WASM-mono and razor-components; ie. They are are naive of user roles and permission groups on the server, and expect to interact with an arbitrary backend 'service' with its own permission roles. (But that isnt what the examples show). These are not trivial problems, they are, unfortunately, insurmountable architectural issues with server-side Blazor. ...and the work around is a compromise. ie. You use javascript. Which... kind of makes it rather pointless. This is being shipped early for business reasons, not technical reasons. They should just wait for the WASM target to be ready; this will be a disaster, in my opinion. [0] - https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-6-0-experimental-release-now-available/ https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...
- martijn_himself 8y ago
  This is quite enlightening in that I'm very excited by the prospect of using C# in the browser without the downsides that came with Silverlight, but especially 1) seems to be a big negative! (I'm not sure I completely understand 2) and 3), does 2) only apply to server-side Blazor? Is 3) not inherent to all web development in that authentication on the client is 'disconnected' from users/ permissions on the server anyway?). As someone who is trying to wrap his head around all this, did they go with server side Blazor because browsers do not support all required WASM features yet? What is even the point of server side rendering?
jarcane 8y ago
I look forward to me getting very excited to try this with F#, only to find it requires a pile of hand-spun hacks only comprehensible to the most dyed-in-the-wool Visual Studio user, half-documented scraps of git repos that will only to get working, and will inevitably break completely upon the slightest update or change to your .NET installation.
- s369610 8y ago
  I suggest you check out fable if you haven't already, v2 just dropped the experience was pretty smooth (http://fable.io/ http://fable.io/)
- GiorgioG 8y ago
  I've given up on F# because MS only half-heartedly backs it. In the meantime C# continues to pick up more and more F# features.
aogaili 8y ago
GWT all over again..they tried to kill JS with Java and failed..good luck with C#...
- Kyro38 8y ago
  WebAssembly has different objectives than Java and is backed by the 4 major Browsers.
  - aogaili 8y ago
    I'm not criticizing WebAssembly but the selling points behind the framework which is a use case for WebAssembly. GWT users cared less about how it was compiling, and at the end of the day, they were building webapps using Java and Eclipse IDE along with the rest of the ecosystem. Which is exactly the selling points being presented here. For me this is history repeating itself.
    - k__ 8y ago
      Yes, lets see how big the runtime is and how "much" server is needed for interaction in the end...
- iso-8859-1 8y ago
  They failed because compiles took forever and you couldn't debug very well. With Graal and WebAssembly, performance might be better.
- tudelo 8y ago
  As someone still dealing with this, I really hope it isn't GWT all over again. Ever wait 30 minutes to see a simple change to a web page? sigh
plasma 8y ago
I worry this is close to Web Forms again.
- thomasz 8y ago
  The Problem with Web Forms was that it shoehorned statefull patterns that worked in desktop programming into http and thereby introduced very leaky abstractions. I see absolutely no reason why this should be a problem for frameworks like blazor.
- m_fayer 8y ago
  This is inspired by Vue/Angular. If you're familiar with those and dig into the docs you'll see that it's conceptually very similar. Nothing like Web Forms.
  - aikah 8y ago
    .
    - cm2187 8y ago
      No a server is not mandatory to run blazor. You can run blazor server side, where the client is routing all events to a server. But that's not the way it is designed to work by default. By default everything runs client side, you could run it from a static website.
- pknopf 8y ago
  I agree. WebForms/UpdatePanel was a half-baked solution to pick-up and drop-in .NET developers from WinForms to the web, while Blazor seems to do the same thing for server-side and client-side developers.
myl 8y ago
Very, very exciting! Expecially after the download size is reduced (as planned).
userbinator 8y ago
Yay, now all the bloat of .NET can spread into the browser too! </s> Seriously, I'm saddened to see all this overwhelming hype and "excitement" --- I am a developer myself, and just don't get it: I have used .NET apps before, and I could immediately tell it was such just from the speed (or lack thereof) and memory consumption --- the difference is obvious. It's the same with Java, which is not at all surprising. The absurd amount of object-oriented obfuscation I encountered in the few times I had to debug someone else's code in C# probably contributes to that too. Taking over a second just to load an extremely simple app from localhost in the demo says all I need to know about this --- "no thanks". Please consider your users' experience...
- GiorgioG 8y ago
  You have used .NET apps that were slow/mem consuming - have you ever considered that it’s the app developer’s fault? I can write a slow memory hogging app in C++ too. 1 second to load the whole app compared to the shitshow that is most SPA apps these days is a dream.
  - pknopf 8y ago
    Having two garbage-collected languages in the browser likely won't work out well.
    - GiorgioG 8y ago
      What does having N-number of GC'd languages have any relevance? Your OS is an "app browser" with a variety GC language-based apps running happily alongside one another (Go, Java, C#, Elixir, etc)
      - pknopf 8y ago
        Your OS is multithreaded, JavaScript isn't. Scrolling in your browser is bad enough when JS/dom has to many allocations.
        8y ago
nosjwshere 8y ago
why not compile private methods for the server and public for the client.
kodablah 8y ago
Didn't watch the video, but since the project doesn't make it clear, this is the Mono .Net interpreter compiled to WASM that is interpreting IL at runtime. The AOT .Net-to-WASM compiler is not a thing yet but is actively being worked on.
euroclydon 8y ago
I'm not a big Blazor fan, but mono-wasm is cool, and if the Blazor folks would isolate their DOM/JS interop, that would be a good, lightweight starting point for folks to play around with .NET in the browser.
sebringj 8y ago
This is a theme in that all major compiled languages will have an ability to publish to wasm as WebAssembly is a standard that allows this and we'll see more frameworks like this coming up for various ones. It will be nice for all the specific language camps and allow interoperability as well between them. Big win in general whatever you think of .NET but that's not the big picture.
deleted 8y ago
[deleted]
saary 8y ago
Would like to see a wrapper generator around C# libraries so they could be easily be loaded into node.js That would make all sort of integrations between legacy systems with existing C# support libraries and newer lighter node.js projects work without jumping through crazy marshaling hoops. Seems like a very interesting direction, embedding managed languages into JS.
- jbigelow76 8y ago
  Do you mean something like edge.js? https://github.com/tjanczuk/edge https://github.com/tjanczuk/edge

139 points by quickthrower2 8y ago

This framework is still fledgling, however it is very exciting for a .NET developer, not because it's a shiny new thing to learn, but because it's the opposite ... it's allowing you to reuse existing skills to code for the web, while seemingly allowing you to create a React-like architecture of components / state. All using a decent language C#. This is simplifying things if you are already doing a full stack and working half the time with JS/TS and the other half with C#. I hope MS really get behind this and see it through to a production ready version.

knocte 8y ago
> All using a decent language C# F# is also supported, and potentially any .NET language.
eksemplar 8y ago
We’re a .net house, or we see to be, so I should be embracing this like you are. I’m not though, not because it’s not cool and all, but because js front end has so many things that aren’t in .net. I mean, where is the graphql and Apollo like functionality in .net? How do you make a pretty reactive frontend easier and faster with .net compared to vue/react/angular? How big does the browserbased app get when it has to load .net libraries? Maybe I’m just not seeing it, but I honestly think what laravel is doing with PHP on the backend and vue on the front end is the brilliant way of approaching web apps and I think what Microsoft is doing with web assembly is going to be a needlessly complicated mess that’s really, really unproductive in terms of time to market. And I think they are mainly doing it because Microsoft never made their own JS front end. I’ve been following it for a while too, and I see a lot of the xamarin disaster in it.
- grokys 8y ago
  If you're interested in seeing how a GraphQL client might look in .NET, over at GitHub we've been working on an experimental LINQ-like GraphQL client for our APIs: https://github.com/octokit/octokit.graphql.net/ https://github.com/octokit/octokit.graphql.net/ It only supports the GitHub GraphQL API right now, but everything is generated from the schema so it should be possible to make it support other APIs.
  - Serow225 8y ago
    Thanks!
  - eksemplar 8y ago
    .net core really should adopt it, that would make it really competitive to node on the backend in terms of prototyping.
- cm2187 8y ago
  First this is not just websites. It is also webapps (think universal, cross platform client apps). Then the assemblies will be cached and I understand they are working on getting them small. Silverlight wasn't that bad in term of load time. If the website really deserves a SPA (creating a blog in a SPA is ridiculous), people expects the website to take a little time to load even with javascript, and it does. My online broker trading platform does, webmails do, etc. For reactivity, I am not sure I get your point. With async/await it is going to be trivial, and .net on wasm will likely be faster than javascript.
  - deleted 8y ago
    [deleted]
- pjmlp 8y ago
  I am yet to bother with GraphQL and Appolo, and I bet in 5 years they will be in same place as NoSQL databases are today. I honestly don't see any benefit over plain Web APIs.
  - eksemplar 8y ago
    Then you haven’t used them. They are to rest apis what rest were to soap times ten. You don’t have to take my word for it though, try it yourself: https://graphql.org/swapi-graphql/ https://graphql.org/swapi-graphql/
    - pjmlp 8y ago
      You mean like dropping the documentation and schema validation tools that REST still wasn't able to match beyond what Swagger kind of offers?
    - learc83 8y ago
      That's a very strong statement. I have used them and I dont agree with this at all. I suppose next you're going to say I haven't used them enough?
      - eksemplar 8y ago
        I think you may have been fortunate enough to use a lot of well documented rest APIs. I work in the public sector, we integrate with more than 600 different IT systems. I’d say around 10% of them have the documentation they ought to. With graphql, the API is the documentation. On our own end, it’s improvee production and quality because it’s faster to build an API with it, that lives up to our standards for APIs. It’s also harder to fuck it up without realizing because it’s typed and forces schemes. The last advantage is that it allows for an easy way to get the data you need from a general query, that might not be important in a lot of places, but when you build apps for workers who use them in a rural setting, it’s kind of nice to minimize the data they need to transmit to the bare essentials. You could do that with a rest api, but it would take a lot more time to implement.
- pknopf 8y ago
  What about tree-shaking/bundling/splitting? I don't see that happening, which means that you have to literally download the dlls needed to render every single page/component.
  - GiorgioG 8y ago
    Tree-shaking is already there: https://github.com/aspnet/Blazor/issues/1076 https://github.com/aspnet/Blazor/issues/1076
  - mattferderer 8y ago
    Blazor is an experiment. They're trying to get an MVP & figure out a solid foundation. There are a ton of performance wins they can do later. Those have little value right now.
- recursive 8y ago
  .net was doing graphql back when it was called odata.
xab9 8y ago
Whenever Microsoft tried to do web frontend it was "not really good" (it was borderline catastrophic). Asp spaghetti, aspx components, viewstate handling, razor templates etc. When I worked with .net guys (which happened quite often) 9 out of 10 had been like wow, I don't have to touch frontend, because MS will solve that for me "somehow", plus the frontend is messy and crap and javascript is a terrible language and C# rocks (but F# even rocks more) and I'm not going to learn all this sillyness (because I want to reuse my skills). At least with new-angular they feel a bit better and they can praise typescript, because typescript is "just like C#". Let's just hope noone pulls an angular-one-to-two style rewrite/clusterfuck...
- voltagex_ 8y ago
  I started professional web dev doing ASP.NET around the time of the ASP 2 to 4 transition. After looking at a Vue/Typescript/Webpack template that had 400 dependencies, give me User Components and ViewState any day.
  - keithnz 8y ago
    I was doing some work recently on an old asp.net app, and rather than rocking the boat, I just updated it with the existing webform / viewstate structure... which I haven't touched for years. Was weirdly smooth and easy to do things. There is some disadvantages to the approach... but there is definitely something kind of nice about the approach.
    - thrower123 8y ago
      It's so good that they brought it back as a first-class thing, see the newer Razor Pages stuff. I'd definitely use that for any kind of quick little internal applications, there's so much less ceremony involved.
- jrs95 8y ago
  Razor templates are quite good as far as server side templating goes imo
cm2187 8y ago
I heard in previous podcasts that they surveyed large clients and that the response was enthusiastic to this technology. My guess is that they are serious about it. Now we must distinguish blazor and mono on wasm. Mono on wasm allows the .net runtime to run in webassembly. Blazor uses the mono runtime and creates a UI framework. I think the game changer is the .net runtime in wasm. Once it is production ready, I am sure we will see competing UI frameworks, some possibly even based on xaml.
- mattferderer 8y ago
  Competing UI frameworks exist. Blazor is just one. See Ooui & Uno for others.
mattferderer 8y ago
A lot of people seem to be voicing strong hate without understanding what this even is. (Not the parent comment, but others) Wasm (Web Assembly) is still early in development. It's looking like it will create a high performance & excellent VM to compile code to for the browser. This is great for any language. A lot of proposed features could give it all the same features you have in JavaScript. But those features are only proposed. Lin Clark gives a great intro on this podcast - https://pca.st/5rjS https://pca.st/5rjS Blazor is an experiment at utilizing Wasm to do JavaScript like things with C# in the browser. I've never heard anyone say use it for production yet. The YouTube video here is 1 of the best talks you'll see on it if you watch it. I was lucky enough to attend in person. You can use Blazor without a server to create static sites & host them on servers like Netlify. Performance & file size isn't something they've put much effort into at all yet on Blazor. Way to early & easier problems. There are other experiments going on with .NET, Mono & Wasm . See Uno & Ooui. Steve Sanderson did an experiment a few years ago to see if this was even possible based on some interesting research he found. It grew from that. They have put a really awesome team behind it. It's gained a great following & has a very active Gitter channel that the MS team (notably PM Dan Roth) talks in. They're also quick to respond on GitHub.

dang 8y ago

Some recentish posts: https://news.ycombinator.com/item?id=16651709 https://news.ycombinator.com/item?id=16651709 https://news.ycombinator.com/item?id=16318076 https://news.ycombinator.com/item?id=16318076 https://news.ycombinator.com/item?id=14697520 https://news.ycombinator.com/item?id=14697520

jimmy1 8y ago

I really don't see how C# is decent anymore, can someone change my mind? I was all about it in the 2010-2013 days, but over time it just became more bloated and bloated. It's the new C++, where it tries to be everything for everyone. Every time a new version comes out theres a 500 page tome of all the new features added. Did we really need all those features? I would love it if I saw a new version of a language come out and it removes language features, wouldn't that be a change! It still has all the annoyances of java (the first thing you see in any C# file is a laundry list of imports), I am not convinced the profiling tooling is better. I will preface this with I am still bitter about the initial .NET core rollout which was a crapshoot and had no parity whatsoever with .NET Framework.

quickthrower2 8y ago
In the newer C# features there is a lot of syntax sugar, and you don't really have to use them. I don't think it is any more bloated than in 2013, and most C# code bases wont look much different to back then.
alelefant 8y ago
You are obviously free to dislike C#, but it seems silly to say they should stop adding features or should remove features. > Did we really need all those features? If you don't need them, don't use them. I've found the new features to be great. nameof, string interpolation, property initializers, exception filters, static imports, null propagator. And if you haven't used the language in awhile going back to 5.0 the async await features are fantastic. 7.1 introduced async Main which we've started using in console apps. I use all of these features every day. > I would love it if I saw a new version of a language come out and it removes language features Why, exactly?
- bryanrasmussen 8y ago
  1. Some people dislike languages with a large instruction set 2. I will propose that programming languages are like anything else created by humans - some parts great, some parts not that great. Furthermore some parts of a language are used more than other parts, it should be hoped that the parts least used in any particular language are parts of that language that are not that great. Given these things it might be reasonable that some time you saw a new version of a language in which they said Feature X really sort of didn't make sense and anyway hardly anyone ever used it so we are removing Feature X. Adjust code accordingly. (probably there should be deprecation stage of a year or so with warnings)

maccio92 8y ago

This is really great! Excited to give it a try

caleblloyd 8y ago

Also https://www.youtube.com/watch?v=61qmX5eAPwI https://www.youtube.com/watch?v=61qmX5eAPwI which is a newer video and highlights some of the most recent Blazor 0.6 features. I am very excited about the possibilities this brings. Current frontend/backend solutions all seem to involve duplicating contracts in JavaScript. WebAssembly frameworks like Blazor will let us get back to programming in one language but keep the SPA-style experience for the UI.

paxys 8y ago

I am desperately waiting for Blazor to graduate from the "experimental" label so I can justify investing more time into it, but whatever little I have seen so far seems amazing. For someone who used to live and breathe C#, ASP.NET and Razor, this feels like a godsend.

wokwokwok 8y ago

There's a problem with Blazor, and that is that its not ready. Which is why they're shipping server side Blazor [0], which is all the stupid parts of Blazor with none of the benefits. Don't get me wrong, the idea of running .Net in WASM is very appealing to me... but server side Blazor is a daft idea, and it's a mistake. Here's the model: - Your component view state is rendered on the server. - A delta is sent to the front-end. - The frontend updates the DOM in the browser. - Any DOM event is sent to the server. - repeat. Seems ok? However, the problems here to understand are: 1) Every UI interaction, from mouse focus, to mouse drag, to click to button down, is sent down the wire to the server to be processed. For high latency situations, this will feel terrible. 2) Every client shares the same server cluster. As such, it scales badly; your application may perform well with 10 users, but for 100 users, you have 10x as much server work happening. Not business logic... UI logic. Will it scale? No one knows, but the money is on 'no'. The server scale-out demands will scale with people viewing the website; effectively this means the UI will lag out under load when the server is busy, the exact opposite of modern SPA applications and apps that remain superficially responsive under server load, and compounding issues generated from (1). 3) As many of the examples show, server side Blazor shows how you can execute arbitrary code on the server as part of your components (eg. fetch DB records). However, no vague consideration has been given to the authentication model for this. In fact, the stated high level goal is that razor components will 'with one click' work seamlessly on both WASM-mono and razor-components; ie. They are are naive of user roles and permission groups on the server, and expect to interact with an arbitrary backend 'service' with its own permission roles. (But that isnt what the examples show). These are not trivial problems, they are, unfortunately, insurmountable architectural issues with server-side Blazor. ...and the work around is a compromise. ie. You use javascript. Which... kind of makes it rather pointless. This is being shipped early for business reasons, not technical reasons. They should just wait for the WASM target to be ready; this will be a disaster, in my opinion. [0] - https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-6-0-experimental-release-now-available/ https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...

martijn_himself 8y ago
This is quite enlightening in that I'm very excited by the prospect of using C# in the browser without the downsides that came with Silverlight, but especially 1) seems to be a big negative! (I'm not sure I completely understand 2) and 3), does 2) only apply to server-side Blazor? Is 3) not inherent to all web development in that authentication on the client is 'disconnected' from users/ permissions on the server anyway?). As someone who is trying to wrap his head around all this, did they go with server side Blazor because browsers do not support all required WASM features yet? What is even the point of server side rendering?

jarcane 8y ago

I look forward to me getting very excited to try this with F#, only to find it requires a pile of hand-spun hacks only comprehensible to the most dyed-in-the-wool Visual Studio user, half-documented scraps of git repos that will only to get working, and will inevitably break completely upon the slightest update or change to your .NET installation.

s369610 8y ago
I suggest you check out fable if you haven't already, v2 just dropped the experience was pretty smooth (http://fable.io/ http://fable.io/)
GiorgioG 8y ago
I've given up on F# because MS only half-heartedly backs it. In the meantime C# continues to pick up more and more F# features.

aogaili 8y ago

GWT all over again..they tried to kill JS with Java and failed..good luck with C#...

Kyro38 8y ago
WebAssembly has different objectives than Java and is backed by the 4 major Browsers.
- aogaili 8y ago
  I'm not criticizing WebAssembly but the selling points behind the framework which is a use case for WebAssembly. GWT users cared less about how it was compiling, and at the end of the day, they were building webapps using Java and Eclipse IDE along with the rest of the ecosystem. Which is exactly the selling points being presented here. For me this is history repeating itself.
  - k__ 8y ago
    Yes, lets see how big the runtime is and how "much" server is needed for interaction in the end...
iso-8859-1 8y ago
They failed because compiles took forever and you couldn't debug very well. With Graal and WebAssembly, performance might be better.
tudelo 8y ago
As someone still dealing with this, I really hope it isn't GWT all over again. Ever wait 30 minutes to see a simple change to a web page? sigh

plasma 8y ago

I worry this is close to Web Forms again.

thomasz 8y ago
The Problem with Web Forms was that it shoehorned statefull patterns that worked in desktop programming into http and thereby introduced very leaky abstractions. I see absolutely no reason why this should be a problem for frameworks like blazor.
m_fayer 8y ago
This is inspired by Vue/Angular. If you're familiar with those and dig into the docs you'll see that it's conceptually very similar. Nothing like Web Forms.
- aikah 8y ago
  .
  - cm2187 8y ago
    No a server is not mandatory to run blazor. You can run blazor server side, where the client is routing all events to a server. But that's not the way it is designed to work by default. By default everything runs client side, you could run it from a static website.
pknopf 8y ago
I agree. WebForms/UpdatePanel was a half-baked solution to pick-up and drop-in .NET developers from WinForms to the web, while Blazor seems to do the same thing for server-side and client-side developers.

myl 8y ago

Very, very exciting! Expecially after the download size is reduced (as planned).

userbinator 8y ago

Yay, now all the bloat of .NET can spread into the browser too! </s> Seriously, I'm saddened to see all this overwhelming hype and "excitement" --- I am a developer myself, and just don't get it: I have used .NET apps before, and I could immediately tell it was such just from the speed (or lack thereof) and memory consumption --- the difference is obvious. It's the same with Java, which is not at all surprising. The absurd amount of object-oriented obfuscation I encountered in the few times I had to debug someone else's code in C# probably contributes to that too. Taking over a second just to load an extremely simple app from localhost in the demo says all I need to know about this --- "no thanks". Please consider your users' experience...

GiorgioG 8y ago
You have used .NET apps that were slow/mem consuming - have you ever considered that it’s the app developer’s fault? I can write a slow memory hogging app in C++ too. 1 second to load the whole app compared to the shitshow that is most SPA apps these days is a dream.
- pknopf 8y ago
  Having two garbage-collected languages in the browser likely won't work out well.
  - GiorgioG 8y ago
    What does having N-number of GC'd languages have any relevance? Your OS is an "app browser" with a variety GC language-based apps running happily alongside one another (Go, Java, C#, Elixir, etc)
    - pknopf 8y ago
      Your OS is multithreaded, JavaScript isn't. Scrolling in your browser is bad enough when JS/dom has to many allocations.
      - 8y ago

nosjwshere 8y ago

why not compile private methods for the server and public for the client.

kodablah 8y ago

Didn't watch the video, but since the project doesn't make it clear, this is the Mono .Net interpreter compiled to WASM that is interpreting IL at runtime. The AOT .Net-to-WASM compiler is not a thing yet but is actively being worked on.

euroclydon 8y ago

I'm not a big Blazor fan, but mono-wasm is cool, and if the Blazor folks would isolate their DOM/JS interop, that would be a good, lightweight starting point for folks to play around with .NET in the browser.

sebringj 8y ago

This is a theme in that all major compiled languages will have an ability to publish to wasm as WebAssembly is a standard that allows this and we'll see more frameworks like this coming up for various ones. It will be nice for all the specific language camps and allow interoperability as well between them. Big win in general whatever you think of .NET but that's not the big picture.

deleted 8y ago

[deleted]

saary 8y ago

Would like to see a wrapper generator around C# libraries so they could be easily be loaded into node.js That would make all sort of integrations between legacy systems with existing C# support libraries and newer lighter node.js projects work without jumping through crazy marshaling hoops. Seems like a very interesting direction, embedding managed languages into JS.

jbigelow76 8y ago
Do you mean something like edge.js? https://github.com/tjanczuk/edge https://github.com/tjanczuk/edge