• King (unregistered)

    I was inpsired for the frist time!

  • viewState.comments = base64(comments.all) (unregistered)

    Honestly, view state is not a terrible idea. For a page or wizard-like set of pages where everything is user input, so there's no security issues, and the size of the form state is small, it means that the server can be genuinely stateless, and you avoid annoyances like your server session timing out so everything you entered on the previous five pages is gone.

    A modern single-page app framework is actually doing something pretty similar, except it doesn't go back and forth to the server between actions because the entire system state just stays clientside.

    The WTF is that it was never really explained and so people didn't understand what they were doing, and used it for inappropriate scenarios where a server-side session variable (with, maybe, a cache key in the view state) would be better.

  • (nodebb) in reply to viewState.comments = base64(comments.all)

    The WTF is that it was never really explained

    I taught ASP.Net when it was new. All of Microsoft's training clearly spelled out the six state management mechanisms and what each was to be used for. It's the "if it works it's right" culture of most programmers that makes them jam everything into page state.

    Also, remember that ASP.Net came out in the days when you couldn't rely on client-side javascript. One of the primary goals of WebForms was to allow server-side programmers to build useful web pages without having to learn all of the little browser nuances .

  • Yazeran (unregistered) in reply to Jaime

    Also, remember that ASP.Net came out in the days when you couldn't rely on client-side javascript. One of the primary goals of WebForms was to allow server-side programmers to build useful web pages without having to learn all of the little browser nuances .

    Which could have been prevented by Microsoft themselves by actually make IE conform to the html specification.....

  • Brian (unregistered)

    Looks like a classic case of adding a no-op line for a debug breakpoint and then forgetting to scrub it before committing.

  • (nodebb) in reply to Yazeran

    Which could have been prevented by Microsoft themselves by actually make IE conform to the html specification

    Nice straw man.

    1. At the time, browser functionality was being implemented long before it was in the spec.
    2. Microsoft has always been a "backwards compatibility" company.
    3. The .Net team isn't Microsoft. They were building a product that serves their customers best. It wasn't their fault that other teams at Microsoft were actively trying to get web developers to conform to their specs instead of the W3C's specs, and actively creating alternative behaviors in order to get Microsoft's strengths from the past embedded in the future (e.g. ActiveX). BTW, this still happens, only now it's Google doing it.

    Web Forms were a perfectly suitable way to build web pages in the first few years of the 21st century. If you weren't very skilled, you got something that worked and was ugly under the hood. If you knew what you were doing, much of the ugliness could be avoided. Once javascript stabilized and client-side UI frameworks started maturing, then it was time to do things a different way.

  • (nodebb)

    I think Brian nailed it--this is a breakpoint line that didn't get removed, not a WTF.

  • (nodebb)

    Let me just go on a short rant and say this:

    The only thing worse than those accursed Ribbon replacements for heirarchical Menus is the trend towards replacing standalone client apps and IDEs with browser-based client tools. What a disaster from useability standpoint, and probably from a reliability standpoint as well.

  • (nodebb)

    Breakpoint lines would be better written as "var junkForBreakpoint = 1;"

    Replacing apps with browser-based tools depends on the nature of the app being replaced. My biggest projects over the past several years have been (1) replacing a customer-side Access app (send them monthly data update files and hope they can be arsed to run the import) with a web site, and (2) replacing the associated in-house maintenance app (full of magic numbers and other typical forms of sloppy design) with an in-house web site. So both of those were big wins, at least.

  • (nodebb)

    The only thing worse than those accursed Ribbon replacements for heirarchical Menus is the trend towards replacing standalone client apps and IDEs with browser-based client tools.

    Wait until you see the trend toward replacing admin tools with Slack bots.

  • löchlein deluxe (unregistered)

    Oooooh, ginormous state. I know that one, mostly in form of "why is my LimeSurvey slow, I only have 700 questions". (The entire state of your survey lives in the session variable, so sessions are often multi-MB hunks that get touched whenever you as much cast a sideways glance in the general direction of the survey's CSS file.)

  • Gordon JC Pearce (github) in reply to cellocgw

    The only thing worse than those accursed Ribbon replacements for heirarchical Menus is the trend towards replacing standalone client apps and IDEs with browser-based client tools. What a disaster from useability standpoint, and probably from a reliability standpoint as well.

    Yeah, no. Maybe in the olden days when we hooked everything up over serial cables, bu these days there is literally no application where a standalone client app that has to be deployed everywhere is better than a web app that you can use with the browser you already have. Literally nothing.

  • Dave (unregistered) in reply to Jaime

    ViewState was an attempt by Microsoft to abstract the browser out of sight. Silverlight was another attempt. ASP.NET was (and sadly for me right now) is an unnecessarily complicated bag of postbacks and ajax requests, and the HTML produced makes it painful to debug. Add frameworks like Telerik into the mix and the potential for wtf's goes up exponentially. Embracing the browser with ASP.NET MVC was such a relief by comparison.

  • masterX244 (unregistered) in reply to emurphy

    i usually call debug crap like that "Muggabatscher" (german dialect for fly swatter), easy to find with a search and completely unlikely to appear in productive code at all

  • Wizofaus (unregistered) in reply to Gordon JC Pearce

    I look forward to seeing your browser-based web browser.

  • Ulysses (unregistered)

    Remy used ASPX without knowing about ViewState? Wow.

  • (nodebb) in reply to Wizofaus

    It runs under his browser-based OS...

Leave a comment on “A Nice Save”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article