Maybe a strange and green question, but
Is there anything C# can't do what javascript can...
And considering JQuery?
except for the fact that one is clientside, and the other serverside?
Or am I asking a very stupid question now?
EDIT:
to be more specific: I mean web programming, and indeed maybe a more useful question is:
> What can I do client side that I can't do server side, and vice versa?
> Are there more reasons to use both languages if you keep "server/clientside" out of scope?
> some developers avoid javascript. why?
What can I do client side that I can't
do server side, and vice versa?
Client-side: Javascript runs in most browsers without a plugin. C# requires a browser plugin like Silverlight. Even though it's running on a client machine, Javascript can't read and write files there. C# in Silverlight may be able to read and write files depending on the Silverlight version and what the client allows. Both Javascript and C#/Silverlight can talk to remote servers.
Server-side: since you control this machine, you can do whatever you want - read files, write files, talk directly to databases, etc. Keep in mind there's nothing stopping you from running Javascript server-side. Check out node.js.
Are there more reasons to use both
languages if you keep
"server/clientside" out of scope?
I wouldn't leave the execution environment out of your analysis. If you absolutely need client-side interaction and can't guarantee C# will execute on the client, C# isn't practical. Likewise, if your company runs Windows servers and doesn't want to install Javascript runtimes/compilers, you won't be able to use Javascript on the server.
some developers avoid javascript. why?
Problems with Javascript in a browser are absolutely awful to debug. You're running on a machine that's out of your control - the user may be running an obscure or ancient browser, they may be using anti-virus software that mucks with your Javascript, their browser plugins might muck with your Javascript. It's hard.
This is the cost of doing business on someone else's machine, however. If it was easy, a beautiful client-side experience would mean less. Solving hard problems isn't for everyone but it sure is appreciated when it's done well.
I take it your real question is, if c# can do everything, why should you use javascript at all? The answer here is performance, both perceived and real. The trick here is that to use c# to do the DOM manipulation normally associated with javascript, a browser has to post back an extra http request to the server and tell the c# code what to do. Lets talk about those extra requests. Spread around a lot of users, they add up very quickly and play havoc on your server infrastructure. The "real" performance issue is that now a lot of work has to happen on your server(s), instead of in your users' browsers. The "perceived" performance issues is that, even if you have the server resources to easily handle all the additional http requests, you user now has to spend extra time waiting for latency incurred by those http round trips.
Both languages rely heavily on API's that were designed for different domains.
JavaScript was originally intended to run inside of a browser, so it makes heavy use of DOM API's as well as other in-browser operations such as AJAX. C# probably does not have good support for such API's as it was never intended to be executed directly inside a browser - although Silverlight may provide such operations since it is (in a way) a "C# Sandbox" inside of a browser.
On the other hand, C# is a general-purpose language that was designed to build basically any application, from server-side engines to client applications to services - you get the idea...
I have seen a C# project where javascript is embedded and can execute javascript within a C# code. Have a look here on CodeProject to see how that is achieved.
Technically, no.
You could even use Javascript server-side if you wanted (or client-side C# via different mechanisms).
They're really just two ways of getting the same job done.
Related
We have a lot of red tape to handle before any changes to anything can be made on our servers. Hence I'm looking for ideas and/or suggestions for the below situation.
Must generate html from db (MSSql Server) for a static website hosted on IIS 6/7.
No (external) changes should be necessary on the server side except the ones the application/website makes itself.
I tried markdown and it generates everything nicely but I could not find a way to make the above idea applicable with it. I am willing to put all html code in the db for each individual page but it sounds awkward. Should I go with something ASP.NET'ish or a Windows Service or a standalone app to run at a schedule.
Thanks for the suggestions.
ASP.NET Dynamic Data might be your technology of choice.
http://msdn.microsoft.com/en-us/library/vstudio/ee845452%28v=vs.100%29.aspx
However, my advice is that you'll never be able to solve your problems by something like the above. You need to work out how to do releases more often - maybe start with a CI server and start scripting your releases if you haven't already.
I am working on a pet project and need to overcome a major hurdle in an application. I have checked countless forums and articles and have only found bits and pieces of what I am looking for, so I hope a more direct approach will help me.
Here's the scenario:
1. The site is actually a game, which uses Javascript/JSON with DHTML on a page that has several IFRAMES - two of which are deeper inside the outside page AND of a separate domain.
There are NO security issues with what I am trying to do. All programming and access is limited to merely simplifying and automating normally access functions only. All authentication and private information is done prior to any access, and only the session information will ever be used, and only to facilitate game operations that the user knows will happen.
The idea is to use the webbrowser control to access the game and provide ordinary access, while the app hosting the browser gets the game session information and makes separate automated calls to the game servers. This has already been done via Firefox using Greasemonkey scripting, and it works well - except that Firefox has a horrible memory leak that eventually causes the whole operation to break down.
The problem I am running into is obvious. I am trying to access the iframe that is technically on a different domain, and the web browser DOM model won't let me in. I have seen enough articles to know there are several workarounds to XSS filter blocks but they are quite vague and vary depending on scenario.
So, I will outline exactly what I need in hopes that I can obtain an amicable solution...
I need to obtain the DOM of a nested IFRAME of a different domain. If need be I could live with just the source, but the DOM and the JS vars would be the most ideal. My strategy here is to use the session information and make HttpWebRequest calls parallel to the web browser in-game. That way I can automate some functions while still playing. It can be done - if I can get the session information and pass it the same way. It will all be done on the same client with the users permission and knowledge, so no security issues.
I would really like it if I could pass information BACK to that IFRAME. One of the major things this project is trying to do is make some visual changes to simplify the look and feel of the interface. It is all in HTML, so changes would simply be adding some in-line styling of JS code...
So anyways, what ideas and suggestions would work best? At this point I am open to all scenarios, but ideally something as simple as possible to get what I need. This is already a huge project :).
Thanks in advance!
If you are in control of all sites in question, you could use postMessage to communicate. Also there is easyXDM which provides a set of transports that also work in older browsers (and automatically picks the best one).
https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage
It's possible to bypass XSS checks and access iframes through IOleContainer, as described here. The sample is in C++, but it should not be a problem to do the same from C# with COM interop.
I would like to write a C# app to handle my HTTP (including AJAX requests) rather than go the PHP, PERL or ASP route as I just need to return some standard HTML, albeit obviously, as I want CGI, dynamically generated.
UPDATE: I am not proposing to write my own web server but have the exe hosted by a webserver such as IIS or Apache. Also I dont want to learn and use ASP (I know I can do it much faster, development time, myself in C#) and I just want W3C valid html sent back to the client.
Are there any good reasons for not doing this?
I realise each time a HTTP request is made the exe has to be loaded and run - but surely so does Perl, ASP and PHP? Is there a way to have an exe remain running dealing with all HTTP requests for specific page? (though it feels like I am just writing a mini HTTP server then!)
Are there any good tutorials? I have read this one, but it is bit dated (2005): http://www.codeproject.com/KB/cs/cgi_csharp.aspx
UPDATE2: I dont think speed is going to be a issue anyway (running a small exe without a GUI is almost instantaneous) but if I wanted to be really efficant I could write C# server then the non-static page requests can have a tiny exe written in C which sends the request to the C# server and returns the reply. Couldn't I? :)
There are solutions such as FastCGI, that eliminate the overhead of launching an executable every time you want to process a request. Very few people still use traditional CGI. I don't know if there is a solution compatible with .net.
There is a much better option for .NET, the System.Web.IHttpHandler class.
All you have to do is subclass IHttpHandler, and overload 1 method to process a request. In my opinion it is simpler CGI.
There is a good example on the MSDN Site.
I'd suggest leveraging the HttpListener API for this kind of thing if IIS really doesn't cut it for you.
I have to write an application that is essentially a proxy server to handle all HTTP and HTTPS requests from our server (web browsing, etc). I know very little C++ and am very comfortable writing the application features in C#.
I have experimented with the proxy from Mentalis (C# socket proxy) which seems to work fine for small webpages but if I go to large sites like tigerdirect.ca and browse through a couple of layers it is very slow and sometimes requests don't complete and I see broken images and javascript errors. This happens with all of our vendor sites and other content heavy sites.
Mentalis uses HTTP 1.0 which I know is not as efficient but should a proxy be that slow? What is an acceptable amount of performance loss from using a proxy? Would HTTP 1.1 make a noticeable difference?
Would a C++ proxy be much faster than one in C#? Is the Mentalis code just not efficient?
Would I be able to use a premade C++ proxy and import the DLL to C# and still get good performance or would this project call for all C++?
Sorry if these are obvious questions but I have not done network programming before.
EDIT In response to Joshua's question: I don't necessarily need to write the core proxy server myself as long as there is a good implementation out there but like I said I have been experimenting with Mentalis which isn't performing that well. The final application needs to install on a Windows PC/Server from a single installer with 0 manual configuration.
I can write all the necessary registry edits in the installer as I have done that before in C#.
UPDATE I took Aaronaught's advice and looked into improving Mentalis' code. I fix a problem so it works with HTTP 1.1 allowing it to work with Chrome and Firefox (Safari 4 on Windows crashes the proxy though for some reason).
When I tested in FireFox and Chrome I discovered the performance problems were not there which implied it was an IE problem not a problem with the proxy. After resetting the browsing history settings the problem went away.
Thanks everyone!
How you actually design and code the application is going to make infinitely more of a difference than the platform you choose.
If you design the server efficiently, it will be efficient. If you design it inefficiently, it will be inefficient. There's no clear advantage to choosing C++ over C# or vice versa... unless you'd have to learn the entire language from scratch, which is a huge negative (hard to come up with a good design when you barely know the tools).
Things you'll probably have to understand for this type of application:
I/O completion ports
Thread pools and multi-threading in general
Networking protocols (including HTTP, FTP, TCP, etc.) - especially for error handling
Certificates and signing/encryption (for SSL/HTTPS)
...
Honestly, you're talking about a non-trivial undertaking here. I don't mean to sound overly negative but what makes you think you can do a better job without an extensive knowledge of the underlying networking protocols and proxy design? Why not take a look at the Mentalis Proxy source code instead and see if you can improve it, rather than trying to write your own from scratch? Surely the former would be easier than the latter.
Anyway, a socket is a socket; .NET sockets are not much more than paper-thin wrappers over Windows sockets, so performance is not going to be noticeably different in C++.
C++ is not an easy language to learn. Combine that with lack of networking experience and you are in a totally new territory. If you want to explore - fine, you'll make all the mistakes and learn a lot. If, on the other hand, you need to deliver something by some date - go with whatever you are comfortable with at the moment.
If you want to write a really fast, clean, down-to-the metal server, go with C++ or plain C.
C++ is not an easy language, and is easy to mis-use. C++ requires the discipline to actually read and contemplate difficult books. Used right, it is the best systems programming language available.
If performance is not an issue, you may use fluffier tools such as C#.
Is there any way to have apache "pass" the request it takes to a c# "application" to handle, allowing it to return specific content. I want to handle an intense amount of asynchronous calls to apache via javascript and have these calls routed through c# (much the way asp.net does). Has anyone successfully done this before? Any idea where to start looking?
Update:
Some more information. I want to be able to handle thousands of concurrent asynchronous requests as fast as can possibly occur writing the interpreting agent in some kind of threaded c# application. I could be wrong, but I dont think that iis with asp.net is tailored for this sort of thing (a proof of concept would be great).
I feel that going with something like apache would be better suited. If that means going from something else to c# first is fine I guess, but I would like to be more direct.
Apache actually supports running C# libraries using mod mono. Also, you could use CURL to send a web request to C# running on IIS. Another way would be to open a server socket directly in C#, and have apache (via php, python, or some other scripting language) connect to you C# application to handle the request. I think you need to be more specific about what exactly you are trying to accomplish.
with apache2, you could run mod_aspdotnet
or if it suits you, run some urls in proxy mode (pass them to another asp.net server), using mod_proxy
or Kibbee's excellent solution