Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming Government The Internet IT Technology Politics

The ASP.NET Code Behind Whitehouse.gov 143

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."
This discussion has been archived. No new comments can be posted.

The ASP.NET Code Behind Whitehouse.gov

Comments Filter:
  • whitehouse.gov Blog? (Score:2, Interesting)

    by troll8901 ( 1397145 ) <troll8901@gmail.com> on Tuesday January 20, 2009 @09:33PM (#26540169) Journal

    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"?

  • by ergo98 ( 9391 ) on Tuesday January 20, 2009 @09:56PM (#26540405) Homepage Journal

    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 [w3.org] which is something that is remarkably rare [yafla.com] and shows a concern for craftsmanship.

  • New robots.txt file (Score:5, Interesting)

    by Cyclopedian ( 163375 ) on Tuesday January 20, 2009 @10:13PM (#26540555) Journal
    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 [kottke.org]
  • Re:Maybe we can (Score:3, Interesting)

    by shutdown -p now ( 807394 ) on Tuesday January 20, 2009 @11:47PM (#26541421) Journal

    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"?

  • by mr sharpoblunto ( 1079851 ) on Wednesday January 21, 2009 @12:58AM (#26542055)
    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 [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.

One man's constant is another man's variable. -- A.J. Perlis

Working...