0

Being a PHP guy myself I recently had to write a spider to an asp.net site. I was really surprised by the different approach to ajax and form-handling.

For example, in the PHP sites I've worked with, a deletion of a database entry would be something like:

GET delete.php?id=&confirm=yes
and get a "success" back in some form (in the ajax case, probably a json reply).

In this asp.net application you would instead post a form, including all inputs on the page, with a huge __VIEWSTATE and __EVENTVALIDATION. This would be more than 10 times as big as above.

The reply would be the complete side again, with a footer containing some structured data for javascript to parse and display the result. Again, the whole page is sent, and then throwed away(?) since it's already displayed. Why not just send the footer with the data to parse (it's not json nor xml but a | separated list).

I really can't see why you would design a system that way. Usually you've a fast client, and a somewhat fast server but a really slow connection. Why not keep the datatransfer to a minimum? Why those huge __VIEWSTATE and __EVENTVALIDATION?

It seems that everything is done way to chatty and way to complicated. I really can't see the point and that usually means that I'm missing something. So please tell me, what are the reasons for this design and what benefits (and weaknesses) does it have?

(Yes I know that __VIEWSTATE is used to tell what type of form-konfiguration should be sent back to the server. But WHY is this needed?)

Please keep this discussion strictly technical and avoid flamewars.


Update:

Please excuse the somewhat rantish question. I tried to explain my view to be able to get a better answer. I am not saying that asp.net is bad, I am saying that I don't understand the meaning of those concepts. Usually that means that I've things to learn instead of the concepts beeing wrong.

I appreciate the explanations about that "you don't have to do this way in asp.net", I'll read up on MVC and other .net technologies. However, there most be a reason for this site (the one I referred to) to be written the way it is. It's written by professionals for a big organisation with far more experience than what I've. Any explanation about their (possible) design choice would be welcome.

iveqy
  • 468
  • 1
  • 5
  • 10
  • 5
    There seems to be a valid question in there, but it is hard to read around the rant that is there also. Can you reformulate your question such that it doesn't read like an anti-asp.net rant? – Bart van Ingen Schenau Oct 22 '13 at 05:57
  • 3
    I don't see the valid question. Using ViewState is optional and ASP.NET works with AJAX and JSON. – dcaswell Oct 22 '13 at 06:16
  • It's really hard to point out something you see as a flaw without making it a rant. I really tried, and it seems that I failed. I would gladly accept any more specific pointers on how to rewrite it better (as I'm interested in good answers I will of course try to formulate as good question as I can). – iveqy Oct 22 '13 at 06:19
  • `Please excuse the somewhat rantish question.` This overture does not excuse the "rantish" question. Also, ASP.NET Web Forms is yesterday's news. Prefer ASP.BET MVC. Always. – Jim G. Oct 22 '13 at 06:31
  • @JimG. Then please give me pointers on how to formulate it better. I must be possible to ask about the pros and cons of different designs even when they're competing against eachother. – iveqy Oct 22 '13 at 06:33
  • 3
    @iveqy: Language matters. Believe me - I get fired up about poor frameworks too (and ironically, PHP is one of them!). And in a chat room you're perfectly free to say that something "sucks", but not here, not in a question. You'd be better off if you reworded your confusion with and criticism of ASP.NET Web Forms in a much more objective manner. – Jim G. Oct 22 '13 at 06:39
  • I honestly think that this is more of a Google question. "Why was webforms built the way it was" seems to be fairly common knowledge across the internet, especially considering that it was built over ten years ago.... –  Oct 23 '13 at 01:56
  • @lunchmeat317 I would appreciate links since my google-fu doesn't match yours. – iveqy Oct 23 '13 at 07:32
  • Don't use GET to modify something. At minimum you should use POST, but preferably DELETE. – CodesInChaos Dec 11 '13 at 15:49
  • @CodesInChaos why? – iveqy Dec 11 '13 at 18:19
  • Because the HTTP specification says so. "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe"." – CodesInChaos Dec 11 '13 at 18:29
  • Another issue with your example is that it's vulnerable to CSRF attacks. (But that'd also be true if you used POST without an Anti-CSRF token) – CodesInChaos Dec 11 '13 at 18:31
  • It is awful dude. Webforms are horrible. They are the worst thing ever. I have not read any comment or post on this page besides yours because my mind has been made up for years and that is, I hate Webforms. The worst is combining Webforms with the AJAX Toolkit or even worse Telerik's AJAX Webcontrols. I accepted a job that mostly used webforms because they give 6 weeks of vacation. Even with the 6 weeks of vaction I wake up every day regretting my decision. ASP.Net MVC is not bad though. Anyways, sorry you had to enter the world of Webforms. You can now run back to the PHP world happy. – snowYetis Oct 15 '15 at 18:10

3 Answers3

8

Webforms was designed in a time when people wanted web applications to look like windows applications. This was a dark time on the internet where developers were forced to learn page lifecycles and deal with horrible view states and 3rd party controls which would cause such bloat the very fabric of the internet would be shaken...

That is Webforms, an archaic technology that is better left forgotten, and people who say otherwise should also be forgotten.

Like another answer says, MVC is the latest way from MS (although it was pretty much just spawned from Ruby on Rails I think) to design good websites.

Anyway the "Why is MVC great" is another topic, but for this one the answer is.

YES WEBFORMS IS AWFUL DO NOT USE IT FOR NEW PROJECTS

Grofit
  • 863
  • 2
  • 8
  • 11
  • If you compare ASP.NET MVC to PHP you should compare to some PHP MVC Framework – Royal Bg Oct 22 '13 at 10:03
  • 1
    Agreed, PHP is just the web platform, like ASP.NET is. – Grofit Oct 22 '13 at 11:40
  • @Grofit sorry - i disagree, simple php is more akin classical ASP ... the webforms platform is essentially different as it trys to make you use things such as viewstate, page life cicle and controls... not to say its mandatory - it is possible to work like simple asp... it's not just the default – Jonathan DS Dec 11 '13 at 13:58
  • The PHP comment was a whimsical thing I mentioned as the OP mentioned PHP as a comparison. Will remove it as the purpose of this answer is to highlight how shocking webforms, viewstate and page life cycles are in the modern age. – Grofit Dec 11 '13 at 14:51
6

Please keep this discussion strictly technical and avoid flamewars.

We'll see ;) (As Bart van Ingen Schenau points out, your question is a little ranty, which may not help the situation)

You're actually referring to ASP.NET Webforms. ASP.NET doesn't suck at all; MVC is great (and doesn't share the problem you mention).

You're right that the ViewState is large and seems like a nuisance to work with. In a way it can be for developers too. Why was it developed this way? Well it can be useful - I suspect particularly for developers coming from Winforms; the web behaves fundamentally differently from desktop applications but Microsoft tried to mimic the behaviour with abstractions like the ViewState (a big object to keep track of where everything is at). The large Viewstate being passed around is also less of an issue with things like Intranets (where Webforms may be fairly common).

A great discussion and comparison of the two is answered in this question: When to favor ASP.NET WebForms over MVC. Why it was designed this way is also mentioned.

Rowan Freeman
  • 3,478
  • 4
  • 30
  • 41
  • 1
    So basically they ViewState and complete webpage response is to improve development (ease) at cost of the product (speed/size)? – iveqy Oct 22 '13 at 06:42
  • I would say so, yes. Microsoft must have known that the Viewstate would become bloated and decided that the tradeoff was worth it. They may also have thought that with clever/proper design the viewstate may not become quite so large. – Rowan Freeman Oct 22 '13 at 06:44
  • 3
    Why it was developed this way has a lot to do with the state of the web c. 1999 -- loads of potential, doing just about anything interesting required building separate apps for netscape or IE, nobody saw ajax coming, CSS was a minefield. It was better than sliced bread (and php) in the early 00s. – Wyatt Barnett Oct 22 '13 at 14:51
0

I think that there is a simple answer to this, in my view its not so much that its bad as that the choices - compromises - that they made in order to produce a productive framework are not ones that you agree with.

That said the ease with which you can do (and I have done) really stupid things and the amount of bloat that you can trivially add to a page are good arguments for why its flawed.

The flip side of this is that you can do a lot of clever things with not a lot of effort - and if you're targeting a focused site for internal use for a business as opposed to a wider public facing website then the productivity gains can be a huge win.

With the ongoing development of the webforms framework and with developers that have a clue you don't now have to produce poor bloated pages any more either (though lots of people still will).

Murph
  • 7,813
  • 1
  • 28
  • 41