Why not use .NET instead of javascript with HTML5? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel t开发者_如何转开发hat this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

Why are we still using javascript 'only' in web-browsers theses days? It doesn't support custom operators(I use for vector math), structs(value types) & a huge number of other basic Object Oriented principles that greatly improve the programmers coding ability in power & speed?

Why don't we use the openSource .NET CLR Mono instead or something equivalent? Why people insist on just putting hack in's to existing old languages is beyond me.. I mean we have a chance here with HTLM5 to start clean.

Also why are we not passing the client computer a pre-compiled library instead of embedded javascript code? This would greatly increase performance, not to mention the the code-behind is crapping up the HTML markup & in my mind is all totally just wrong...

I would love to make some web-apps for say ChromeOS, but i'm not going to touch the crap if javascript doesn't even have operators.

Sorry for the frustrated tones i'm giving, but I see something with great potential here in ChromeOS's model but if they want to compete with MS then they need to focus on better Dev tools for the people that make there stuff tick. Thats the one thing I rly like about MS, they have killer languages & tools for them.

NOTE: I'm not a web-developer(as you can probably guess why), so correct me if i'm wrong on anything or need clerity tnx.

Why are we still using javascript 'only' in web-browsers theses days? It doesn't support operators, structs(value types) & a huge number of other basic Object Oriented principles that greatly improve the programmers coding ability in power & speed?

"It doesn't support operators" - actually it does, like =, <, > and + and plenty of others...
Class-based OOP is not the only programming paradigm in the world, and it's not the answer to everything. JavaScript's prototypal OOP is much more flexible.
Power and speed? JavaScript is one of the fastest to work with languages. This is exactly because it does not limit the programmer to things like static typing.

Why don't we use the openSource .NET CLR Mono instead or something equivalent? Why people insist on just putting hack in's to existing old languages is beyond me.. I mean we have a chance here with HTLM5 to start clean.

Backwards compatibility: You can't just say "screw you" to everyone using old browsers.
HTML5 is built on top of existing standards. It's not a clean start at all.
Mono and .NET do not work on a wide range of devices which can run JavaScript, such as various mobile devices.

Also why are we not passing the client computer a pre-compiled library instead of embedded javascript code? This would greatly increase performance, not to mention the the code-behind is crapping up the HTML markup & in my mind is all totally just wrong...

HTML is text, CSS is text, I think it's natural for JS to be text too. It also helps when developing because you don't have to constantly keep compiling your code.
JS being text also helped to teach new programmers. You could simply take a look at the source code of your favorite website to find out what they were doing and how.

if they want to compete with MS then they need to focus on better Dev tools for the people that make there stuff tick. Thats the one thing I rly like about MS, they have killer languages & tools for them.

There's a wide range of tools available for JavaScript development. One of the most Visual Studio like tools is probaby JetBrains' WebStorm IDE
There are also unit testing and other testing tools, continuous integration tools, static analysis tools...

My suggestion to you would be to actually take a while to learn more about JavaScript before casting judgement upon it like this.

I'm not sure I understand what you're asking:

Why don't we use the openSource .NET CLR Mono instead or something equivalent? Why people insist on just putting hack in's to existing old languages is beyond me.. I mean we have a chance here with HTLM5 to start clean."

How does HTML5 give us the chance to use Mono as a replacement for Javascript?

Also why are we not passing the client computer a pre-compiled library instead of embedded javascript code? This would greatly increase performance, not to mention the the code-behind is crapping up the HTML markup & in my mind is all totally just wrong...

You're coming from the assumption that the only way to use JavaScript is to embed it inline with the HTML markup. This is horid. I prefer non-instrusive JavaScript linked in external files. These files are responsible for attaching events to elements etc, not the other way around.

The old school way is to do:

<input type="button" onclick="alert('Hello World!')">Click me</input>

Agree that with this example, JavaScript is getting in the way of clean markup. But why not just do this:

<input type="button" id="hello-button">Click me</input>

And in JavaScript file that has been included:

$('#hello-button').click(function() { alert('Hello World!'); } );

Separation of concerns can be achieved easily with JavaScript.

In terms of OO principles, we use them extensively in our application. JavaScript logic is carefully contained, separated by namespaces, and have a complete object model with functions, operators etc.

but i'm not going to touch the crap if javascript doesn't even have operators.

http://www.w3schools.com/js/js_operators.asp - or do you mean something different by operators?

Because its possible only in the perfect world. In the real world we have dozen of legacy apps, written on JS and thousands of web-developers, that doesn't know .Net or Java or any other similar technology. BTW, sometimes JS is not so bad as it looks.

For a while, there were a lot of "server side only" type web development going on, because there were so many differences between browsers when it came to JavaScript processing and item rendering, that it was better from a maintenance perspective to leverage these server side languages. They did all the heavy lifting and ensured you had a pretty consistent view across these browsers.

The downside to the server side only apps is the constant post back to the server, which caused an ugly "flicker" effect with applications. If you had a bad connection, or a lot of server processing, it became annoying to wait 2 minutes for a page to update itself when all you did was check a box saying you didn't want to enter a calendar date, which forced the application to hide its calendar widget and maybe do some other processing.

In addition, the view state generated by .Net applications really started to eat away a the user's experience, as more and more controls were being pushed into a single page, and controlled via AJAX or other events to display and hide them. Web pages became rather bloated by a process that was supposed to help eliminate some of that.

jQuery and CSS have been some major advances that has pushed things back to the client side model. With a uniform way of displaying data, as well as leveraging the clients machine to do a lot of the heavy lifting of showing/hiding controls, it made more sense to have apps written this way. Generally speaking they are faster than their server side counterparts, and can do most of what the server side based apps do. In addition, the view state bloat goes away. You also have the ASP.NET MVC framework, which tries to balance both worlds of giving you the server side power, but reducing a lot of the client end bloat from the view state.

In short, you'll find a lot more apps going the JavaScript route these days because you can get similar functionality, thanks to jQuery and CSS, and a lot less overhead and repeat trips back to the server.

JavaScript is generally considered a more advanced OO language than .NET by people such as Douglas Crawford.

You do have the option of running .NET code in a web browser: it's called Silverlight / Moonlight.

Regarding the idea of only sending precompiled code, one major issue is security.