Why are we messing around with html when we have .net?

[Bartolomeus-649]

How do you get winforms or a wpf application to run in the browser with Blazor?

Or Silverlight, that's a framework even smaller than .NET/Mono, why not use that? Just about anything is better then doing GUIs in HTML.

[chrissainty]

Blazor is supporting web standards. If you are more interested in XAML then the Ooui project might be more to your liking.

_{Sent with GitHawk}

[SteveSandersonMS]

Thanks for answering, @chrissainty!

[taori]

@chrissainty This reply isn't really helpful. It was my first thought too, when i heared about blazor. Silverlight was scrapped because it required an external plugin - it's the result which matters. If i want a SPA, silverlight would be amazing if it were built on top of webassembly. I would not even spend a second thinking about using blazor then. If i want to write HTML i'd just go with mvc, instead of learning another hybrid with new syntax.

[chrissainty]

@taori I’m struggling to see why my response wasn’t helpful. I clearly restated what the Blazor team have said from day 1, that the framework will support web standards. I.e. HTML and CSS. I also provided a link to a project which is looking at things from a more desktop/Silverlight angle. I’m failing to see your issue.

[Bartolomeus-649]

@chrissainty, what the Blazor team have sad or not said is beside the point.

The point is that Microsoft is finally doing something that seems like the right thing to do. Lets face it, Microsoft has been completely lost, and still is, since before the started to mess around with a perfectly good Windows, which had a 95% market share, back in 2012. And before that when Microsoft betrayed its partners, developers and customers by deprecating Silverlight, the embryo that would have gotten back the productivity everyone was used to from VB.

Visual Basic used to be the most popular and most used development language and development framework out there. People were used to be able to create a working prototype for a customer in less than a week!

For some obscure reason there are people who really think HTML, CSS, JavaScript is a good development platform. Well, it isn't, it sucks! At the very best it's a GUI layer, and a poor one at that!

For those that have been around since before the web know that there were a lot of problems with VB and traditional "fat clients". Problems with DLLs, problem with versions, problems with deployment and so on. But most of those problems were addressed by .NET when it came about. Now you could do XCopy deployments of applications, you could redirect which DLLS an Application should use after it was installed, still deployment were problematic and click ones installation had/has issues.

So when the web came along and Microsoft introduced ASP with JScript and VBScript, and people realized that if you wrote something in ASP there were no deployment problems any longer, in fact there were no deployment at all! The whole issue vanished as you no longer needed to deploy anything to the clients. Everyone started to create ASP solution, everyone was happy. But unfortunately, soon people started to realize that the web was very limited in what you could do. It was impossible to print anything like what you used to be able to, it was difficult to get a web application working across the different browsers, and just about anything could break when a browser was updated, there were no easy way to integrate with other business systems or local applications like Office. And designing the graphical user interface was a huge problem, you had to do everything by hand manually, you had to do special fixes for each browser. Some browsers had their own API extensions. Soon Microsoft released a way to write components in Visual Basic that you could embed on a page in your website, just so you should be able to get more advanced functionality. And ofcourse this lead to new problems, security issues and more. And then you had to code your web application in JavaScript, a language where you basically can write just about anything and it will run. It will run, but not necessarily in the way you intended and not with the result you wanted. Developing a large Enterprise application in Javascript, where you have developers come and go, and where the application should live for 20 years will end up in chaos, worse than most nightmares.

So, with this situation, people started to create frameworks to ease building web applications. We saw everything from Microsoft's Web Forms, Microsoft Access saving forms as web forms to JavaScript libraries and CSS frameworks. And they all had one goal, to get the developer away from HTML, css and javascript.

Everything done for the web after this is just to try to encapsulate HTML, CSS and JavaScript in a way so that the developer can focus on the features of the customers Application, and not how to vertically center/position something on screen, or finding why it works in Browser A but not in Browser B.

And remember, still we are just talking about a GUI-layer. There is NOTHING in HTML, CSS and JavaScript that even come close to an application framework where you communicate back and forth with one or more servers, or need to localize the Application, or where data validation picks up properties from the DataBase and use the to constrain the length of a text in the GUI. There is nothing for transferring data between the server and the client, instead you should invent your own way of transfering data by serializing it on the server, and then deserialize it on the client...basically the same way you do when you use native sockets. No help whatsoever to make sure your date on the server will be the same date on the client.

Somewhere around this point Silverlight shows up! and it have most of the functionality you need. There is tight coupling between the client and the server, the objects/clases you have on the server, are basically the same ones you have on the client. No plumbing whatsoever to get things to work. Date is transferred seamlessly between server and client. And then we have the GUI, in Silverlight you do a proper GUI where you can focus on usability, functionality and productivity. And you use the same language when you develop the server side and the client side. No need to manually serialize anything, it just works. And even though its brief existence, it managed to provide a development platform that gave you the productivity you were used to from VB and .NET while still taking advantage of the web for distributing the Application. You stated a SilverLight application in the same way as any webpage. No deployment necessary.

So now when Microsoft is working on a new project, were .NET is converted to web assemblies, it is a HUGE disappointment and a kick in the balls to find out that Microsoft still will use HTML and CSS for the GUI. It's like showing an utter disrespect and pissing on your partners, developers and customers!

Getting the silverlight runtime to work as a WebAssembly should be a piece of cake for Microsoft, especially since it has already been done (and no, we can't use a solution someone manage to get working. We need a solution were Microsoft stands behind it, supports it and continue to develop it, with integration into Visual Studio, Azure and so on.)

Just look at all the issues with the Azure portal. It's made in HTML, CSS and JavaScript. The first version of the Azure Portal was in Silverlight, it worked, everything after that has been worse and worse. And that's natural when they need to spend time getting the dates to display in the correct format, they are not adding features.

Just look at the top two requests at the UserVoice site for Visual Studio

#1. 10.199 votes: Create a Ubiquitous .NET Client Application Development Model https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

#2. 6.009 votes: Open source Silverlight https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/5042512-open-source-silverlight

If you continue reading the list you will see many more with thousands of votes for similar things.

So, in what way to you yourself think your answer was helpful?

[chrissainty]

Well, I pointed out a framework that appears to be developing the thing you seem to be longing for so much.

Seems pretty helpful to me.

[humbersoft]

Anyone who has spent over 10 years in IT will recognize that, like many things in life, it is just one big cycle. Old ideas always come back as new. I 100% agree with @Bartolomeus-649 points and comments. Microsoft made a huge mistake by killing Silverlight. However, please remember that the industry was moving away from the plugin-based model that Silverlight and Flash was. People hated being forced to use IE or Windows OSes. People love choices. They want to run their apps on Windows/Linux/MacOS/Android/iOS or whatever else. It was either run with the crowd or be left behind.

HTML and CSS are web standards. Apps built to this standard will have much further reach and shelf life than any app built to run only on Microsoft browsers or OSes. Silverlight and Flash were horrible from security and mobile standpoint. We still do not know what to expect from Blazor with respect to mobile battery life and security. I hope Blazor pays attention to these concerns.

IT is a cycle so Silverlight may be resurrected to run on WebAssembly. @chrissainty gave some examples of some different approaches WPF-based and Silverlight-like. Blazor doesn't take away from those approaches. Blazor just wants to build the UI layer using HTML and CSS. I think it is a good choice.

[taori]

@chrissainty @SteveSandersonMS Your answer was not helpful because it simply dismisses the topic. Right now barely anyone knows of blazor on a general level? Do people who love programming and check the news know about it? Probably - It still is a minority.

The problem is the following. No project developer or external (non ms) product developer cares the slightest bit about how his code compiles as long as whatever he is developing behaves efficiently and can be influenced easily.

My development experience:

• native html + php: yuk. just yuk really. not missed it for a second ever since
• WinForms: Couple dozen small applications which were kinda spaghetti with the lack of knowledge about software design i had back in the day. Even now looking back it promotes dirty dependencies between views+domain and so on.
• WebForms: Several years. Oh hundreds of hours i wasted trying to find solutions on how to make something work, which is so simple if you know how the web works - yet webforms is shackeling you. Things only got better once you found ways around webforms to hack yourself around the constraints of webforms. The running gag being "rapid"-application-development libraries which gave you controls to use which got you going 80% of the way, only to then spend 10 times as long on the remaining 20% where a view was called from varying points of the application and update panels yadayada. Just to, at some point, throw it away and do it with a workaround which entirely avoids webforms. Silverlight: Couple small projects because i couldn't believe that WPF'ish development could actually be translated to web and free me from the torment of duck typing and lack of intellisense and refactoring. I was amazed by that one.
• WPF: Multiple bigger projects with thousands of lines of code. MVVM felt like a charm. Code was just more easier to grasp and seperate in a meaningful way. If i had the choice i would always write WPF applications.
• MVC: Couple dozen applications: If i develop an application these days which is destined to run on the web it'll be mvc. Angular or something alike? No just bare MVC+javascript and some typescript where possible. I will expand on why. Layoutwise HTML was probably the most annoying one out of all View Render methods to get the view you want. DockPanel + Grid on WPF is just so super versatile in comparison
• Xamarin Forms/ios/android: Forms was annoying - because most things worked rather well, while very common things (such as lists, drawers) were barely useable, poorly customizable and had awful performance. Things only turned out better after replacing anything in the forms application listwise with custom renderers.
• Xamarin iOS: An example of failed software design. Bad feedback on how to develop things (talking about random exceptions), Very restrictive in terms of how to do things, where to do things, what to call and so on for things to actually work the way you expect them to.
• Xamarin Android Android has a very simple but extremely verbose way of declaring layouts. Oddly enough what feels like essential layout capabilities sometimes only gets shipped with SDK later on instead to begin with. There was a learning curve but compared to iOS it wasn't steep at all. Getting custom lists working the way you wanted them to was a matter of a couple of hours, whereas it took several weeks on iOS thanks to that horrible gesture system, forcing you to write loads of customized code (unlike windows which simply bubbles events up and down... and is so easy to work with)
• Xamarin in general (I am glad it exists. I love using C#)

I am a person who absolutely loves learning new things, sometimes investing dozens of hours of my free time just to learn a couple things about how something works or how to do something better, because the process of doing something felt awkward or flaky.

So my instinct with blazor is the following: To me it feels like a retry with webforms pages with a new mask. The ability to develop a web application with web page related constraints just for the sake of staying close to html, because in the past webforms has been ill-reputed for being for being the wannabe web application spewing you with html, awfully verbose syntax and horrible performance.

Blazor certainly would allow for applications which feel less infuriating than anything that's bound to happen with webforms, but the core issue is the same. What you are working with is another hybrid application. Something which emulates a web application, mixing server code with client code and bluring the lines of knowing how to modify things according to your own need. With MVC that was always a non-issue because it was perfectly obvious how to sort things out if you knew how requests and dom manipulation works.

So what is the reason why i didn't bother with angular or something alike? My past experiences - The kind of abstraction i saw there (and from brief inspection with others) was in itself its own application development platform. So you had a web application, which in terms of maintainability was absolutely unmaintainable for anyone who does not invest hundreds of hours of research in this platform.

When learning MVC / WPF i did not require any help, because MVC does not deliver constraints - it provides you with the means to develop things in an easier way, while being close to the bare way things can be done without it. WPF, too was a concept which didn't really need an explanation either ( neither did silverlight obviously) You've got controls - Controls can be nested and themed. Neat. Bindings to viewmodels? Neat - easy to grasp. BindingConverters, Triggers, Style Inheritance, AttachedProperties, DependencyProperties? All made sense and helped me get stuff done without too much of a hassle.

So to cut things short we are now at a point in time, where Silverlight was scraped, because of the dependency on a plugin, which to be honest, does make perfect sense. Outside of my development machine i did not want such a deeply integrated piece of software (SL plugin) on my computer. The sour experiences i've had with flash, were enough to make me not install anything i don't absolutely need on my host.

Silverlight has been abandoned, which probably scared very very many customers, which probably is one potential reason why MS chose not to revive it with a binding around using WASM instead of that plugin. MS not being interested into providing a platform which perfectly caters to developing software which depends on running on their OS might be another (though then SL should never have been invented then, so that is unlikely)

So to sum this up. I will try out blazor, but if working with it feels like working with webforms again i will turn away and not look back at it ever again. Because i will not waste my time trying to learn a hybrid platform again, with it's own syntax modifications, making 30% of my work easier, while forcing me to do nasty workarounds for the remaining bits (that's what working with webforms felt like to me). I do have lots of experience with multiple UI Platforms and backends and i am truly hoping my instincts are just deceiving me about blazor might be going, Just wanted to share my insights regarding development platforms here and why SL does not the state it is in now.

If MS were to hold a survey on whether people enjoyed developing with SL i have no doubt that the majority said they liked it big time too. And why is that? It was a properly working, performant abstraction over a web application (unlike webforms)

I hope this does not come off too ranty - Just wanted to expand on why simply dismissing the "why didn't you instead revive SL with WASM" doesn't feel helpful at all.

[YAJeff]

I went ahead and started building a Xaml engine that runs natively in the browser. You can check it out here: https://github.com/XamlEngine/Samples

[Bartolomeus-649]

Rendering XAML in the browser might be cool, but it just HTML on steroids, brings very little to table when what we really need is an Application Development Framework. A framework that connects the front-end to the back-end in a structured highly productive typesafe way, as well as providing a way to write native .NET/C#/XAML in a fully supported way in Visual Studio that can run in a browser as well as a native application on most devices and platforms.

[YAJeff]

XamlEngine isn't HTML on steroids. It has it's own parsing engine, layout engine, rendering engine. It's built on top of WebGL and renders pixels in an HTML canvas.

The reason I started building this is because of exactly what you're saying. .NET already runs on all platforms. The one thing that doesn't exist on all platforms is natively rendered Xaml. XamlEngine is compiled from C++ (so it can run natively on any platform) and it targets OpenGL thanks to Emscripten (so it can theoretically run on any device). But the current priority is to getting it working for the browser.

Technologies like this, paired with all the cool stuff the .NET Core team is doing will (hopefully) someday create the ideal platform for development.

[Bartolomeus-649]

What I meant with HTML on steroids is that you replace one XML GUI definition (HTML) for another XML GUI definition (XAML). And as long as you are not satisfied with static pages, you need code to run together with the XAML, code that hopefully is written in C#.

Blazor is so close to what could be a first step to something wonderful....all Blazor need is to just fully support .NET and draw stuff just like you do on a canvas in HTML. If they did that, then all Silverlight applications, WinForms and WPF applications would just work in the browser with none or very little adjustment.

[YAJeff]

Well that's just how I'm currently parsing the source Xaml. The important part is that I have a function that can be invoked where I pass it Xaml and it renders that Xaml on the screen. Exporting that function call (and the DOM tree) from my WASM package would allow the ported DotNetAnywhere runtime to hook into those calls.

But this is still experimental. There are a lot of features that still need to exist. It still doesn't yet support mouse + keyboard input. And while I share your love for C#, I think this Xaml technology should be available to any language, including Javascript. Hence, why the simplest form of rendering Xaml in the browser is the example I've created. That way you could render Xaml from an app you authored in notepad if you wanted to. With that low barrier for entry, I don't have to create a bunch of build tools to get my engine up and working.

What I still need to build in though is the ability to compile the Xaml at build time. WPF does this or used to do this and I think they call it BAML. In that scenario, raw xaml would never be transmitted from the web host. This would be pretty easy to do. If it gets to the point where this is integrated with the ported DotNetAnywhere, then we can talk about an ideal package format.

[zwcloud]

Why not just write a WebGL-based or Canvas-based rendering backend and render XAML on top of that? ;)

[YAJeff]

Because if it remains compatible with OpenGL, C++ can be compiled for Android, iOS, Linux, Max, Windows, etc. One codebase, same Xaml engine everywhere. ;) ;)

[ghost]

People who have always worked on web using HTML/CSS can't appreciate the power and simplicity of XAML. Blazor does add a lot of value by enabling C#/.NET instead of JavaScript, but I agree with @taori that it might not survive because it goes back to old WebForms like approach instead of clean MVC/MVVM like approach. If Microsoft can unify the world with XAML for UI and C# for logic it can become single greatest platform for software development and we as developer can focus on developing great features rather than learning a new web technology, JS framework every few months. XAML is far more mature, stable and powerful then web stack (HTML/CSS/JS) and its already proven by these new frameworks every now and then which are just trying to copy features like bindings/commands etc. from frameworks like XAML/WPF.

[GoranHalvarsson]

I have to disagree with previous speaker. Please stick to html and css. This will be the new standard for mobile apps. Progressive web apps will grow and outcompete classic native apps. And if you want to build native apps (using blazor), it will be possible with electron.

[Arshia001]

@GoranHalvarsson that, and python's quick rise through the ranks, has me seriously worried about the future of software development. I don't know why the general public seems to only like horrible technologies. I mean, who takes a single-threaded, type-unsafe language with no compile-time checks (0 + [] + "" = "0") and creates servers with it? What, aside from the number of people using a technology justifies that? And when people use something, it's not because it's better (or we'd all be writing Haskell), but because it's more accessible or easier to learn at an elementary level. Blazor is a ray of hope, because it lets people break free of the hell that is javascript development. I have my fingers crossed for an alternative to HTML that's well-supported and optimized next.

[ghost]

@GoranHalvarsson HTML/CSS was developed years back to design newspaper like web pages and its still the same. It has not really evolved the way other technologies have. So no I don't agree, HTML/CSS is a thing of past not future.

[Telavian]

I personally love xaml and think WPF is amazing from a development perspective. WPF + MVVM makes developing applications almost easy.

With Blazor we no longer need to worry about the horrible mess of JS and can focus on logic and UI. This makes web development almost the same as desktop development.

HTML is certainly not as nice as XAML however they are honestly very close and I don't see why they can't be the same eventually. CSS is definitely a pain when it doesn't work however component vendors (Telerik!!!) massively simplify things like this.

I see Blazor as a huge step in the right direction and I think Blazor 2.0 will merge desktop and web development into a unified approach.