6 ms·

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

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.

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.