The ASP.NET Code Behind Whitehouse.gov

An anonymous reader writes "The author looks at the markup for the new whitehouse.gov site, launched today. It uses ASP.NET and various JavaScript libraries. It suffers from various inefficiencies, most easily remedied. Check the images and techniques used to build the site front-end."

Comments

Maybe we can

[AKAImBatman]

The whitespace.gov site has lots of whitespace characters.

Hmm... Freudian slip? FWIW, most of the whitespace is probably generated by the ASP technology they used. Spots where code goes can often generate unexpected whitespace. It's just a side effect of using scriptlet-type technologies.

Don't get me started on the "correct" way to write ASP. The tag-substitution gobbldy-gook encourages all kinds of bad page-development practices. The request-time attributes + templating taglibs seen in JSP provide a much cleaner separation between logic and HTML.

The whitehouse.gov site uses more GIFs than PNGs.

Ouch. Welcome back to 1996. Web developers looking for the smallest file size really need to learn that there is such a thing as palletized PNGs. They're even smaller than GIFs, even.

The whitehouse.gov site uses heavy JPG compression.

This is one place where my reaction is "BFD". As long as it looks acceptable under most circumstances, the people with the carefully color calibrated monitors (*cough*yeslikeme*cough*) can suffer a bit. Heck, half the JPGs on the internet look like garbage, so I'm not too worried about artifacting in the gradients.

The whitehouse.gov site uses IIS 6.0. The whitehouse.gov site uses ASP.NET 2.0.

Can we choose the right technologies for a website? No we can't! Thankfully, the President isn't hired to choose the best technology to run his website. ;-)

Re:Maybe we can

[AKAImBatman]

Did I say anything to suggest otherwise? As of right now, ASP.NET is ASP. Pointing out that they are different is like pointing out that Windows 95 != Windows XP when someone criticizes "Windows". Especially when "ASP.NET 2.0" is clearly spelled out in my post.

Now if you want to hear me complain about the inanity of ASP.NET 2.0 and 1.x being incompatible with each other, thus necessitating the need for both engines to run alongside each other in support of legacy modules, just keep it up. ;-)

Re:Maybe we can

[zoips]

The request-time attributes + templating taglibs seen in JSP provide a much cleaner separation between logic and HTML.

Wait, are you serious? JSP is no better than classic ASP; it's arguably quite a bit worse than classic ASP since it isn't language agnostic. JSP is a defunct and outstandingly annoying technology to work with that encourages all sorts of bad habits.

You might consider checking out Tapestry 5 for something a little more this century.

Re:Maybe we can

[caramelcarrot]

I'd expect that the imagine compression issues are short term to handle the large amount of traffic they're expecting now. Because they're damn ugly.

Re:Maybe we can

[AKAImBatman]

JSP is no better than classic ASP; it's arguably quite a bit worse than classic ASP since it isn't language agnostic.

Language agnostic is pointless when you're not writing code. Correctly written JSP 2.0 files should have no scriptlets in the pages. All the code should be in behind-the-scenes APIs or in parent servlets that use the page for rendering. The JSP solution is far more flexible than the ASP page-backing code files solution, and generally encourages better written code. Looking at ASP.NET pages that reference tags by IDs makes me want to tear my hair out in frustration. ("NO! You do NOT make six instances of the same tag so you can populate them in the page-backing code file! Arrrgghhh!!!")

On a broader note, .NET's language agnosticism is a farce. You can have any color you want (slate, charcoal, basalt, jet, etc.) as long as it's black. There are no real differences between the languages. They have all been modified to fit the C# mold.

JSP is a defunct and outstandingly annoying technology to work with that encourages all sorts of bad habits.

Whatever helps you make it through the day. I've worked with ASP.NET long enough to know that a bit of reality disconnect makes the pain a little more bearable. ;-)

Re:Maybe we can

[zoips]

Whatever helps you make it through the day

In comparison to Tapestry or Wicket, JSP is defunct, you really can't deny that.

Re:Maybe we can

[The Bungi]

The tag-substitution gobbldy-gook encourages all kinds of bad page-development practices.

That "gobbldy-gook" generates valid XHTML, if you tell it to.

templating taglibs seen in JSP

Bwahaha... sorry. There are better templating engines than ASP.NET 2.0, but JSP is not one of them - not in a million years.

Re:Maybe we can

[AKAImBatman]

Oh for the love of God. You have no idea what you're talking about.

http://java.sun.com/products/jsp/

Use JSTL. Don't use JSF. There, good to go.

I was there when the first version of Tapestry was introduced the internet. It was an interesting idea, but it took quite a few revisions to make it into something useful. Today it's an alternative to JSPs for rendering, but it by no means retires the use of JSPs. Same with Velocity and Wicket. And if you try to introduce me to Spring as if it's the latest and greatest thing (rather than a technology that's been around since the turn of the century), I will have to smack you. ;-)

Of course, all of this just points to the flexibility of the J2EE platform. (Primarily the servlet layer, but using a full J2EE implementation has a variety of pleasant advantages.) Which is why I feel like getting a lobotomy every time I have to work with ASP.NET 2.0 code. It's like going from a Cadillac to a Power Wheels. (Pow-pow-power wheeeeeelsss...)

Re:Maybe we can

[AKAImBatman]

That "gobbldy-gook" generates valid XHTML, if you tell it to.

So does every other page templating technology known to man. I can do it in ColdFusion if you ask me to. That doesn't make ColdFusion a particularly good language for scalable site development. Nor does it make ASP.NET anything special. And if I never see more code like this, it will be too soon:

Featured1.Attributes.Add(...);
Featured2.Attributes.Add(...);
Featured3.Attributes.Add(...);
Featured4.Attributes.Add(...);
Featured5.Attributes.Add(...);
Featured6.Attributes.Add(...);

*sigh*

Bwahaha... sorry. There are better templating engines than ASP.NET 2.0, but JSP is not one of them - not in a million years.

Because ASP.NET can output XHTML code? Listen, I've looked at nearly every template language and framework on the market. 90% of them result in coding one's self into a corner. JSP may be simple, but that's it's strength, not its weakness. Especially when you break up your JSP code into smaller pieces and use a higher level abstraction at the servlet level to produce more maintainable code.

Re:Maybe we can

[ILuvRamen]

I don't use PNGs because IE6 can't handle partial transparency of pixels and some morons still use it unfortunately. Other than that, it's a better format. Oh but I did use 3 layers in one website and 2 were semi-transparent PNGs and even my 8600GTS OC can't render it while scrolling without severe skipping in IE7 or Firefox 3. I think PNG still needs some work (or the browsers)

Re:Maybe we can

[shutdown -p now]

FWIW, most of the whitespace is probably generated by the ASP technology they used. Spots where code goes can often generate unexpected whitespace. It's just a side effect of using scriptlet-type technologies.

Don't get me started on the "correct" way to write ASP. The tag-substitution gobbldy-gook encourages all kinds of bad page-development practices. The request-time attributes + templating taglibs seen in JSP provide a much cleaner separation between logic and HTML

We're talking about ASP.NET here, not plain ASP, and these are two very different thing. ASP.NET is not a "scriptlet-type technology", not any more so than JSF is - in fact, much like JSF, it's component-oriented. Yes, it does allow scriptlets, but it strongly discourages their use. The correct (no quotes needed) way to write ASP.NET markup is to use components and data binding.

I'm not sure what's wrong with a website running IIS, either. Last time I checked, the NetCraft top10 uptime list had quite a few of those, which means that they do work. ASP.NET isn't that bad either, depending on what you want to do (for some tasks I'd rather prefer any decent MVC framework, which are much more plentiful for Java).

Re:Maybe we can

[palegray.net]

thus necessitating the need for both engines to run alongside each other in support of legacy modules

I can think of several languages that have had such issues over the years ;). Anyhow, I'm a dinosaur... I still do 99% of my web development in Perl on Debian (mostly using a framework I wrote myself a couple of years ago plus a sprinkling of third-party tools). Whatever gets the job done...

Re:Maybe we can

[shutdown -p now]

On a broader note, .NET's language agnosticism is a farce. You can have any color you want (slate, charcoal, basalt, jet, etc.) as long as it's black. There are no real differences between the languages. They have all been modified to fit the C# mold

This isn't entirely true. For example, you can have normal ISO C++ compile into pure MSIL - VC++ does that (if you use /clr:pure). When you look at the features the runtime provides, it's pretty obvious: it has raw data and function pointers, arbitrary-layout structs (this means you can also do unions), and manual stack memory allocation. With that, you can implement virtually any language you want.

Where the problems begin is with the CLR object model. Yes, that one is quite specific, and any language that wants to deal with it (you don't have to, but you lose the class libraries...) has to support it. Note that "support" still doesn't mean "require" - for example, C++/CLI adds the constructs needed both to create and to use classes compiant with the CLR object model, but it is entirely possible to only use them to interoperate with the standard .NET class library, and write the rest of your code in good old ISO C++, using STL and Boost. And yet, your whole app still runs on CLR, including the C++/STL/Boost bits.

Then of course there is F# (though I guess you can still find some similarity to C# there - but not that much), or, heck, Eiffel and IronPython and Common Larceny - all pure .NET implementations. Will you say that they all also "fit the C# mold"?

Re:Maybe we can

[shutdown -p now]

Sites where skilled and competent IT people picked Microsoft Internet technology based on it's technical or economic merits? Perhaps you can name one, I can't.

Just look around for .aspx pages when you browse, you'll see plenty.

Matter of fact is, IIS6 has been good enough, and IIS7 is great - and that's what any competent admin who knows both Unix and Windows (and has seen the latter some time after W2K last time, and not in the 90s) will tell you.

Of course, you don't give any specific reasons why one shouldn't "pick Microsoft Internet technology based on it's technical merits", especially when the rest of the network is also Microsoft-centric (AD etc - and there are good reasons for that as well, depending on what you're doing), so what can I really say? If you have any specific points, bring them on. Just a word of advice - before mentioning security, actually check the exploit stats for IIS6/7 vs Apache...

Re:Maybe we can

[Xest]

Whilst I'm a fan of PHP myself, I have to say the new ASP.NET MVC framework is rather good.

It really does beat hands down anything in the PHP world in terms of how quickly you can get something up whilst maintaining quality. I'd argue partly this is because of the Visual Studio integration and the power of Visual Studio to start with.

I wouldn't ever build a live app. in web forms, but I could be pretty tempted with the new MVC framework I have to admit. The various PHP frameworks out there that perform a similar task such as CakePHP could learn a lot from it in terms of how quickly you can build with it without the usual sacrifice of quality of software you get with Microsoft's tools (again, web forms for example).

Of course, the thing is as well, the Microsoft platform is slowly getting better, Windows Server 2008 and IIS 7 really aren't that bad, performance isn't too much different to Apache/PHP now and security since .NET is much improved. Of course, Apache was always pretty good so to say IIS is improving doesn't mean much in that context but certainly combined with .NET MVC I think the whole LAMP platform needs to watch out. The various PHP frameworks like Cake could do things such as dropping the stupid cake bake crap that fails half the time on Windows and is pretty much undocumented (It has one page in the docs that don't explain much beyond what it's for). In contrast Symfony is absolutely fantastic on documentation and so is Zend, but it's still much more hassle, and there's still many more security pitfalls you have to keep an eye on vs. ASP.NET MVC.

I'd probably like Java, but I've never used it professionally, only academically so can't compare with that. At the end of the day though, my point is that with ASP.NET MVC I can build a high quality site much more quickly and with much greater confidence than I can with any PHP framework right now.

Re:Maybe we can

[SBrach]

Here are a few major sites. Also Microsoft makes it pretty easy to break into web development for the first time with Visual Web 2008 and all the resources (templates, starter kits, custom controls, forums, how-to's, training docs and videos) available on the asp.net website.

Re:Maybe we can

[hesaigo999ca]

I tend to agree and disagree, the fact is, whatever clever thing you think you can do with JSP can also be done with ASP.net or even ASP....if you know your programming of that language, webservices, API and even .exe calls can all be done by all these technologies.

If you want to trash talk one language, or another, be sure that you have a firm point.

That being said, I tend to like one over another purely because of the ease of use by the designer/utilities/tools associated with it. Komodo was cool for awhile, but did not have the
extended libraries that .net does....and also it is easier to redo a .net website for someone
where as perl/python/php/jsp can come up with some pretty ugly syntax...

seeing as more hardcores use those languages, tends to lend to the use of obscure code, whereas the newbs liking to jump on .net will always to a tee keep their code LOOKING simple. Not efficient, but simple. SO redoing a full site in obscure code will be harder then redoing a site that is in cleaner more evident code.

Just my 2 cents

Re:Maybe we can

[AKAImBatman]

Can you recommend any good beginner references to get started with J2EE stuff?

FWIW, you should probably start with Glassfish (aka Sun Java System Application Server) and Netbeans. That combination is extremely smooth for J2EE development and will have you up and running in no time flat. (Plus it's all open source. ;-)) Just visit Netbeans.org and grab the full version or the version with Glassfish bundled.

Once you get it setup, you can configure features like the JDBC connections through the admin console on http://localhost:4848. The default user/pass is admin/adminadmin.

You can then review the official tutorial here. It covers the concepts pretty well. Truth be told, though, you can skip most of the details for now and jump straight to servlets. Servlets are Java objects that respond to network requests. HTTPServlets thus have methods like doGet, doPost, doPut, etc. All you have to do is read in the parameters passed and write out to the output stream. Due to their relative simplicity, the JavaDocs tend to be the best reference for programming servlets:

http://java.sun.com/products/servlet/2.2/javadoc/

(Don't be fooled, though. Simple ideas are some of the most powerful.)

The one part that's not covered by the JavaDocs is the deployment. You will need to understand the web.xml file for mapping servlets to URIs. Thankfully, Netbeans has some GUI tools that can help you understand the format and how it works. Advanced servlet development can have a whole chain of cool stuff like classes that intercept requests before and after the servlet runs (filters) and event listeners on session creation and destruction.

Once you understand servlets, then you can move on to JSP pages. At their simplest, JSP pages are HTML with code that get compiled internally by the server into servlets that print out the HTML. (Take a look at the generated code sometime to understand JSPs inside and out.) Modern JSPs should be written with taglibs. Taglibs basically work off the page attributes collection. Rather than working with solid page variables, entries are created inside the hashtable used to store page attributes. (These are attributes that exist only for the period of the request.) The standard pattern for these is that you execute a tag to retrieve a collection of information, then you use tags to output and/or loop through the values.

Servlets and JSPs can be chained by using the RequestDispatcher.include and forward methods. This allows you to not only include one page inside another, but you can also use the page attributes to forward data around. e.g. Let's say you have a servlet that reads from the database in response to a user's input. It can then dump the results into an attribute and call off to a JSP for rendering of that data.

Once you get that stuff down, you can start looking into the other features of J2EE. The JNDI directory is a wonderful way to handle connection pools. Don't put your connection information in your pages! Let the J2EE server manage the pools through the directories. This will make your application more adaptable. JMX allows you to wire up all kinds of meta-data about your app in the same way that SNMP is used to manage network devices. The authentication system can be used to automatically restrict resources without having to write protection code into your application. Java messaging can be used to send messages between systems. JavaMail is obvious. Support for SOAP/XML-RPC/REST and other features are built into the server and are easy to use. EJBs are best ignored unless you're developing a compute engine. (If you don't know what that is, all the more reason to ignore EJBs.) Java Server Faces should be avoided at all costs.

While that just barely scratches the surface of J2EE power and scalability, hopefully it will be enough to get you started. :-)

Re:Maybe we can

[plague3106]

Now if you want to hear me complain about the inanity of ASP.NET 2.0 and 1.x being incompatible with each other, thus necessitating the need for both engines to run alongside each other in support of legacy modules, just keep it up.

I think you fail to understand .Net, and why this is actually a good thing. Maybe you don't remember DLL hell? Side by side versioning is MS' solution to DLL hell, and many of the things that .Net 2 made incompatible were done because they were causing some serious problems in 1.1. It's foolish though to assume you can just recompile a library which uses version 1.1 of a library against the 2.0 version and expect nothing to break. Not very sound engineering, and you should retest your application after doing a version upgrade of libraries.

Re:Maybe we can

[AKAImBatman]

We're talking about ASP.NET here, not plain ASP

I can't think of any nice way to put this, so I'll just go with you fail it.

Don't you get tired of typing .NET after everything? That's as obnoxious of a marketing scheme as putting "Sun Java" before every name.

ASP.NET is not a "scriptlet-type technology", not any more so than JSF is - in fact, much like JSF, it's component-oriented.

Scriptlet technology is a core part of ASP.NET whether you like to admit it or not. Ideally it should not be used, but it is there. And JSF is an awful technology. Comparing ASP.NET to JSF is a mark against the ASP platform.

And in any case, the analog to ASP controls and data binding is taglibs like JSTL. (Exactly like I said in my original post.) Except in JSP you have a choice. You can use an alternative lib to JSTL or even create your own. The JSTL package is pretty powerful though, so there's little need to swap it out.

The correct (no quotes needed) way to write ASP.NET markup is to use components and data binding.

Yes, the whole "runat=server" thing I was just lamenting. Worst idea ever. It works great for basic websites, but it does. not. scale. I managed to at least figure out a way to evaluate tag names dynamically so that I could loop through a collection of tags. The ASP.NET programmer I inherited the project from was so impressed he said he'd make that a standard part of his toolkit. Just peachy.

As for the control options, they get really limiting really fast. Microsoft is the master at making the simple things stupidly easy. This gives the impression of power. But it fades very quickly when you try to scale the solution up or do anything that's outside the realm of "normal" usage. That's where the power to develop and deploy your own unified solutions comes in handy.

And don't even get me started on the amazing lack of a servlet analog. HTTPHandlers/HTTPModules are a poor excuse for an alternative, and tend to be divorced from the rest of the application. (Microsoft's take: Cohesive whole? What's that and why would you want it?) Oh and deployment. Oh the pain, the pain! Why oh why do I have to configure every little piece? Complain about J2EE all you want, but deployment is incredible.

I'm not sure what's wrong with a website running IIS, either.

Nothing. As long as you want a webserver. If you want a full blown application server, things fall apart quickly. Did I mention the deployment and cohesion issues? I'm not sure if these can be overstated. Application server functionality is a bolt-on module to IIS. At its core, it's really just a web server like Apache. J2EE is the opposite philosophy. It's an application server first with standard web server functionality hosted as one of the many applications running in the application space.

The end result is that easy things in J2EE take a bit more work, but the hard things are brain-dead simple. (e.g. dynamically interpreting URLs) Meanwhile, easy things are made even easier in IIS, but the hard things become convoluted and incredibly difficult.

Last time I checked, the NetCraft top10 uptime list had quite a few of those, which means that they do work.

FWIW, uptime measures uptime. Nothing more, nothing less. The top sites for uptime tend to be the ones with the most static content. The more dynamic your content is, the harder it is to maintain both the application and the uptime on a per-machine basis. (Case in point: The top 2 sites on Netcraft's list are a porn site and a site for a pasta product.) That's okay though. Clustering and fail-over features exist for that very reason. If you need to take a server down, your availability does not go away. And at the end of the day, that's a lot more important than your uptime numbers.

Re:Maybe we can

[AKAImBatman]

I think you fail to understand .Net, and why this is actually a good thing

I've been doing servlet code for over a decade. I can still take the code from one of those old applications and make it run in a modern J2EE server. No changes necessary.

The fact that Microsoft needed to make such radical changes after only a single release suggests that they have a problem with their engineering. No other server-side technology changes so radically between versions.

Being able to run original ASP alongside ASP.NET I can understand. Needing to run ASP.NET 1.x alongside 2.0 I don't. That's just bad engineering.

As for DLL hell, that's another problem with Microsoft's engineering. Microsoft likes to make libraries global. That's a bad idea for this very reason. J2EE apps bundle libraries inside the web application. So even if you have one app that requires an incompatible version of a lib, it won't impact another app running on the same server. Only if and when an API is stable and mature does it get moved up to a global level. And Sun takes the approach of getting input from the entire industry before making such a commitment. Thus you may or may not like an API, but a given API is not going to remove support for previous versions.

Microsoft takes the approach of imposing their will on the industry rather than asking for their opinion. You don't like Microsoft's API options? Don't worry, we'll impose a new and incompatible one next week. :-/

Re:Maybe we can

[plague3106]

I've been doing servlet code for over a decade. I can still take the code from one of those old applications and make it run in a modern J2EE server. No changes necessary.

Likely because Java doesn't ever change the behavior of a library, even if it's technically buggy. Oh, and anecdote is not evidence.

http://www.looseleaf.net/looseleaf/forum.nsf/8178b1c14b1e9b6b8525624f0062fe9f/e88692165c399a3b8525704400552d9c?OpenDocument

There's at least one case where an upgrade broke an existing servlet.

The fact that Microsoft needed to make such radical changes after only a single release suggests that they have a problem with their engineering. No other server-side technology changes so radically between versions.

Where did I say radical changes? I just said changes that were great improvements. Of course, as DLL hell teaches us, sometimes code relies on the buggy behavior, and fixing it breaks applications.

It might also be interesting to you that even major car companies typically have problems with the first (or sometimes even second year) model cars. That doesn't mean the car company has "a problem with their engineering." It means that without limitless resources to test the design, there are bound to be mistakes.

Being able to run original ASP alongside ASP.NET I can understand. Needing to run ASP.NET 1.x alongside 2.0 I don't. That's just bad engineering.

Sorry, I disagree. If your application IS behaving properly on 1.1, why add risk by trying to run it on 2.0? And seriously, who cares? Extra assemblies take up insignificant amounts of disk spaces.

As for DLL hell, that's another problem with Microsoft's engineering. Microsoft likes to make libraries global. That's a bad idea for this very reason. J2EE apps bundle libraries inside the web application. So even if you have one app that requires an incompatible version of a lib, it won't impact another app running on the same server. Only if and when an API is stable and mature does it get moved up to a global level. And Sun takes the approach of getting input from the entire industry before making such a commitment. Thus you may or may not like an API, but a given API is not going to remove support for previous versions.

DLL hell doesn't exist on the .Net framework.. which is my point. SxS is thier answer to that problem... a problem many developers loudly complained about. And typically MS has, with .Net, marked members obsolete instead of changing their behavior. There are relatively few cases where upgrading doesn't just work. but from a risk perspective, why take a risk you don't need to? Just so you can say you have the newest version?

Microsoft takes the approach of imposing their will on the industry rather than asking for their opinion. You don't like Microsoft's API options? Don't worry, we'll impose a new and incompatible one next week. :-/

Again, I disagree somewhat. I think they do listen to thier customers; they wouldn't be around if they didn't, and they've made significant progress in the past decade. I do agree that sometimes they offer too many solutions to the same problem.. but sometimes this is done with good reason. Take WinForms vs Wpf. Both serve the same purpose... but Wpf makes many great improvements over WinForms. The same can be said of Remoting vs. WCF. And again, MS hasn't removed the older API at all. It's still there, and it still functions the same as previous versions.

I'm sure there are plenty of obsoleted APIs in the java servlet world as well. You CAN still use them, but are discouraged from doing so. And they'll continue to work, just like WinForms will.

Re:Maybe we can

[AKAImBatman]

Likely because Java doesn't ever change the behavior of a library, even if it's technically buggy.

Somewhat correct. The key issue to keep in mind is that the spec is usually vetted to the point where the specification is correct. Sun then uses a test kit to ensure that VMs meet the specification. Sometimes an error is not caught and the implementation has to be updated. However, these situations are few and far between. They rarely affect code deployed using the APIs. (e.g. I once had an executable JAR file with a manifest that didn't meet the standard. My fault, but the JVM didn't call me on it. I had to fix it when Sun made their JVM more restrictive.)

Oh, and anecdote is not evidence.

Good. Because your anecdote isn't even valid. LTPA authentication is an IBM proprietary extension. From the sound of that link, it appears that IBM broke the LTPA functionality he was using. Which is one of my major gripes with IBM. They first convince people to use garbage that isn't in the spec, then they stop supporting it or change the way they support it in future versions.

Where did I say radical changes?

You didn't. I did. ASP.NET 2.0 was a radical change to ASP.NET. That's why users are forced to convert or continue running 1.1.

It might also be interesting to you that even major car companies typically have problems with the first (or sometimes even second year) model cars. That doesn't mean the car company has "a problem with their engineering." It means that without limitless resources to test the design, there are bound to be mistakes.

Bad analogy. Most car flaws are implementation problems, not design flaws in the underlying architecture. Usually the implementation issues are resolved in the next model year without a significant change to the vehicle platform. In fact, cars are far more evolutionary than most people realize. Revolutions in vehicle design are few and far between.

I just said changes that were great improvements.

Great improvements can usually be done without breaking old code. For some reason Microsoft decided that wasn't an option.

Of course, as DLL hell teaches us, sometimes code relies on the buggy behavior, and fixing it breaks applications.

No, DLL Hell teaches us that global libraries are BAD. Because applications can rely on buggy behavior or because experimental libraries need to make radical changes, it's better that applications be able to link against libraries locally rather than having everything global.

Sorry, I disagree. If your application IS behaving properly on 1.1, why add risk by trying to run it on 2.0? And seriously, who cares? Extra assemblies take up insignificant amounts of disk spaces.

Ignoring the pain and anguish caused during the transition period when IIS didn't support running both, then sort of did, and now mostly does, there's also the issue of obsolescence. Microsoft has basically made a decision for you that your code is now obsolete. At some point it will become inconvenient for Microsoft to continue supporting you and you will be left without an upgrade path. Certain features are already unavailable to users of the 1.x series of ASP.NET.

J2EE OTOH adds features into the same framework. I remember when JSPs were first implemented. It was a snap to use JSPs to make my next version of an application more sophisticated with less work.

DLL hell doesn't exist on the .Net framework.. which is my point. SxS is thier answer to that problem..

SxS is a patch (not a solution!) to a core design problem with Windows. Microsoft dropped support in ASP.NET 2.0.

And typically MS has, with

inefficiencies

[yincrash]

wait, a government project that suffers from easily remedied inefficiences??!?!
no way.

whitehouse.gov Blog?

[troll8901]

Not to mention ...

TUE, JANUARY 20, 12:01 PM EST
Change has come to WhiteHouse.gov
The first post on WhiteHouse.gov.

A "first post"?

Re:whitehouse.gov Blog?

[samriel]

I can imagine that post...

Poster:Barry
Subject:Change Has Come
FIRST!!!!!

(Black president.)

Re:whitehouse.gov Blog?

[Stormwatch]

FIRST!!!!! (Mulato president.)

Fixed.

Re:whitehouse.gov Blog?

[thegnu]

I thought it would be the ever-popular:

Poster: AC
FRIED CHIKKIN!!!! :)

Re:whitehouse.gov Blog?

[socsoc]

Except it was the second post. The MLK post was first...

The fact that he uses them makes them the best.

[Anonymous Coward]

The fact that he uses them makes them the best.

As of today, IIS6 is the best web server and ASP.NET 2.0 is the best web application framework.

Re:The fact that he uses them makes them the best.

[MindStalker]

Technically its the same server and software that was on whitehouse.gov yesterday under the Bush Administration. Like the Defense Secretary, keeping the stuff that works and would be a hassle to change around for right now.

This page is a way

[Nimey]

for the author to show his superiority to the Internet. None of what he cites really matters.

Re:This page is a way

[ergo98]

for the author to show his superiority to the Internet. None of what he cites really matters.

True enough. Indeed, the page in question actually validates as XHTML Transitional which is something that is remarkably rare and shows a concern for craftsmanship.

Re:This page is a way

[shutdown -p now]

Actually, merely using ASP.NET components for all markup will give you valid XHTML Transitional for ASP.NET 2.0+ with default settings. So no surprise there - it just means the guy who made the website knows how to use ASP.NET properly (well, maybe that's a surprise in and of itself, of course).

Re:This page is a way

[betterunixthanunix]

Exactly. When I saw this headline, I expected a solid critique of the use of ASP.NET (there are certainly reasons to criticize this), but instead, it looks like a 12 year old wrote it. The website uses JPG compression, has some extra whitespace, and uses -- gasp -- gzip? That is about as important as how often I clip my toenails.

Re:This page is a way

[Yath]

Strange - it almost seems like you interpreted everything on that page as a criticism.

PNG/GIF i'll forgive

[coryking]

But I agree with the heavy jpeg compression. It is one of my pet peeves, actually. Especially when people use JPEG's for images that really should be GIF's.

And yes, PNG's are smaller but I've found that IE6 can do weird things to them. Even IE7 can sometimes do funky things with the colors in PNG images. And don't forget you can't easily do transparent PNG's until IE6 is finally flushed out of our system (if you are reading this and are using IE6, please upgrade for the love of god).

Can we choose the right technologies for a website?

If they were using ASP.NET MVC you wouldn't have even known the thing was running ASP.NET. You could have thought it was mod_perl or ruby until you looked at the headers. Like most PHP sites, the aspx extension is a dead giveaway :-) ASP.NET MVC is url based, just like a good mod_perl app or a rails app.

Re:PNG/GIF i'll forgive

[ergo98]

Like most PHP sites, the aspx extension is a dead giveaway :-) ASP.NET MVC is url based, just like a good mod_perl app or a rails app.

Many, many ASP.NET sites use URL rewriting. http://www.yafla.com/dforbes/The_Best_And_Worst_of_2008/ goes to an aspx page. http://www.yafla.com/dforbes/Could_Microsoft_be_the_Patron_Saint_of_Firefox/ goes to the same aspx page, albeit with different parameters.

ASP.NET MVC brings a nice model, but it certainly wasn't first to rest-ful URL rewriting.

Re:PNG/GIF i'll forgive

[AKAImBatman]

And yes, PNG's are smaller but I've found that IE6 can do weird things to them.

256 color PNGs work correctly in IE6. No need to do anything special.

And don't forget you can't easily do transparent PNG's until IE6 is finally flushed out of our system

Put pngfix.js in an IE conditional tag if it bothers you. I refuse to stop the progress train because of Microsoft's ill-gotten monopoly.

If they were using ASP.NET MVC you wouldn't have even known the thing was running ASP.NET.

I confess, I haven't used ASP.NET 3.5/MVC yet. It would have been handy back when I inherited an ASP.NET project. Unfortunately, after my poor experiences with ASP.NET's scalability (or lack thereof), I'm not really inclined to develop another site in ASP.

As a former President once mumbled, "Fool me once, shame on you. Fool me twice... you ain't gonna fool me again." :-P

Re:PNG/GIF i'll forgive

[Mad Merlin]

The PNG hack for IE6 has some rather fatal drawbacks, particularly if you want to use it to replace background images instead of just regular <img>s. The most obvious issue is the z-index one, in that the PNG hacked PNG is rendered on a layer on top of the canvas, for which no events (including clicks) will pass through, unless you throw in a lot more hacks and you're really lucky. The other more insidious problem is that any element with a PNG hacked PNG must have layout, meaning it's almost guaranteed to have nasty side effects on any non-trivial page. I don't really care about IE6, but out of curiosity I tried applying the PNG hack to the gameboxes in Game!, and quickly scrapped the idea after finding several major issues due to the required hasLayout hack.

PNG8 is an interesting aside, but only marginally better than just serving GIFs to IE6.

Re:PNG/GIF i'll forgive

[KlomDark]

Hold off on the ASP.NET MVC stuff for now. It's really a pathetic implementation at this point.

Stuck with only basic HTML controls, nearly none of the more advanced ASP.NET controls work, as most continue to rely heavily on ViewState which isn't supported with the MVC framework.

So until they convert most of the advanced controls, it's just going to create more work to use it.

Worse than Ruby on Rails for now, but give them time...

Re:PNG/GIF i'll forgive

[rk]

I was about to call you crazy until I looked it up. IE6 was released August 27, 2001. Not a decade yet, but damned if it's not going on eight years.

Wow, I am getting old. Thanks for the reminder. :-)

Re:PNG/GIF i'll forgive

[datapharmer]

I would love to have the users I manage dump IE6. Ask Microsoft to support IE7 or IE8 for Windows 2000. We have some rather expensive hardware at work that requires Windows 2000 due to driver compatibility (XP will NOT work) and a website for a company we work with requires requires Active X... not a common combination, I know, but try getting users to open IE for one site and Firefox for another! It is harder than you might think.

Re:PNG/GIF i'll forgive

[elrous0]

Most of us have to code our sites for the benefit of our clients and users, not our own egos.

Re:PNG/GIF i'll forgive

[plague3106]

I confess, I haven't used ASP.NET 3.5/MVC yet. It would have been handy back when I inherited an ASP.NET project. Unfortunately, after my poor experiences with ASP.NET's scalability (or lack thereof), I'm not really inclined to develop another site in ASP.

You mean since you lacked the knowlege to properly scale and Asp.Net application.

Re:PNG/GIF i'll forgive

[maxume]

Every hear of the boy who cried wolf?

Re:PNG/GIF i'll forgive

[maxume]

If I knew you and knew that you tended to exaggerate, I would take everything you said with a grain (bucket sized) of salt, eliminating any shock value.

Also, I tend to view all intentional inaccuracies in the same light.

Helpful advice??

[biocute]

Many developers use the JQuery from Google's servers for improved performance and lower latency.

Is this guy serious? Advising Whitehouse.gov to use a remote server to serve javascripts?

Re:Helpful advice??

[c_g_hills]

Who said anything about hacking? It's entirely feasible that they would change the script they serve up themselves. It would allow Google to track all visitors to the site who have javascript enabled, a possible privacy violation.

Re:Helpful advice??

[GleeBot]

The theory behind using the Google-served copies of JavaScript libraries isn't to reduce load on the whitehouse.gov servers, but to improve caching.

Since HTTP caching is URI-oriented, a browser can't tell whether whitehouse.gov/xyz.js is the exact same thing as mypetcat.com/xyz.js, but it can if both sites reference a copy stored at google.com/xyz.js instead.

Re:Helpful advice??

[biocute]

Yes that's my point.

It's somehow disturbing to see people just so easily and readily trust Google.

Funny how we hardly trust cops who swore an oath to protect us, while we firmly believe in a corporate motto.

Re:Helpful advice??

[mangobrain]

The theory behind using the Google-served copies of JavaScript libraries isn't to reduce load on the whitehouse.gov servers, but to improve caching.

This is true, but it doesn't change the fact that it still introduces security/privacy concerns. The fact remains that if the remote JavaScript changes, the behaviour of all websites referencing it will change. The method by which it changes doesn't have to involve hacking Google (DNS hijacking (site-local or otherwise), HTTP cache poisoning, etc.), and changes don't have to be outwardly malicious to have unintended side-effects (AVG's LinkScanner, anyone?).

On the face of it, though, referencing JQuery files directly from Google's servers is no worse than them referencing external resources from WebTrends Live, which I presume they have to do at some point in the tracking process.

I freely admit these comments are verging on paranoid, but the point is, intentions != reality, and just because there may be one good reason to do something doesn't mean there aren't also good reasons not to. Reality doesn't care which reason you picked.

Re:Helpful advice??

[neomunk]

Well, I don't know about you, but I've never had google kill a member of my family and get its search engine buddies to cover it up.

I get what you're saying, but there's a visceral reason why many people don't trust thugs with a piece of tin on their chest, and I can't think of very many things google could do to inspire that level of raw hatred in its customers.
 

Re:Helpful advice??

[eison]

No, the idea is to get the script to the client faster, because most web browsers will only initiate two connections per site you're talking to. Serving different things off multiple different sites lets you download more than two things at once. See for example http://support.microsoft.com/kb/183110

Re:Helpful advice??

[socsoc]

This bears repeating. I use it for a few sites, but .gov should have their own system if they need to be so concerned about saving bandwidth by users caching files.

Re:Helpful advice??

[atamido]

Funny how we hardly trust cops who swore an oath to protect us, while we firmly believe in a corporate motto.

Google has never given me an expensive speeding ticket under suspicious circumstances.

Re:Helpful advice??

[csartanis]

Yes, I trust engineering PhDs more than I trust Joe Sixpack that spent a couple months in the academy.

Is technical efficiency the immediate goal?

[gabroo]

Personally, I think the site does a great job in balancing usability, layout, and (most importantly) good content. Given the extreme time pressures they were probably under, I think they did a great job.

open sourced govt please

[bluetigerbc]

hey, hopefully a new website like this can have votes for it's citizens about diff issues, stats on who voted for what, and senetor voting to ensure they follow what they say after elected. some free webspace/an email couldn't hurt either. whats webspace to an org like the govt? 2gb for all would get people more involved! as for the idea about open sourced govt, can such a concept be applied for our most imprtant (corrupt) system?

Re:open sourced govt please

[TrancePhreak]

We already had access to vote information. Such as Mr Obama likes to vote 'present' quite often.

Re:open sourced govt please

[socsoc]

You are truly an idiot, as evidenced by your grammar. Congressional voting stats are easily obtained and why the hell should the gov provide free webspace? They are busy (trying to half-assedly) provide essential services.

Re:open sourced govt please

[maxume]

Well, he only has 1,459 days to do nothing, and then you either get to eat crow, or holler "I told you so."

Either way, I recommend taking it 1 day at a time.

well at least it's not...

[Cyko_01]

...flash based!

Is it Valid?

[gloryhallelujah]

Fortunately, it's valid HTML.
Unfortunately...
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.whitehouse.gov%2F&profile=css21&usermedium=all&warning=1&lang=en

Re:Is it Valid?

[Dotren]

Looks to me like a lot of those CSS results are due to trying to make it cross-browser compatible. Looks like they went pretty far back too... some of those tags have been depreciated since Firefox 0.9.

I never really did the color comparison/validations on my pages although I can see how handy that information could be and I bet its pretty easily remedied.

What I am surprised about is that you mentioned its valid HTML. The article mentions the site uses .Net 2.0... its been my experience that most, if not all, of the pre-built controls they offer end up compiling into invalid code. I've heard you can change this by re-writing parts of the controls and if they did that to produce valid HTML then I'm impressed.

"...and has a focus more on appearance."

[LoadWB]

You mean like his entire campaign, and probably the "first 100 days?"

I believe government should be more like technology: it does not have to look good to work and, dammit, we would really prefer it work right out of the box!

Re:"...and has a focus more on appearance."

[LoadWB]

No, I really did not overlook it, I just both rue and lament it.

New robots.txt file

[Cyclopedian]

The switchover of the whitehouse.gov site also meant that the robots.txt file has changed. From around 2400 lines to just 2 lines: http://www.kottke.org/09/01/the-countrys-new-robotstxt-file

Re:New robots.txt file

[The Bungi]

Obviously because of growth through the years. The same file in 2001 was pretty much empty as well.

Re:New robots.txt file

[hansamurai]

Disallow: /firstlady/behindthescenes/text

Can't wait to crawl that one.

Re:New robots.txt file

[kenj0418]

That's only fair. He's the president for all the robot-american's also. They should be able to access the site as well.

And if you don't agree, you can "kiss my shiny metal ass."

Re:New robots.txt file

[russlar]

That's only fair. He's the president for all the robot-american's also. They should be able to access the site as well.

Richard Nixon is the true president for robot-americans!

times are changing

[icepick72]

We're not designing for modem bauds anymore. Platforms having a high level of abstraction (Java, Microsoft, etc) inject meta data into the pages. Really, I consider this a non-story. Sure it's fun to see how the website could be more efficient in fine detail; however it doesn't need to be. If you really want to do that, go back to CGI gateway.

Can do HTML all the time

[troll8901]

Slashdot'ers talk, think, eat, and dream in HTML.

Some can even describe their dreams using VRML.

Campaign servers ran open source

[rwa2]

http://www.linuxjournal.com/content/open-source-force-behind-obama-campaign

My take is that the whitehouse.gov servers are run by the government and have to conform to DoD security guidelines, which have only relatively recently included Linux configurations for certain commercial distributions such as Redhat. So they probably don't have the freedom to redo the servers with whatever they could cobble together with talented volunteers for the campaign.

Anyway, we'll eventually see whether all this talk of change only runs skin deep.

CSS Sprites

[Yvan256]

The author states that CSS sprites are "somewhat involved to implement". Unless you're really new to CSS, it's very easy to do.

What I find sad is the poor choice of image formats, i.e. all the graphics of the blue border should have been in 24-bit PNG, not JPEG.

I do applaud them for having clean URLs. Most of them anyway.

I'm an ASP.NET developer...

[Junior J. Junior III]

...and, admittedly, a pretty sucky one. I figured out html on my own and it's not the main thing I do at work, so I never learned how to do things "the right way", and neither did any of my co-workers, for the most part.

I do want to do things the right way, so I read articles like the one linked to in this story with interest. However, I get NOTHING out of them when they're written like this:

The whitehouse.gov site uses ASP.NET 2.0. The HTTP header that identifies the software says "X-Aspnet-Version: 2.0.50727". There is a way for this header to be removed, which saves about 30 bytes of bandwidth on every response. [Search for 'X-Aspnet-Version']

It's annoying to read someone going off about inefficient practices without telling you how to do it better.

"There is a way?" Nice. Thanks for sharing.

(Yes, the "[Search for 'X-Aspnet-Version']" is dead text, not a link to anything...)

It's like this with virtually every other tech problem I've ever tried to research... Zillions of pages of people complaining about a problem, suggesting fixes, or claiming that something they did fixed the problem, and very little in the way of actual, detailed information about the fix, how and why it worked, and what exactly the problem was that it solved.

Re:I'm an ASP.NET developer...

[AKAImBatman]

First hit on Google. Remember to search only the "X-Aspnet-Version" (remove the quotes) part of that text. BTW, as efficiencies go, this is a pretty minor one. It matters for a site like whitehouse.gov because they're likely to get a few million visits per day. (At least in the short term.) Very few websites have that problem, so I wouldn't worry too much about it. :-)

Re:I'm an ASP.NET developer...

[nacturation]

(Yes, the "[Search for 'X-Aspnet-Version']" is dead text, not a link to anything...)

Of course it's not a link. It's an instruction that you ought to follow if you're interested in finding it out for yourself.

Re:I'm an ASP.NET developer...

[Junior J. Junior III]

Of course, I can search for answers to questions using a search engine. It's not particularly effective though. It might be in this case, from what the other responder to my original post said, but that's not the point.

Probably better than 90% of the time when I try to search for "how do i..." or "I get [this] undesirable behavior..." I end up getting a lot of useless hits in the search results. Discussion boards where no one knows anything, everyone guesses, someone mentions that they fixed the problem, but doesn't bother putting up any details of what the fix is. "Professional" answer sites where you have to pay to see what the answer is. Some tantalizing hint that the problem I'm researching is actually the way people were doing it 8 years ago, and there's a better way to do things, and if you're lucky there's a name of a technology or new class of object, but little else.

All I know is that if that was the standard that I performed to when providing technical expertise to someone looking for help, my supervisor would lambast my lack of effort.

Re:Keep your adulation to yourself...

[CaptCovert]

'hero shot' is a term I've heard bounced around in web design/publishing before, which possibly may be what is referred to here.

Engineering nerds, this is an example!

[Anonymous Coward]

You will encounter this sometimes in your life, and you better get used to it. Sometimes, believe it or not, things are done simply because they need to be done.

They don't spend a lot of time laboring over every little detail, they have a list of tasks and a deadline and they do their best to meet the deadline.

They anticipate that nerds who nitpick Battlestar Galactica episode continuity errors will likely come in and stroke their butter soaked neck beards and chortle about how this or that could be done better to achieve 5% faster page loads, or allow for translation into Swahili.

But, they get paid either way and in the grand scheme of things trying to impress anyone on Slashdot is probably pretty low on anyone's to-do list.

As someone who's argued with people about vi vs. emacs in the past, I can honestly say you guys have reached a new low both in wasting time, having no worthwhile point, and being worthless slashdot editors. The trifecta.

Re:Engineering nerds, this is an example!

[hab136]

stroke their butter soaked neck beards

I hate you for providing that mental image.

Seemed to work for me...

[im_thatoneguy]

I went to it today. All the links worked. It looked nice and professional. It loaded fast even though I'm sure it was getting hammered.

No complaints from a user.

At the end of the day. Who gives a shit if it's 30bytes less efficient. A hummingbird landing on a telephone line probably disrupts my DSL connection worse.

Re:Seemed to work for me...

[0100010001010011]

It's not YOUR bandwidth, it's about theirs.

What is this ignorance?

[KlomDark]

I just love when people who know nothing about ASP.NET attempt to critique things:

The whitehouse.gov site has long ASP.NET IDs. There are many elements on the page that have very long IDs, which are mainly a waste of bandwidth usually. They could be easily removed on the server side.

<a id="ctl09_rptNavigation_ctl00_rptNavigationItems_ctl01_hlSubNav"...

Sorry bud, they can't really be removed on the server side - these are controls embedded in controls embedded in controls. Maybe a slight shaving of rptNavigationItems down to rptNavItms or something, but the long name is to be able to reference the embedded controls.

Please try again...

Re:What is this ignorance?

[JamesNK]

Sure you can. Create your own hyperlink control inheriting from the one in ASP.NET and exclude writing the id.

Re:What is this ignorance?

[iamhigh]

Otherwise, Qrirybcref pbhyqa'g ernq gurz naq vg jbhyq or n ybg uneqre gb pbqr!!!!!!!

Re:What is this ignorance?

[Amtiskaw]

Maybe he's from the future and thinks they're using ASP.NET 4?

Re:What is this ignorance?

[icepick72]

Rhetorical question I know, but an answer in general: binary data in html source code doesn't work so well for re-submission, POST/GET, client-side scripting/referencing, etc. -- that's why we often encode binary data as printable character sets into the HTML source code using encodings like base64. This is also one reason why the long ASP.NET IDs are kept human readable, also because the controls have to be reconstructed on the server side when the page is posted back.

Fix the problem now

[EdRob]

They could fix these perf problems instantly using the RPO (www.getrpo.com). If anyone knows the developers, let them know

Re:Fix the problem now

[TJCunn]

Its a great looking site, and since we're setting a new path for the country i agree lets fix it now and move forward.

Valid XHTML (Transitional)

[Charles Dodgeson]

Indeed, the page in question actually validates as XHTML Transitional which is something that is remarkably rare and shows a concern for craftsmanship.

I noticed that, too. The CSS however does not validate. Still I take your point. APS.NET is not the tool I would use, but they have done well with the tool of their choice.

Pick the low hanging fruit.

[mr sharpoblunto]

Most of the optimization suggestions in TFA are going to offer no real performance benefit. With gzip on, whitespace, long ID's & viewstate make pretty much no impact on the final page weight, but doing these "optimizations" is going to make your page a hell of a lot harder to maintain. Don't believe me, go to webpagetest.org and have a look, HTML accounts for only around 5% of the final page size. The best thing these guys could do to optimize the site would be to

• combine the css and javascript files.
• minify the javascript (as it is its taking up around 20% of the page weight)
• perform more aggressive css spriting of the gif and jpeg images to slash the request count further.
• remove ETag headers and add far future expiry headers to the images to speed up repeat page views and cut down on 304 responses from the server.

Who cares about a 30 byte http header when your page is over 800k and ~45 requests, there's plenty of low hanging fruit to pick first. Interesting thing is in the post above a tool called the rpo is mentioned, it seems to do most of the important optimizations automatically.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Anyone try a DNS lookup?

[iabervon]

$ host www.whitehouse.gov
www.whitehouse.gov is an alias for www.whitehouse.gov.edgekey.net.
www.whitehouse.gov.edgekey.net is an alias for e2561.b.akamaiedge.net.

Reducing their bandwidth and server load is just not a big deal. (See Akamai and note that the whole site takes the path that the "image" request takes in that diagram.)

Found a bug

[Toreo asesino]

This is a classic one:

ASP.Net has built in defences against XSS which are enabled by default. Most sites will however only catch this on the last line of defence; the server-side request causing HTTP error unless manually handled or overridden. It looks like this site also doesn't do any input validation for tags either causing said errors.

Really, you need to switch off the XSS checking and instead HttpEncode all the inputs manually so at least you don't break the site for potentially dangerous requests.

Still, small point though...just makes me slightly uneasy the web-admins left the server to fend for itself when dealing with potentially malicious inputs. Nevermind; It's a nice site overall.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Fitting the mold.

[shutdown -p now]

If you mean the lack of functors - yes, they did miss that, but that's just one bit of the language. And, of course, it's still quite possible to implement full OCaml on top of .NET, including functors - it's just that F# decided not to do that particular feature.

On the other hand, Don said that we should expect full-fledged type classes sometime in F# 2.0... now that would be quite something.

As for the rest, Eiffel is quite different from C# (and Java, and the likes) - for one thing, it has full MI, which is something the CLR object model does not natively support. Python - I won't even comment here, the difference between a statically and a dynamically typed language should be pretty obvious.

Comment removed

[account_deleted]

Comment removed based on user account deletion