MySpace runs on IIS? Really?
myspace.com
myspace.com
But it is very, very unlikely.
.Net teaches programmers to write code to .Net, to Microsoft rules. It teaches its victims to use the excreable "viewstate" and POST when they mean to GET and pass volumes of unnecessary and poorly-encoded data back and forth between the server and client. .Net programmers learn to drag and drop things onto forms which Visual Studio then clogs up with layers of absolute-positioning tags, ensuring that the resulting pages will only display correctly on certain browsers with certain window-sizes and absolutely will not print properly, even when the planets are properly aligned. But that's okay, with .Net you can use Reporting Services to design hundreds of divergent "reports." .Net teaches programmers to code to Microsoft's api, not to web standards, fundamental principles of math and computer science or, frequently, to common sense.
It isn't to Microsoft's advantage for developers to consider other options and thus they try with great success to prevent .Net developers from realizing those options even exist. Microsoft documentation almost never refers to RFCs, even when doing so would be helpful. They hide the browser object model as much as they can and instead present the .Net wrapper for the browser object model as the only truth, with a Microsoft registered-trademark character after every thought.
It is possible to do good work on the .Net platform; it's just very, very unlikely.
Perhaps I've gone too far with this rant. As you may guess, it results from great frustration with well-funded idiocy in the wasteland of corporate American IT. Also I just tried to pay my property taxes online and the lovely .aspx page blew up with a CLIENT-SIDE VBSCRIPT error.
Good grief.
But here is a final and positive thought: quite a lot of business in the world is run on very poorly-designed systems, whether .Net or otherwise. Perhaps there much opportunity and advantage to be gained in creating better systems to replace them.
"It teaches its victims to use the excreable "viewstate" and POST when they mean to GET and pass volumes of unnecessary and poorly-encoded data back and forth between the server and client."
You are right here to the extent that "viewstate" is the default way of managing state, scalably, in ASP.NET. And this adds to the amount of data being streamed between the server and the client, and back. But, when performance is the "key" consideration, you can turn off viewstate for controls that dont rely on it, or for the page as a whole. If you are really hard-core about performance, you can write HTTP handlers that override parts or whole of the default handlers. Thus, you can maintain state on the server side completely if you wish to (dealing also with the concomitant issues to scale the site).
".Net programmers learn to drag and drop things onto forms which Visual Studio then clogs up with layers of absolute-positioning tags, ensuring that the resulting pages will only display correctly on certain browsers with certain window-sizes and absolutely will not print properly, even when the planets are properly aligned."
If you look into the "flow" layout mode, you will see that "absolute-positioning" is only one of the options that the Visual Studio Designer presents to you. There are no browser compatibility issues per se with the "flow" layout mode for printing or otherwise.
Also, Drag and Drop is a _Good Thing_. I have been dabbling with RoR lately and am yet to find good tooling around it. But, Visual Studio .NET is definitely one of the most powerful IDEs I have worked in. Drag and Drop = Increase in productivity.
"But that's okay, with .Net you can use Reporting Services to design hundreds of divergent 'reports.'"
From what you say in your comment, you seem to have quite a bit of experience with developing web applications for businesses. Given that, I am quite surprised you havent encountered similar attitudes that I have, as far as "Reports" go. Business Users _LOVE_ reports. "Reports" have been given a substantial amount of attention in most projects I have been associated with. So they are not "divergent" by any means. Drag Drop Capability for Designing of Reports, with Design Time handles for all the entities that compose it, is again very powerful for a host of business scenarios.
".Net teaches programmers to code to Microsoft's api, not to web standards, fundamental principles of math and computer science or, frequently, to common sense."
"It isn't to Microsoft's advantage for developers to consider other options and thus they try with great success to prevent .Net developers from realizing those options even exist. Microsoft documentation almost never refers to RFCs, even when doing so would be helpful. They hide the browser object model as much as they can and instead present the .Net wrapper for the browser object model as the only truth, with a Microsoft registered-trademark character after every thought."
Tnese are very strong statements. :) I actually think that the Server Side abstraction that ASP.NET provides to developers is amazing. Why? Because being exposed to the "browser object model" for a number of browsers and their varying capabilities is not really meaningful when what I want to do is develop relativly straight-forward applications _fast_. You can also look into what ASP.NET calls "Adaptive Rendering". This also serves to abstract away the nitty-gritties of the browser making the HTTP requests.
"As you may guess, it results from great frustration with well-funded idiocy in the wasteland of corporate American IT. Also I just tried to pay my property taxes online and the lovely .aspx page blew up with a CLIENT-SIDE VBSCRIPT error."
Sure there are idiots in IT. And sure there are idiotic ways to develop software. Microsoft's marketing department does a good job capturing market share in the corporate world. Once they do that enough, it moves into the realm of supply and demand. When we have enough money to pay, enough unqualified people move into all points in the software development cycle, and what we get is this.
Orkut is a great example of this. In its earliest incarnations it used postbacks and viewstates rather wildly but I notice every so often they seem to have rewritten it to use less and less of that stuff.
One thing I will disagree with you on - dividing your system up into input .aspx pages and reporting pages using reporting services - isn't good design. You shouldn't force a user to go to some other page to print the same data he sees on the screen. The data IS the report - if you can see it on the screen you should be able to print it on the paper without having to navigate to some other page. Think of the URL as the Dewey Decimal number for a piece of information. If you want to see the sales data for June, for instance, you might find it at http://mycompany.com/sales?fromdate=2007-06-01&todate=20... Why should you have to navigate to a different URL to print that? Tim Berners-Lee's original ideas of the URL as the starting point for the semantic web seem rather good to me but I don't think there are many implementations which come close to recognizing the potential of this idea. Breaking a system into separate sections for reporting and viewing just seems a bit daft. But again, that's the sort of behavior .Net encourages - not requires, but encourages.
For some reason I thought you were talking about "Reports" and "Reporting" in general, as offered by the Report Viewer Controls in ASP.NET (using rdlc / rdl).
I have used CSS in the past to allow users to print pages (as they see it on the page) and it has worked well for me. Although Report Viewer Controls in ASP.NET have their own magical hold on the business users (Probably because they are made to look and feel similar to other Reporting Packages, which Business Users are comfortable with). So, I still think thats a good way to go, if that is your audience. :)
But, I do understand what you are saying and agree that there is the possibility of people using this technology where it shouldnt be used.
Why should a programmer have to write special handlers just to save session state on the server side? Other platforms (Java, PHP, etc.) does that stuff for you in the background.
More like limps along..
It's funny how hating myspace has become as popular as hating microsoft...
I'd like to see you make something "run" with that many users.
The founders pored so much money into just barely keeping their non-scalable site running that they completely watered down their share of the company. Is that what you call succeeding?
As a very unscientific test, I just logged on to my Facebook account and my Myspace account and noted the following about my home pages:
Myspace html size: 16.38kb count of external .js files: 10 count of external .css files: 4 render mode: quirks load time (time to reload, thus assuming most requests cached, average of 3): 3191ms Facebook html size: 5.35kb count of external .js files: 27 count of external .css files: 25 render mode: standards load time (time to reload, thus assuming most requests cached, average of 3): 3207ms
I was surprised the load times were so close. MySpace feels slower but that may be because pages frequently include external images and sound files.
I don't mean these comparisions to either trash or promote MySpace or Facebook; instead I think it's instructive to consider which benchmarks translate to the best user experience and what techniques contribute to the better set of numbers.
Myspace's server software and html was bad. So so bad.
Note that I am not saying that PHP > .NET -- obviously on sites of this large scale, as has already been noted in the post's comments, using any technology "out of the box" is looking for trouble. What I mean to imply, however, is that perhaps for sites this big, .NET is the wrong thing. And, as the parent comment points, out, IIS certainly isn't helping things, though I don't think Apache would necessarily be a magic bullet. Craigslist, which does many megabytes of data transfer per minute, is considering switching to Lighttpd because Apache too heavyweight.
P.S. Sorry about the links -- I couldn't figure out how to link a text string to a URL. Can someone enlighten me?
For example, we use apache with mod_mono and write our own custom controls.
asp.net out-of-the-box will not work for a massively concurrent public facing app. However, neither will php, rails, django, any of the java frameworks. "re-invent the wheel" might be an overstatement for what you need to do, but no matter what...you're going to do some serious tweaking since every app has different needs
Our configuration....
- Lots of JS, homegrown ajax framework that extends YUI
- asp.net but with custom controls that we wrote
- custom http handlers take care of the call backs
- deployed on apache with mod_mono. mysql db
- The server, db, and xml APIs are great
- We really love the c# language
- We're already experts with the technology
.net is more than just the default settings for asp.net. Using any platform "as-is" will get you into problems.
We essentially have our own framework, with .net as the foundation.
ps - We're deploying on linux with apache and mod_mono
.Net is NOT for web sites, it is for web projects, really big and heterogeneous, with lots of services behind.
For other please use php and the like, with "quick submit to db" approach.
Edit: Also, I find it interesting that on a site so big (I mean MySpace, and thusly, on a site that should have a fair number of smart developers working on it), they have not changed the default IIS error message for something a little more site-specific and user friendly. To see what I mean, click the story's URL. :) Or is doing something like that deep voodoo on a robust web platform like .NET+IIS?
tagworld.com is really complex thing despite its simplicity from the outside. It has unique user base and handles around 1000 requests per minute. It uses around 20 web servers and 20 other servers for db, file storage, video/photo converting.
All code is written from scratch and .Net is great in maintaining the developement process. C# compiles and most errors get caught before deployment. In addition there is a buit in mechanism for validating dynamic pages, which also helps a lot. For some time we used to deploy the whole thing daily, with active users on the site.
.Net is more for the corporate world with lots of legacy code and outside apps. It just can't be done almost with any language except java.
I think the tools for .NET makes it better than others.
Eh, depends on who you talk to. I'd guess it's very much en vogue with web developers who are not so thrilled with the LAMP/OSS stack.
And nobody so far has mentioned one of the best features of ASP.NET apps: crazy speed. After everything gets precompiled it is amazing how much load a cheapo $1K server can handle.
Check out my comments below.