|
How can you create Wpf apps for a browser?
Disagree strongly about Wpf not being good - at least on the desktop (non browser) side it is the pinnacle. IMHO of course.
|
|
|
|
|
|
Ohh ok. I thought you were referring to some recent development.
Anyway .net/c# and Wpf are not one and the same.
|
|
|
|
|
Way to sluggish for the desktop and too limited in its environment. WinForms is mature, WPF might never reach that point.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Not sluggish compared to Java client apps; if you use Visual Studio (since 2010) then you're using WPF.
|
|
|
|
|
No, we're not 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
WPF is excellent - if difficult to learn. Also MVVM muddied the waters
|
|
|
|
|
I'm with you. I read the same article and thought "This is exactly why I haven't gotten into web development".
The plethora of things to learn makes it practically impossible to really truly learn web development. How can you really learn a technology when it's constantly changing.
It's frustrating at best, impossible at worst.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Peter Moore - Chicago wrote: someone has to be first. Please, for the sake of our sanity - bring C# and .NET to the browser
The holy grail of web development, I thought we had gotten there with Silverlight.
I posted that article to our development manager in the hope that it may shake some sense into her.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Dropping Silverlight was a huge mistake. The adoption was crazy being it wasn't cross platform.
Microsoft should reverse course here.
|
|
|
|
|
Javascript isn't the main problem (I can't believe I just said that.) It's the HTML, CSS, browser incompatibility, and all the cruft you have to add to get SPA's, REST calls, automatic client-side updating (aka SignalR), responsive web (aka auto-save), client-side models, events, etc., all working. OK, .NET could solve some of those problems, but not all.
Marc
|
|
|
|
|
They could call it something snappy like "ActiveX".
|
|
|
|
|
Good luck trying to get Apple to accept running .NET in Safari. They seem to actively block progress today, in the much the way MS used to with IE 6.
Personally, I think Web Assembly is our best hope here - .NET can compile to Web Assembly, as can any other language.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Hm. Despite what I said above, I wonder would Apple's involvement be necessary? or Google's or even Microsoft's for that matter?
I confess I don't know much of anything about how to build modern browser extensions, but I wonder if it's possible to make browser extensions for all platforms that would be capable of intercepting all the script blocks and hooking into all of the rendered elements on the page. I'm guessing not, but if it were possible, it would be an intriguing project to attempt.
Anyway, Mozilla's open source. Take Mozilla + Roslyn + Mono and we'd have a beautiful proof of concept to inspire the others.
|
|
|
|
|
Because ActiveX objects were such a good idea the first time around....
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Did you not read my actual post? I specifically said I did NOT want some kind of compiled extension that is downloaded and runs on the client. I want C# as a scripting language, powered by Roslyn and .net.
|
|
|
|
|
Yeah, and ActiveX object hooks were a thing in IE that did not require browser extensions, as they were baked in.
You're suggesting that .NET be baked in. It's the same thing.
Yes, I read your post. I honestly hoped you were joking: from the level of indignation I'm guessing not.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
It's totally not the same thing.
ActiveX controls were compiled, native code modules. If a page used one, you'd be prompted to download the ActiveX control if you didn't have it already, at which point it WOULD basically be a browser extension. (The extension - OCX - originally meant OLE Control Extension, but I believe it was just a DLL). The main reason they were a disaster was because they were unmanaged, insecure, natively compiled extensions; you needed 16-vs-32-vs-64 bit versions; and they were platform dependent.
You're right, I'm suggesting that .NET be baked in. .NET is a robust, secure, proven framework for both application and server programming. It is now platform independent and more or less open source. Yes, it would be "baked in" - precisely the same way JavaScript interpreters are "baked in."
But the C# scripts for each page would be dynamically compiled to IL on the fly by Roslyn with each page load, and the CLR would execute it. The server could send pages with dynamically generated C# script just as it does now with JavaScript. It would be secure, managed, and wonderfully easy to program.
As someone else said, the holy grail. Not even close to ActiveX.
|
|
|
|
|
Peter Moore - Chicago wrote: The main reason they were a disaster was because they were unmanaged, insecure, natively compiled extensions; you needed 16-vs-32-vs-64 bit versions; and they were platform dependent.
I wholeheartedly disagree. The primary reason they were a disaster is because they gave native system hooks to mobile code; easy as that. They allowed the bad guys to break the sandbox with little-to-no effort. It had very little to do with the actual downloaded code.
I have a better suggestion. Pull down NPM and start writing server-side JS. If you want an end-to-end code solution that's already existing one that doesn't arbitrarily attempt to hand all browser specifications to a for-profit company.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Maybe using asm.js, NaCl, or some other intermediary, to get to native code.
|
|
|
|
|
You do realize that changing the language running in the browser won't change the (over?) proliferation of libraries. We would just end up with three.net, react.net, redux.net and angular.net.
|
|
|
|
|
Good point! But, at least, the .NET framework has a lot more built in functionality so that we would not have to be so dependent on external libraries to do anything interesting.
|
|
|
|
|
What you're really saying is, "Please bring about a way to stop trial-and-error style developing", which is the "hell" most C# programmers have to contend with, when it comes to having to learn and use JavaScript. The short answer of course is "good luck"!
That's why we are paid a tonne of money (ok maybe a little more than average wages) compared to most professions, is because no one, and I mean NO ONE other than a dedicated web or systems development programmer can do what we do. I dare you to ask someone in the street if they've ever heard of C-SHARP, and they'll say yes of course - it's a musical note!
|
|
|
|
|
What chaos? What are you talking about?
>> just imagine how much life would improve for everyone if we could use the same language for both client and server side coding
Answer is:none, zero!
|
|
|
|
|
Funny; I've wanted python as an alternative to JavaScript for a long time...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
