4 ms·
In short: because the web is inherently stateless and it's much harder to deal with than stateful UIs. I last used Delphi back around the turn of the century,
by gregmac 10y ago
In short: because the web is inherently stateless and it's much harder to deal with than stateful UIs.
I last used Delphi back around the turn of the century, so I'm remembering it as a drag-and-drop Windows UI framework/builder. ASP.NET WebForms is the most similar thing I've used (and it's been at least 5 or 6 years since I last really used it). I would not recommend investing a lot of time in it.
WebForms is great when you are starting. It is drag-and-drop, with 'controls' like text boxes, drop-downs, check boxes, grids, labels and pictures, and there are a ton of 3rd party control toolkits.
WebForms abstracts away the stateless nature of the web, and attempts to make it look like it's stateless. The trouble is it's a leaky abstraction, and at some point it's unavoidable that you will have to deal with it either indirectly or directly.
Indirectly, you deal with slow load times as a crazy amount of 'state' storage is required to maintain the abstraction. I dealt with an app at one point that had a grid with many text box controls in it, where the 'state' information was well over 1MB -- which gets sent as part of every request to the server.
As your app gets more complicated, you start running into more direct problems. In my experience, as soon as you're build any type of interaction that's not something built-in (can be done by clicking in the IDE), you start fighting with the framework. The lifecycle is necessarily complicated in order to support the stateful abstraction, and you must understand it very deeply to know where to put your code. The lifecycle is a series of events that happen between initializing, loading posted data, rendering output, etc.
At some point you realize the framework is getting in your way more than it is helping, and switch to just developing for stateless directly (which basically means MVC, or a stateful single-page app + stateless REST API).
- TimJYoung 10y agoSingle-page web applications that get loaded once and stay loaded, and are primarily driven by JS code, don't have any of these negative attributes. State is kept in memory, just as it is with a desktop application. There is no need to shuttle around large amounts of state, other than what is needed to authenticate against/communicate with the back-end APIs.
- bbcbasic 10y agoI remember having to hack new controls e.g. options that did away with the viewstate. Then had to roll my own event handling as the events which rrelied on comparing the viewstate will the latest value would no longer fire. Great times.