Some things like making an endpoint that servces json and xml responses is almost trivial on Nancy or ServiceStack, easy in ASP MVC with WebApi, and a pain in webforms.
From what I understand, what I'm using is lighter weight than MVC or anything else being discussed here. So far, I see no problems with what I'm doing.
E.g., for the MVC architecture, I have a server farm and software architecture, and it's simple and more than enough.
If you have "event handlers" like "Page_Init" in a .apsx.vb file then you are using web forms. No other framework has these. They were an attempt in the late 1990s to make the web look like winforms. it worked, to a degree.
> what I'm using is lighter weight than MVC
I doubt it.
> I see no problems with what I'm doing.
That's a different question; I'm sure what you're doing is workable.
> You might be absolutely fine not knowing those things, but at some point down the road you are going to be lacking some essential knowledge of how HTTP works. To put it simply: everything - Ruby, PHP, ASP.NET, you name it - uses GET and POST requests underneath it all. Learning about them would be of great benefit to you in the long term.
Right. But I do understand GET and POST, and, again, via some classes in ASP.NET have access to that data, including raw, if I want it. Occasionally I considered looking at the raw data but too quickly found ASP.NET classes that had the data I wanted already all parsed, etc. in properties of the classes; I don't think I've touched the raw GET/POST data yet.
Yes, ASP.NET does some things for me, e.g., ViewState, which took a while to understand. Okay.
I didn't like the way ASP.NET and IIS handled user session state so just grab a GUID, convert it to a string, put it in a hidden field, and send it to the user. Then on postback, I get the GUID, and that's my session ID for that user. That session ID, just as the string is the key in a little key-value store I wrote as a separately running Visual Basic .NET console application using class instance de/serialization, TCP/IP, and two instances of a .NET collection class (hopefully AVL trees or red-black trees). The key-value store is single-threaded so doesn't need to use the concurrent versions of the collection classes. Timings indicate that on a 3.0 GHz single core processor, the store should be able to send or receive 2000 key-value pairs a second, enough to send 1000 Web pages a second.
As far as I know, I don't really use Web Forms. I use placeholders, tables, buttons, and text boxes via static HTML and/or the corresponding ASP.NET classes. ASP.NET builds a big tree of all the 'controls', etc., and at 'render time' does apparently a depth first traversal of the tree and scribbles out the corresponding static HTML to send to the user. And if ASP.NET wants to send the user some JavaScript, it writes and sends that, too -- so far have yet to write a single character of JavaScript. Fine with me.
So far my Web pages are next to dirt simple and, with the JavaScript, send from my server (not counting data from ad servers) for about 400,000 bits each. Likely much of the JavaScript is boilerplate and can be shrunk, but that's for later. I have no pull-downs, pop-ups, or roll-overs; each screen is exactly 800 pixels wide; there is some simple text, a few simple images, some push buttons and text boxes, all arranged in tables for layout. Some of the screens have to be a bit dynamic so get generated in loops in Visual Basic code and are not just static HTML, but the only dynamic part is the number of rows in some tables -- we're still talking simple.
I guess, "If it ain't broke, then don't fix it.".
AFAIK, a pull-down is a menu that usually starts near the top of a Web page and 'pulls down' so that its items cover much of the page and let the user click to pick one of the menu options.
I have contempt for pop-ups and also pull-downs so use "ups" for one and "downs" for the other.
Instead of such controls, I prefer a better considered user interface (UI) that doesn't have the screen jump around. Basically for a good user experience (UX), I never want the screen to 'jump' in a way that surprises the user.
A screen that jumps has a UI that is difficult to document succinctly and, thus, usually is not documented well or at all and, then, requires a user to experiement with the UI, assume some truths from some really thin hints, and waste effort. Instead I want the UI to be easy to understand carefully and thoroughly without experiments or guessing.
You might be absolutely fine not knowing those things, but at some point down the road you are going to be lacking some essential knowledge of how HTTP works. To put it simply: everything - Ruby, PHP, ASP.NET, you name it - uses GET and POST requests underneath it all. Learning about them would be of great benefit to you in the long term.
A slightly inaccurate analogy: you can make a perfectly functional web site with Dreamweaver, and not touch a single HTML tag. It'll work fine, until it doesn't, and then you're going to be in a lot of trouble. Given that you don't know what's going on underneath Dreamweaver's GUI, your only option will be to keep hitting 'undo' until it works again.
Same for a 'framework'. Same for Nancy and everything else in the OP.
ASP.NET WebForms is a 'framework', too. They're just different frameworks. WebForms, as the name suggests, is particularly good at creating forms- it has numerous abstractions to help you maintain state. It's great for intranet data gathering/presentation stuff. But the pages are very, very heavy, loaded down with code that never gets used. So it has pluses and minuses. Just like MVC and Nancy.