Boyd Stephen Smith Jr. wrote:
The output of ASP.Net is trash. Most notably it doesn't gracefully degrade as the browser loses features, and generates unnecessary round-trips to the server.
That was true for *Microsoft's* ASP.Net 1.1. The output HTML for the MS supplied controls was pretty ugly and non-standard. ASP.Net 2.0 is much improved. I also use Mono. Mono's .Net 1.1 has better output than MS's .Net 1.1.
I agree that event-driven programming generally a better fit for GUIs, however it's not really a good fit for HTTP. I prefer a middle ground that removes the spew of markup (which is bad) but doesn't work against HTTP/HTML. In general, the goal is for php/java/vb/c#/<your language here> to not generate much markup, but to generate the content inside the markup.
Middle ground is very good. I do like event driven programming and doing web apps with it seems natural to me. However, there are some things that do seem clunky and not to fit well with event oriented web apps.
Code separation is easily done without writing event-driven code. You can define procedure libraries and/or Class (and object) hierarchies that don't deal with markup but use their results in the markup.
True. However some models lend better to more separation. There is no one *true* method for every purpose. I have done the markup-with-code crap; The extremely complex abstractions Java crap for a simple web app; the make everything like a VB form MS C# web app crap; etc, etc. They all have had pros and cons.
Writing an event-driven dynamic webpage is a little questionable to begin with since the underlying protocol is request-driven. If your applications are request driven, you'll find they are much easier to debug. Work *with* the tools you are given, not against them. On top of that, you have very little control over the other side of the protocol, most of the time. This is basically a requirement for layer another framework on a protocol and changing how it works. E.g. TCP [stream-oriented with delivery guarantees] over IP [packet-oriented with no delivery guarantees] has fairly specific behavior for both sides of the TCP connection.
The protocol is not important and that is why it is OK to abstract it away. Event oriented web apps are not the answer for everything. They have pros and cons.
All I know is I don't want to ever have to do stuff like this again: echo "<table><tr><td>".$foo."</td></tr></table>\n"; Response.write "<table><tr><td>" & foo & "</td></tr></table>" & vbCrLf : )
The SquirrelMail source code is trash.
I haven't gone through all of it, or even much of it to really know. Though the compose.php page was a real mess. All I wanted to do was line the form buttons up nicely : )
Jim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= There's no place like 127.0.0.1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JimD Central FL, USA, Earth, Sol -- gentoo-user@gentoo.org mailing list
