Performance is only part of it. Using a single language for the whole stack is very valuable to a lot of people. I think that's why Node gained popularity because many developers were using JS for the frontend so why not use the same language for the backend as well?

That's what appealed to me. Cross-platform desktop client? Electron/TypeScript. Front-end of a website? TypeScript. Back-end service? Node/TypeScript.

Yes, exactly. Xamarin is already a good cross-platform solution for "apps" and so Blazor is hopefully the missing piece for the web. The JS-based cross-platform mobile solutions are just not in the same league as Xamarin, IMO.

Can you show benchmarcks of an electron app vs xamarin for a same UX?

I don't have any, no. Benchmarks are going to be relative to what you want to compare though so you will likely have to take them yourself, especially if you are comparing something subjective like UX.

I know Paul Betts lurks around here sometimes (well maybe he used to, it looks like xpaulbettsx no longer exists), I would take his opinion on the two frameworks over anything I come up with.

JavaScript isn't a very good programming language. Just because I can develop in it doesn't mean I want to.

Sure. Blazor scratches a developer itch. But end users aren't likely to feel a difference one way or the other. The same bottlenecks are still the same bottlenecks.

It isn't just about scratching an itch. It results in fewer bugs, faster development, more features etc. which are useful to end users.

My experience of tools/languages that sit on top of the actual native implementations (e.g. React Native or Xamarin on mobile) is that they often lead to much slower development, since when you're Googling around trying to find answers to an issue you're looking in a much smaller community for answers. Eventually the answer usually ends up being "just do it the native way".

Hopefully Blazor will avoid such issues. In any case I'm probably speaking out of turn... it clearly isn't designed for wide-scale deployments - in house/intranet tools are a different beast anyway.

I use Xamarin Android and while you are right about the ton of googling needed, it was always to search for Android API and almost never because of Xamarin itself. Once found, it’s straightforward to convert from Java code to C# except a few cases (layout parameters for instance). The other issue is coming from a nicely design framework (WPF, Silverlight or WP7/8) the Android APIs feel ugly at times (gesture handlers for example).

Assuming you are doing Xamarin.Native and not Xamarin.Forms, you can just tab-complete your way through it if you know the native side. The apis are almost 1-to-1, only making things more dotnet-y when it makes sense.

That's such nonsensical marketing spin.

I don't see how easier development does not result in better outcomes. Imagine how bad things would be if everyone had to code in Assembly.

But the "easier development" part is very debatable. What do I see in the browser developer console when debugging a Blazor app? Can I insert breakpoints, trace what is running and how? etc. etc.

I get disliking JavaScript, but there is a strong argument to be made for using the tried and tested technologies that developers have been using for a very long time, rather than shoehorning whole new tech in just because it's in a language you prefer.

The answer to your break point question is yes. You can debug your C# code on the front end with breakpoints. The biggest benefit is applications with a lot of domain business logic tend to have that logic copied to the front end and copied to the backend. If a object can no longer be updated if it has an expired date then you would have logic on your server to prevent that. You would also have logic on your front end to display to the user that this can not happen before even going to the server. The server would act as a backup and ensure it never happens.

With Blazor, this logic only exists in one place which helps follow DRY.Logic that is duplicated tends to get missed in testing often. This provides business value.

The process of developing better tools for more effective software design is not just about making developers feel better.

It's about prodding development teams towards the pit of success, to use a common cliche, instead of the pit of despair. Less mental overhead, less need for expertise in specific flavor-of-the-month frameworks, less churn, easier hiring (you just need to know C#), more reliance on compiler tools to prevent dumb mistakes.

Stuff like that easily make the difference between success and total failure. The business stakes are actually quite high.

The solution is a new CRUD-friendly markup language & standard. Why does JavaScript have to reinvent common and expected GUI idioms that have been around since the late 1980's? That to me seems irrational. Slap the industry and wake them up! We are downloading an entire (buggy & leaky) GUI engine for every app. That kicks D.R.Y. in every organ.

HTML was originally intended for static documents. We have been shoe-horning it to act like a real GUI and faking state, and it's been grunting and groaning under the strain for 2+ decades. Give up already. Make CRUD Normal Again! #MCNA!

The problem with JavaScript is it's a separate programming language.

If you could use C# on both the front and back end, that would be a game-changer for enterprise shops, and very useful for everyone else too.

It used to be this way back with thick clients(Winforms) and then for a short time Silverlight.

It was a very productive time, not sure if I have have ever been as productive as I was with C# and Winforms. Run code on the client, run it on the server, whatever.

I use Elm and by having a language that puts constraints on what ultimately is executed in JavaScript and manipulations to the DOM, you can manage to write complex programs and have them be relatively efficient in size and operation.

Of course Elm isn't without its problems, too, but I think it may be on the right path for web applications.

it's not about the performance or replacing javascript. It's about being able to program the DOM in the same language you use on the backend, whatever that might be.

Blazor is a game changer in my opinion. C# is a sold language and this project solidifies that.

> JavaScript isn't really that big of a problem or a performance killer. The DOM is.

I'm using QML, which is JS without DOM. JS is absolutely a performance killer. Migrating stuff from JS to C++ in a dumb way (no architectural change) makes things 20x - 200x faster.

I don't doubt C++ is faster than JS, but JS in modern browsers is more than "fast enough" no matter how much faster C++ may be. If you're doing the kind of things most web pages do (render some UI, information and inputs, adjust UI, take responses from those inputs, validate and send) then JS is very, very rarely a bottleneck in performance.

What JS engine does QML use? Because if it's a relatively modern one (V8, JavaScriptCore etc) and you're experiencing huge slowdowns just creating and modifying UI components then I'd seriously question the JS code you're running.

I’ve got to be honest I thought this was the right take but I doubt it now. At least with React. Ive been doing performance on a large app now for months and JS is very often the problem. If you’re re-rendering anything that’s more than a few components wide and a few deep, say 20-40 in total, you’re already over your frame (16ms) budget. To me that’s insane. You can’t render more than 20 components at a time? And this is using a really fast computer. I almost can’t believe it. But often just the logic for a single component that’s a few levels deep takes 4ms. I really do feel that should be about 10x faster but for some reason it isn’t.

You probably need to learn how do either design a better app, or write better react if you’ve got that much of the DOM updating at once.

A computer shouldn't struggle updating 30 smaller components. It's not DOM I'm talking about it's React, so not sure you even understood me.

I've written more React than most people, and am very intimately familiar with the internals, optimization and more.

With enough effort you can usually mitigate most of it, but I'm going as far as doing static compilation optimizations just to get it to feel good.

Just curious are you referring to this?

https://doc.qt.io/qt-5/qtwebchannel-index.html#

Is it possible to get any benchmarks or comparisons.

No, just using plain QML. Basically, it's a C++ application with application logic written in JS (using a rather bad JIT), and where we went wrong was writing a lot of application logic in JS rather than just writing the UI specific application logic in JS and the remaining part of the application logic in C++. OTOH, we already had huge parts of the system in C++ and the JS access was mainly small data transformations, but even this turned out to be too slow.