5 ms·

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

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.

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.