|
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...
|
|
|
|
|
I think that the Webassembly (You can than develop in C#, Java, whatever has a web assembly compiler) is in the long run the only architechture / endevour that could put an end to that (yes I too consider it to be a) misery. It still has some not yet solved problems (like Garbage Collection, multithreading and more) and the task is daunting. But it is very well under way. If this really is to be more than a good platform for game developers remains to be seen. But as far as I understand the potential is there. Like an ecology of libraries for DOM Manipulation. And Tooling in the Style of WPF/Universal Windows XAML/Java FX: so one easyly develop "Desktop" style apps, that in the end write to the HTML Canvas or so.
The implications are vast. And I would really like to see that that pulls of. It is the only concept I know of, that would dispense with the manifold of fundamental problems of the current situation with developing clients for a browser.(Which I have done extensively in the last years).
|
|
|
|
|
|
Do you realize what you are asking? Billions of dollars will be needed to rebuild mountains of existing software across multitude of companies just to make developers happy? I guess if Vulcan suddenly come down to visit Earth and money goes the way of the dinosaur, may be.
|
|
|
|
|
I second this. C# is a pleasure to work with. C# 7 is coming our way too. What prevents people from making websites that is pure C#?
Why are we stuck with HTML and CSS hell? Why are we stuck with Angular, jQuery, Node.js, React, and thousands of libraries? They gave me headaches...
Someone said that it's impossible to do this since people wouldn't want to rewrite billions of websites. Now. Now. Who said that they have to rewrite? Browsers can simply accept a brand new extension for websites. Even now, they accept several extension: html, php, aspx.
modified 10-Oct-16 23:17pm.
|
|
|
|
|
Yesterday, @glennPattonWork is talking about fixing a printer: http://www.codeproject.com/Messages/5309442/Cue-Evil-Laugh.aspx[^]
I just had to say
Quote: The problem I have with my inkjet is that I use it so infrequently that every time I try the cartridges have dried out...
So an hour ago, Herself asks me to knock up a form for her: 5 minutes and LibreOffice Calc later and it's ready to go...only the ink cartridges have dried out... 
And it took me an hour to get the stupid print heads printing all lines again. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I found it easier to soak the heads in 99% rubbing alcohol for a few minutes first then wipe them off. May need a couple of applications of this but takes about 10 minutes.
But, since I'm lazy, I'll probably replace the inkjet with a color laser next time. 
|
|
|
|
|
Lots of really cheap color laser printers are out there now, but their toners cost as much or even twice the cost of the printer - and I am not kidding.
|
|
|
|
|
Yeah, they figured out a long time ago that you only buy the printer once and the ink/toner lots. Guess where all the profit is coming from?
But, toner doesn't evoprate on contact with air, so...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
