views:

250

answers:

2

There are several talks about this issue, but I havent found a clear complete explanation of the flaws of the postback model in relation with other models. If you think this is a redundant question, and you are tired of these topics I'll understand you vote to close it but what I usually read in articles in internet and here it's the postback model to be mentioned as a flaw of the asp.net webforms model along with others flaws which I understand well (lack of separation of concerns, viewstate, unit testing, etc) but I see no broad, clear and complete explanation of why the postback model in particular is considered bad by many, or I dont seem to completely get it. Someone mentioned pages post to itself, other that some pages using the postbackmodel were slower (is this true?) , and I see detailed explanations of how the postback model and other models run, or theoretical explanations that's bad because it doesnt follow such philosophy or model, but not a explicity detailed list of what it makes bad in practice. So if you think it would be useful as I think to have such list of items of what it makes it bad in mind when choosing a model for developing, go ahead

+2  A: 

The criticism is mostly about two things:

  1. Postback makes your programming paradigm stateful and event-driven. The web is actually stateless, page concept is long since deprecated and the word of today is REST. Postback makes achieving these goals not straightforward.

  2. It makes programmers program as though the web is stateful and keep them in the darkness forever. So Windows programmers continue messing with WebForms like with WinForms. Many ASP.NET programmers with 5-7 years of experience have no idea of how HTTP works.

If you ask why postback is bad as an implementation of an idea to add statefulness to a stateless medium, I have to answer: it isn't. In fact, it is awesome.

If you ask why postback is bad as a concept, then read above.

Maybe you could clarify for us which point of view of presumed badness interests you.

Developer Art
that's what I was refering to when I said theorical explanations or references to models (such as REST) . Then in practice, by using the postback model (which makes me think the web has a state and it doesnt follow REST) which problems could I have in a web application by not following REST or thinking the web has state. ViewState gets big among other things? That would be a problem of ViewState, not postback, wouldnt be?
Pablo
For once, integration with other systems may be hard. It is, for example, impossible to provide a link to a page in some specific state (first loaded, then some controls clicked like sort headers on data grids).
Developer Art
@Pablo - The ASP.Net model is all one big thing. In my mind, you can't talk about Postback without the ViewState coming up, as they're both parts to a bigger whole.
Matt Grande
The postback model was intended to be a convenient abstraction for HTTP's request/response model, but it ended up being more harmful than helpful by hiding too much of the implementation from the developer.
Abboq
So Abboq, which problems do you know people having when 'the implemenation was hidden too much from the developer' because of the postback model?
Pablo
+1  A: 

WebForms is a lie. It’s abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand. Nothing you do with Webforms has anything to do with the web – you let it do the work for you.

Source: Rob Conery

Matt Grande
he doesnt mention the postback model in the article. He mentions the other flaws of webforms which I already read (testability, control over html, it works better with javascript, etc) That quote in particular doesnt mention any bad practical consequence of the postback model in particular (not of the webform model in general)
Pablo
As I said in my comment to the other answer, the PostBack model is part of a bigger whole. You can't talk about it in isolation. WebForms, the Postbacks, the viewstate, it's all part of the whole of (non-MVC) ASP.Net.
Matt Grande
But that doesnt mean the problems of webforms are the problems of postback. Id naming for example has nothing to do with postback. Now in the other comment it seems you said the problem of postback is actually the problem of postback/viewstate. Do you mean the problem of it is viewstate's size? Do you know any other problem of the asp.net postback/viewstate (no problems of the webform model which arent related to the postback) Developer Art mentioned another problem for example which is related to the postback/viewstate
Pablo