Comment by eksemplar | Hacker News Reader

Comment by eksemplar | Hacker News Reader

Parent Full thread

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.

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/

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.

Thanks!

.net core really should adopt it, that would make it really competitive to node on the backend in terms of prototyping.

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.

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/

You mean like dropping the documentation and schema validation tools that REST still wasn't able to match beyond what Swagger kind of offers?

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?

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.

I'm not going to rehash the numerous argument against GraphQL. My point is Plenty of people who have experience with REST, SOAP, various old school RPC protocols, and GraphQL (myself included) prefer REST.

The superiority of GraphQL is not as self-evident as you believe it is.

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.

.net was doing graphql back when it was called odata.

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.

Tree-shaking is already there:

https://github.com/aspnet/Blazor/issues/1076

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.

Reply on news.ycombinator.com