Hacker News Reader

Comment by quickthrower2 | Hacker News Reader

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.

View on HN

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...

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.

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.

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.

Razor templates are quite good as far as server side templating goes imo

To me razor seems great, but I can only compare it with quite horrible HUGO templating.

I have been jumping between native and web development, alongside backend since the late 90's.

I will take any server side rendering framework, with some sprinkle of JavaScript, over any SPA framework.

A node_modules directory with several thousand packages just for a basic CRUD app, really?

Clojurescript is quite nice in avoiding the whole webpack/npm/grunt/gulp/... build and dependency tooling evolution nonsense. There are a few other compile-to-javascript environments that are as good by now I suspect if you don't like parens as much.

However, I agree that server-side rendering is much simpler in all of the cases where desktop app-like experience isn't required.

which yields better outcomes: organic growth (open source) or central planning (microsoft)?

Central planning for sure, given the lack of UI/UX focus we usually see on open source stacks.

Coding is fun, but providing a productive experience also requires doing lots of stuff that FOSS coders don't invest any resources into it.

I have a very similar background and hate the idea of having a bunch of dependencies too - but I found my Vue pwa 'just works' even with 1007 folders in my node_modules directory. We'll see if it stands the test of time.

It's a lack of any well designed standard library for JS, combined with weak namespacing and modules, as well as the rougher compilation step.

You are comparing 90s technologies to today's web standards. It's like saying that "open source isn't good for websites because look at php".

Microsoft front ends haven’t really changed since the 00s.

Blazor, to me, feels like WebForms/UpdatePanel.

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.

Microsoft eventually created MVC, which embraced the nature of the web (HTTP verbs, no viewstate, etc). I would urge developers to just dump into the deep end and use tech native to the browser. I know wasm is now native, but Blazor is running a VM in it that wasn't designed for it.

C# developers might find some comfort in TypeScript. Maybe Angular?

Wait, what's wrong with razor?

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

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.

> All using a decent language C#

F# is also supported, and potentially any .NET language.

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.

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.

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.

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.

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

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.

Competing UI frameworks exist. Blazor is just one. See Ooui & Uno for others.

Reply on news.ycombinator.com