• giammin (unregistered)

    if(!IsPostBack()) { ViewState["DWTF"]="frist"; }

  • sokobahn (unregistered)

    And .Net WebForms was not a news; we were using similar with Java 1.2 in 1999 (before Servlet API) with 512 Mega-bytes RAM at application server (pre-J2EE). The pages could be combined: meaning you can create XYZ form page and reuse it in 50 other parent pages, even many times at a page, with automatic renaming. There were server snapshots of per-session DB queries etc. that you could iterate many times and save back (it was also before JDBC). That was called visual and RAPID development.

  • LCrawford (unregistered)

    I'll admit, I'm a fan of the old "drop a button on the designer page", click on it and add backing code. I still haven't memorized the modern arcane rules to center text horizontally and vertically in a DIV. (4 answers on StackOverflow are wrong, 6 are just hacks that may or may not work, and 2 are correct.).

  • WTFGuy (unregistered)

    In fairness to MSFT, at the time ASP.NET WebForms was conceived, desktop UI was the way all meaningful apps were built. And that's where all the customer developer expertise was. ASP that had come before and all the various ways people were trying to build a dynamic website were simply awful considering they had to be built on top of HTTP+HTML which were really designed for serving & rendering static content from a fixed file library .

    To be sure, by the time WebForms become really popular, many nimbler options had come out. Some of which have survived 20 years of internet time, and some of which have not.

    So now in 2023 many websites are mish-mashes of a dozen different competing frameworks, lots of redundant and buggy stuff being done, built and maintained by a cadre of developers who half-understand the 15 technology stacks they use rather than fully understanding one. But as long as we can throw enough bandwidth and client-side processing cycles at the kludge (and hide / ignore all the javascript errors) it works well enough that civilization hasn't collapsed under a ginormous pile of bugs. Yet.

  • Oliver Jones (github)

    Yeah, Webforms, yeah, VIEWSTATE. A great source of WTFs. Remember the cluster***k from a couple of years ago where a website for the US state of Missouri used VIEWSTATE to let anybody VIEW the social security numbers of teachers all over the STATE?

    Missouri's guv, a bozo named Parsons, tried to prosecute -- for hacking -- the journalist who published the story and the professor who helped analyze the problem. Hilarity ensured, except for the teachers who were doxxed. Brian Krebs has a good summary.

    Please, please, please, if you're doing WebForms code with other peoples' personal information, do this

  • LZ79LRU (unregistered)

    Could be worse. It could have been Flash.

    ... I miss Flash.

  • Hal (unregistered)

    Wow so much hate for viewstate and pages.

    Look guys it was a product of its time. Microsoft had a lot of VB4/5/6 developers that wanted to transition to web. Those guys were writing LOB apps for which there was a strong desire to get away from complex to deploy and version control, hard to manage integrity issues etc business had with fat-clients all over the enterprise, but such apps would never need to go anywhere near the "world-wide" aspect of "web" apps.

    Microsoft came up with what for its time given the current capability of the user-agents a pretty good solution. It let the guys churning out facing business calculators and records management front ends, and reporting tools continue to work with the paradigm they understood. Unpacking some base64 and desalinizing it back into a set of collections and dictionaries was not performance issue for applications that had online user counts at the upper end in the low 1000s, similarly shoveling even a few hundred kilobytes around the LAN and even WAN wasn't a big deal in that era at internal scale.

    This also afforded you a pretty natural way to laterally scale the web tier if you did need to do so.

    Where it wasn't a good fit was true WWW sites/applications, and everyone figured that out pretty fast and moved on from pages for those types of development targets quite quickly.

  • (nodebb)

    The controls approach has some benefits from modularity and code re-use perspectives, but the ASP.NET WebForms were a very bad attempt at implementing it.

    And I agree with Remy: modern web development, for ex. using Angular and React, is also fraught with WTFs. Some of these websites today work slower than opening stuff over dial-up in the 90s.

    At this point, if a new client asks me to start a new web project, I'm most likely to recommend ASP.NET MVC (or even something similar in a different server runtime) with the most vanilla approach possible on the client: that's the only way to ensure maintainability and overall code quality, including but not limited to, performance.

  • Ludite (unregistered)

    Probably gonna get bashed for this. But I believe there is a place for WebForms...

    1. Good for datacentric web sites. Particularly internal ones.
    2. WYSIWG editor
    3. Easy to learn
    4. You can get away with knowing C#, SQL and a little HTML. No need to know javascript, CSS, HTML, jquery, and several different frameworks...

    Sure Viewstate is a bit clunky and consumes bandwidth. But it does work (I really haven't had any issues with it)... and we are starting to come full circle with doing full apps in the browser that require a larger download and more processing on the client side.

  • LZ79LRU (unregistered)

    Hence Flash. Just download the entire website to the user and run it like a browser mounted program. Truly a solution ahead of its time.

  • Barry Margolin (github)

    Isn't ViewState effectively like a cookie?

  • Richard Brantley (unregistered)

    I did some WebForms back in the .NET 1.1 and 2.0 days, and in contrast to it’s many apologists, even back then I knew it was a bad metaphor for web development. I will turn down employment rather than touch it ever again. To my mind it’s much like PHP - it is possible to write well structured clean code in it, but I have so rarely ever seen it in the wild. But even if the WebForms code is clean and well structured, it is still entirely the wrong model for how web sites work.

  • NoLand (unregistered) in reply to Barry Margolin

    Isn't ViewState effectively like a cookie?

    Back then, browsers allowed users to deny all cookies by a simple click of a checkbox. So cookies weren't universal. (This may sound weird nowadays, but this was when there were still notions of privacy and respect for a foreign machine.)

  • dpm (unregistered) in reply to LZ79LRU


    Thank you so much, LZ79LRU.

  • (nodebb) in reply to Barry Margolin

    A cookie generally holds an ID used to look up your server-side session. Cookies are limited to 4093 bytes per domain (i.e., you can set a few cookies if you want, but their lengths must add up to 4093 bytes or less.)

    Viewstate holds all the data you might have put in Session instead. It is effectively unlimited (although if it exceeds your server-side max request length, an exception will be thrown). 150K is not unheard of. That's 150K making its way back and forth over the wire ON EVERY REQUEST. It's stupid.

  • (nodebb) in reply to Oliver Jones
    Please, please, please, if you're doing WebForms code with other peoples' personal information,

    then STOP NOW.

  • (nodebb) in reply to Ross_Presser

    In addition to the cookie size limit, and the ability of the users to disable cookies, there was another, much bigger and actually the main reason, why a cookie wouldn't work: ViewState is per page, whereas cookies are per domain. Therefore, cookies would not work if multiple tabs were opened with the same web site.

  • TheCPUWizard (unregistered)

    WTFGuy - many valid points...

    As a side note, I recently finished a system (custom from the ground up) that basically mimics the WebForms paradigm with some SOAP messages.... Yup, "everything old is new again".... For this particular set of circumstances it worked out really well, even though it is a statistical anomoly against more common types of web/browser elements...

  • LZ79LRU (unregistered) in reply to dpm

    As someone who has worked with Flash extensively I can honestly say that the hatred of it by some people and institutions is heavily misguided.

    Yes, as a framework for actually making web pages it had some serious flaws. The primary being security issues and treating web pages like they are applications. But the hate it gets for those is unwarranted.

    The first is something we can't blame it for because frankly the only secure system is one nobody uses. That's just the nature of software. It's like that old joke that says there are no viruses for Linux because not enough people use it to make writing viruses worth it. And whilst it is exaggerated there is some truth to that. And to their credit Adobe and Macromedia before them did their best to find and patch them.

    The second is a philosophical discussion and not a flaw. Personally I think the web and desktop are two very different environments that can't really be handled the same way. But a lot of people disagree vehemently. Which is why we periodically see the idea of either writing web pages like applications or more recently the trend of using web technologies instead of desktop programs.

    So whilst we might disagree with that idea a lot of people like it. And thus there has to be something to it. And that something is the idea of ease of retraining and reuse of knowledge for developers. Which is one of those things that sound too good to be true because they are. But that still means it "sounds" good.

    Continued in part 2.

  • LZ79LRU (unregistered)

    More importantly though all this is really not what Flash was about. What Flash was, and what made it great, is a tool that was easy to use, intuitive to learn and designed for a wide variety of people with different backgrounds.

    At its peak Flash combined an easy to use vector graphic interface with a powerful and intuitive to use scripting language and a timeline tool which allow you to make animations visually without having to script. What this meant is that whether you were a programmer with little skill in drawing or an artist with no skill or inclination to program or anywhere in between you could pick Flash up and become proficient in it relatively quickly and without ever feeling lost or overwhelmed.

    In that respect it was a true precursor to the modern out of the box ready to go game engines like Unity and Unreal. Indeed, having worked with all three of those I would say that Flash easily beats both in terms of the ease and accessibility of the onboarding process.

    Which is precisely why it was so popular. Whether you wanted to make a web page or a video game Flash was just there. It was easy to learn, intuitive to master and it just worked.

    And honestly I think modern software like Unity and Swagger have a lot to learn from that.

  • Albert (unregistered)

    I maintained a number of Web Forms apps that as part of their exception handling, send the (encrypted) VIEWSTATE as part of an email, which of course having to comb through the kilobytes of gibberish to find the one line of (sometimes also incomprehensible) error text. And even better is that it was written in 3 layers (because that's how it was "supposed" to be done), so an email (with the same encrypted VIEWSTATE) would get sent by each layer as it bubbled up to the top. Good times.

  • nasch (unregistered) in reply to sokobahn

    JDBC was released in early 1997, so it predates the Java 1.2 in your anecdote.

  • BOKUwaOTAKU (unregistered)
    Comment held for moderation.

Leave a comment on “The View From Your State”

Log In or post as a guest

Replying to comment #:

« Return to Article