|
I did indeed! My apologies. 
|
|
|
|
|
You have a good point. Here's another idea:
One of us needs to grab a time machine and go back in time to the mid 1990's. Invent a technology called "Java Applets" that runs state-of-the-art object-oriented code in the browser. Once everyone realizes how awesome it is, crude hackish Javascript frameworks will never have the chance to rise and turn web development into a mess.
|
|
|
|
|
I've done that...The problem that it can't stand the journey back to our time...Wrecked on it's way...
But I have a better idea...Port the .NET source from GitHub to JavaScript!!!
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
If I do this, will I also be required to go hunt down Sarah Connor?
|
|
|
|
|
Umm, there is such a technology, created by Microsoft, actually created by Anders Hejlsberg, the creator of C#. It is called TypeScript[^].
Google ditched their Dart language in favor of Typescript when setting the default for Angular 2. Speaks volumes about the quality of Typescript.
Edit: BTW the article you are referencing is typical for the React crowd, which indeed needs to put together a bunch of libraries in order to start developing. Angular 2 is a monolithic framework pretty much everything included, so it doesn't have those problems.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
But TypeScript isn't C#... Does it even use .NET?
|
|
|
|
|
It is as close as it can get. It is included as a first class language in Visual Studio. It doesn't use the .NET Framework libraries of course since it compiles to JavaScript. Nobody will redesign their browsers to ditch HTML5 Javascript and CSS and switch to WPF. Not even Microsoft.
You can even now create WPF apps for browser, however let me tell you a secret. There is a reason why not everybody switched to WPF by now. It is not that good.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
