ASP.NET You're doing it Wrong. An Introduction to Nancy(mat-mcloughlin.net)
mat-mcloughlin.net
ASP.NET You're doing it Wrong. An Introduction to Nancy
http://mat-mcloughlin.net/2013/08/20/aspnet-youre-doing-it-wrong-an-introduction-to-nancy.html
7 comments
The article title is pretty misleading. NancyFX looks very succinct, but it solves much smaller scope of problem than ASP.NET MVC does. The only notable comparison he makes between NancyFX and ASP.NET MVC is routing -- while the level of indirection in the RouteManager and the folder structure conventions of the default one provided in ASP.NET MVC, the purpose of that is to give enterprise applications an extensibility point. If you don't need all the ways you can customize ASP.NET MVC, sure go with a simpler framework. But there's nothing "doing it wrong" about using ASP.NET MVC if you need the services it provides.
"the purpose of that is to give enterprise applications an extensibility point"
No its not.
"If you don't need all the ways you can customize ASP.NET MVC"
Nancy is pluggable at pretty much any point. You don't like the way routing works in Nancy, plug it. Don't like the base module, plug it.
Nancy is far more extensible than WebAPI or MVC.
Having said that, anything you can do in WebAPI / MVC you can do in Nancy, and anything you can do in Nancy, you can do in WebAPI / MVC
Nancy just has a nicer API.
No its not.
"If you don't need all the ways you can customize ASP.NET MVC"
Nancy is pluggable at pretty much any point. You don't like the way routing works in Nancy, plug it. Don't like the base module, plug it.
Nancy is far more extensible than WebAPI or MVC.
Having said that, anything you can do in WebAPI / MVC you can do in Nancy, and anything you can do in Nancy, you can do in WebAPI / MVC
Nancy just has a nicer API.
>Nancy just has a nicer API.
In your opinion.
A lot of older developers don't like the Func<>iness of some of these newer frameworks. Just something to consider.
In your opinion.
A lot of older developers don't like the Func<>iness of some of these newer frameworks. Just something to consider.
I think this guy has never heard of Web API (http://www.asp.net/web-api). He's saying MVC is bad, then he writes code that just returns serialized data instead of views.... which is exactly what Web API does.
"Which basically means it can be used as a viable replacement for WebAPI or MVC".
He does know about WebAPI.
He does know about WebAPI.
Oh I agree that he mentions it in his article, but everything he says is good about his library is already done (better, I might add) by Web API.
I'm pretty sure Nancy predates the Web API by a decent amount of time. So it wasn't "already done" when Nancy was written.
They both have differences, and are equally valid choices. Aside from anything else, I give Nancy time because I'd love to see more open source independent development on the .NET platform.
They both have differences, and are equally valid choices. Aside from anything else, I give Nancy time because I'd love to see more open source independent development on the .NET platform.
skrowl, can you quantify your arguments as to why you think Web API is better? In what way? What do you not like about Nancy, where does it fall short?
How is anything WebAPI does, better?
Its routing is rubbish - waiting for V2 for fixed routing (AttributeRouting support so its not hidden away)
Its terrible to extend.
Its slower than Nancy.
Its hard to test out of the box.
Its routing is rubbish - waiting for V2 for fixed routing (AttributeRouting support so its not hidden away)
Its terrible to extend.
Its slower than Nancy.
Its hard to test out of the box.
Have you used Nancy? When you have then you can say WebAPI is better. Until then, keep your MS Fanboy comments to yourself
Ahh, WebAPI. The thing that MVC should have been, but still falls short. Promoted as an 'API' despite the fact it does the same thing as MVC, only slightly better.
Guess what, your website is an API, it just happens to return text/html instead of some other format you specify. If you use MVC and WebAPI, you're doing it wrong.
Also...
http://weblogs.asp.net/shijuvarghese/archive/2013/07/30/writ...
vs
http://www.marcusoft.net/2013/01/NancyTesting3.html
Sums up WebAPI for me.
Guess what, your website is an API, it just happens to return text/html instead of some other format you specify. If you use MVC and WebAPI, you're doing it wrong.
Also...
http://weblogs.asp.net/shijuvarghese/archive/2013/07/30/writ...
vs
http://www.marcusoft.net/2013/01/NancyTesting3.html
Sums up WebAPI for me.
Many people develop a web-app using MVC-based framework and have a separate API endpoints using lightweight library.
SpringMVC + JAX-RS1/2
RoR + Sinatra
A web-app using some framework + NodeJS for API
There's nothing wrong with that as you may want to have different models or different configurations (throttling or whatnot).
Using MVC-based framework for your API endpoint is overkill.
SpringMVC + JAX-RS1/2
RoR + Sinatra
A web-app using some framework + NodeJS for API
There's nothing wrong with that as you may want to have different models or different configurations (throttling or whatnot).
Using MVC-based framework for your API endpoint is overkill.
Isn't this what WCF does as well? WCF will happily interact with JSON clients, and make spinning out services blissfully easy and efficient.
Hahaha, have you actually used WCF? You may as well just use SOAP. You wont end up slitting your wrists.
WCF's only benefit is TCP bindings. If you're doing any HTTP stuff, stay clear of WCF.
WCF's only benefit is TCP bindings. If you're doing any HTTP stuff, stay clear of WCF.
I'm wondering if you've ever actually used WCF, or if you're simply incredibly ignorant about how to use it (why understand existing systems when you can recreate them -- poorly -- yourself), as creating a JSON-friendly web service in WCF is absolutely trivial. Through some very large scale systems I have had absolutely no issues, whatsoever, with it.
Your issues with it might have more to do with you.
Odd that the two single replies I got are a couple of bulldogs desperately shooting any alternative to this submission down.
Your issues with it might have more to do with you.
Odd that the two single replies I got are a couple of bulldogs desperately shooting any alternative to this submission down.
WCF is extremely powerful, but it is poorly documented for a system of that complexity.
Configuration is a black art: it involves configuring the various WCF interfaces/components in XML. Because of the poor documentation and bugs this can be quite a lot of work. It was quite obviously architected to be used with a configuration UI - it's similar to XAML and IIS in that respect - only Microsoft never bothered making the investment the way they did for IIS + XAML.
It's also buggy - XML parsing in particular is broken - and the default serializers are horribly slow.
It's extremely extensible, but extension requires considerable work. A lot of the base classes are either sealed or internal (or both), which just exasperate this. Without either the source, the tests, proper documentation or the ability to extend existing implementations it turns a job which should take an engineer an hour into a job that will take them 3 months.
So basically, Microsoft have done done everything to make using WCF in anything but the most basic scenarios hard and expensive.
As others have said, if you're doing anything over HTTP then you're better off using either Web API or better yet ServiceStack. I have good experience with the latter.
Configuration is a black art: it involves configuring the various WCF interfaces/components in XML. Because of the poor documentation and bugs this can be quite a lot of work. It was quite obviously architected to be used with a configuration UI - it's similar to XAML and IIS in that respect - only Microsoft never bothered making the investment the way they did for IIS + XAML.
It's also buggy - XML parsing in particular is broken - and the default serializers are horribly slow.
It's extremely extensible, but extension requires considerable work. A lot of the base classes are either sealed or internal (or both), which just exasperate this. Without either the source, the tests, proper documentation or the ability to extend existing implementations it turns a job which should take an engineer an hour into a job that will take them 3 months.
So basically, Microsoft have done done everything to make using WCF in anything but the most basic scenarios hard and expensive.
As others have said, if you're doing anything over HTTP then you're better off using either Web API or better yet ServiceStack. I have good experience with the latter.
"So basically, Microsoft have done done everything to make using WCF in anything but the most basic scenarios hard and expensive."
I've implemented and used WCF in very large financial systems, under enormous loads pushing absolutely massive amounts of data around. These are very complex systems I am talking about, and WCF was used in many capacities, one of which was as a HTTP Restful service layer (and given that we also used it through queueing, and over TCP, it added a consistency to the stack).
It certainly wasn't perfect (the configuration happens to be a particular point of irritation), but it wasn't a pain-point at all. It just was a non-issue and did the job, and was no engineering challenge whatsoever.
But, I suppose, it was "basic" in that we looked to WCF as a service front-door, and didn't actually see any need to alter it much, in the same way that we don't modify the kernel of the Linux instances that we work on or the source code of the nginx variants we use. We have a different domain that is where we add value, and building (or extending) a service handler like that would have been a gigantic waste of time.
Which, I suspect, it is for most people who do so. People have this intrinsic desire to seemingly make their own tasks more difficult for often ill-conceived or illusory goals.
I've implemented and used WCF in very large financial systems, under enormous loads pushing absolutely massive amounts of data around. These are very complex systems I am talking about, and WCF was used in many capacities, one of which was as a HTTP Restful service layer (and given that we also used it through queueing, and over TCP, it added a consistency to the stack).
It certainly wasn't perfect (the configuration happens to be a particular point of irritation), but it wasn't a pain-point at all. It just was a non-issue and did the job, and was no engineering challenge whatsoever.
But, I suppose, it was "basic" in that we looked to WCF as a service front-door, and didn't actually see any need to alter it much, in the same way that we don't modify the kernel of the Linux instances that we work on or the source code of the nginx variants we use. We have a different domain that is where we add value, and building (or extending) a service handler like that would have been a gigantic waste of time.
Which, I suspect, it is for most people who do so. People have this intrinsic desire to seemingly make their own tasks more difficult for often ill-conceived or illusory goals.
That's where WCF works - in internal systems where you have control over both clients and services.
Trying to do a phased replacement of existing J2EE SOAP webservices without the ability to change the clients (meaning that you need wire-level compatible) and you'll see just how hard WCF is to extend.
The fact that it IS possible to do that kind of integration is a testament to just how powerful the framework is. It's just a shame that Microsoft didn't spend an extra 5% effort on the documentation (or just open sourced it).
I should add that we're currently using WCF as an integral part of our system as despite the drawbacks being able to support TCP (and MSMQ etc) and everything else in one framework is worth the extra complexity. Plus we have a lot of organizational knowledge of WCF now.
Trying to do a phased replacement of existing J2EE SOAP webservices without the ability to change the clients (meaning that you need wire-level compatible) and you'll see just how hard WCF is to extend.
The fact that it IS possible to do that kind of integration is a testament to just how powerful the framework is. It's just a shame that Microsoft didn't spend an extra 5% effort on the documentation (or just open sourced it).
I should add that we're currently using WCF as an integral part of our system as despite the drawbacks being able to support TCP (and MSMQ etc) and everything else in one framework is worth the extra complexity. Plus we have a lot of organizational knowledge of WCF now.
Currently in the process of ripping out WCF and replacing it with ServiceStack. Because WCF is such a pile of shit. If you seriously think WCF is good, and 'trivial' then you're clearly a MS fanboy who've never tried alternatives.
I used to be like you, think WCF was the bee's knees.
WCF promote poor service design, in an untestable manner, has no real support for DI, has terrible configuration, unhelpful exceptions, faults, message size limitations that cause headaches, horrifically slow. The only benefit to WCF is TCP endpoints. End of story.
I used to be like you, think WCF was the bee's knees.
WCF promote poor service design, in an untestable manner, has no real support for DI, has terrible configuration, unhelpful exceptions, faults, message size limitations that cause headaches, horrifically slow. The only benefit to WCF is TCP endpoints. End of story.
Whats funny is in my experience even MS fanboys hate WCF.
;)
;)
you're clearly a MS fanboy
Um...okay. That says enough. End of story.
Um...okay. That says enough. End of story.
I've done my fair share of WCF development, and I can tell you without reservation that it just BLOWS!
I'm glad MSFT is moving away from that.
I'm glad MSFT is moving away from that.
Thanks for your unqualified, unevidenced opinion.
What 'unqualified' and 'unevidenced' opinion?
I have a dozen WCF projects under my belt.
WCF is fine until you need to extend it. Nancy, MVC, Web Api are much easier to extend.
Plus WCF needs all sorts configuration stupidity which alternatives just don't have.
WCF is fine until you need to extend it. Nancy, MVC, Web Api are much easier to extend.
Plus WCF needs all sorts configuration stupidity which alternatives just don't have.
Really? WCF? Really, you're sticking up for WCF?
Yeah but WebAPI sucks :)
I started moving a large API we had built on MVC4 over to using WebAPI 2 beta and the attribute routing is amazing. Nancy looks to have similar conventions as far as routing goes but one thing I just couldn't get working properly was authentication. With WebAPI I found it more intuitive to have [SomeCustomAPIAuthenticationAttribute] on controller class and have it look for either an active session (for our browser javascript ajax calls) or if it has none then for an ApiKey (for our mobile apps) in the post data and look up to make sure the api key is valid.
Nancy is cool and i'd definitely consider using it in the future but for now, it was easier to port over our api from MVC4 to a much more familiar structure.
Nancy is cool and i'd definitely consider using it in the future but for now, it was easier to port over our api from MVC4 to a much more familiar structure.
Nancy uses extension methods in placement of Attributes.
Forms auth is done by calling this.RequiresAuthentication(); you can implement an extension method to do an ApiKey check in about 5 lines of code :)
Forms auth is done by calling this.RequiresAuthentication(); you can implement an extension method to do an ApiKey check in about 5 lines of code :)
Thanks for that! I'll have to play around with it again.
How about a demonstration of something of real-world significance?
- content negotiation (basic building block of hypermedia APIs),
- authentication (and ensure SSL is used when authenticated),
- most importantly, HTTP caching, where
-- unauthenticated users get cached content, authenticated users don't,
-- vary on representation negotiations (media type, encoding, and language),
-- cache is located on server and in browser.
In other words, take basic advantage of HTTP to improve security and performance. Taken together, the requirements listed above comprise a problem of only moderate complexity, and are fundamental to flexible, high performance web apps. Accomplishing it in ASP.NET MVC/Web API is painful and relies on the inconsistent, malfunctioning, horrifically designed ASP.NET response caching module.
Show me a framework that does the above and makes it reasonable to build hypermedia APIs, and you've got yourself a convert.
- content negotiation (basic building block of hypermedia APIs),
- authentication (and ensure SSL is used when authenticated),
- most importantly, HTTP caching, where
-- unauthenticated users get cached content, authenticated users don't,
-- vary on representation negotiations (media type, encoding, and language),
-- cache is located on server and in browser.
In other words, take basic advantage of HTTP to improve security and performance. Taken together, the requirements listed above comprise a problem of only moderate complexity, and are fundamental to flexible, high performance web apps. Accomplishing it in ASP.NET MVC/Web API is painful and relies on the inconsistent, malfunctioning, horrifically designed ASP.NET response caching module.
Show me a framework that does the above and makes it reasonable to build hypermedia APIs, and you've got yourself a convert.
Nancy is cool. Currently trying ServiceStack http://www.servicestack.net/ which is also great at serving up json endpoints.
Agreed, it looks like a promising framework as an alternative to MVC4/5
I don't 'get it': I'm developing
a Web site, my first serious one,
and using the standard Microsoft
software tools Windows, IIS,
Visual Basic .NET, ASP.NET,
ADO.NET, SQL Server, and some of
the rest of .NET, e.g., TCP/IP
sockets.
For entering the code, I am using my favorite (programmable) text editor and believe it is working very well. Otherwise I use some scripts I've written in my favorite scripting language.
To do this development I read through about a cubic foot of books and 4000+ Web pages of documentation, nearly all from Microsoft's Web site.
For the development I struggle some with 'scope of properties' in CSS (which apparently is nearly never discussed) and much of the documentation, but otherwise from the server farm architecture to the computing to be done down to the lines of code and documentation, there are no problems. E.g., for a single Web page, say, X, there is a file X.ASPX, and it has some options, some static HTML and CSS, some 'event handlers', e.g.,
And I don't have even as much as a weak little hollow hint of a tiny clue what MVC is or why I should want or need it. The explanations of just why I should want MVC look to me as burdensome and totally meaningless distinctions and constructions for no good reason. Same for a 'framework'. Same for Nancy and everything else in the OP.
E.g., the OP talks about GET and POST "methods". I don't do those things -- IIS and ASP.NET handle those for me. If I want the actual post data, then it's available to me via some ASP.NET classes. But the code I write doesn't deal very directly with GET or POST.
And have I found no good explanation of why I shouldn't just continue as I am.
I don't have a clue what OP is talking about.
My guess is that MVC, Nancy, etc. are for programmers with backgrounds in Web development on Linux who want to program on Windows and there use programming tools and techniques they used on Linux instead of just the usual Windows IIS, ASP.NET, etc.
I've already read a cubic foot of books and 4000+ Web pages of documentation, and my work is going fine; why should I junk my work to date, read a lot more documentation, involve myself in more overhead of tools instead of just going my real work?
More documentation can have errors; more tools can take me farther from the real data and can have bugs.
Am I doing something seriously wrong?
For entering the code, I am using my favorite (programmable) text editor and believe it is working very well. Otherwise I use some scripts I've written in my favorite scripting language.
To do this development I read through about a cubic foot of books and 4000+ Web pages of documentation, nearly all from Microsoft's Web site.
For the development I struggle some with 'scope of properties' in CSS (which apparently is nearly never discussed) and much of the documentation, but otherwise from the server farm architecture to the computing to be done down to the lines of code and documentation, there are no problems. E.g., for a single Web page, say, X, there is a file X.ASPX, and it has some options, some static HTML and CSS, some 'event handlers', e.g.,
Sub Page_Init
Sub Page_Load
Sub Page_PreRender
Sub Page_Unload
And I don't have even as much as a weak little hollow hint of a tiny clue what MVC is or why I should want or need it. The explanations of just why I should want MVC look to me as burdensome and totally meaningless distinctions and constructions for no good reason. Same for a 'framework'. Same for Nancy and everything else in the OP.
E.g., the OP talks about GET and POST "methods". I don't do those things -- IIS and ASP.NET handle those for me. If I want the actual post data, then it's available to me via some ASP.NET classes. But the code I write doesn't deal very directly with GET or POST.
And have I found no good explanation of why I shouldn't just continue as I am.
I don't have a clue what OP is talking about.
My guess is that MVC, Nancy, etc. are for programmers with backgrounds in Web development on Linux who want to program on Windows and there use programming tools and techniques they used on Linux instead of just the usual Windows IIS, ASP.NET, etc.
I've already read a cubic foot of books and 4000+ Web pages of documentation, and my work is going fine; why should I junk my work to date, read a lot more documentation, involve myself in more overhead of tools instead of just going my real work?
More documentation can have errors; more tools can take me farther from the real data and can have bugs.
Am I doing something seriously wrong?
E.g., the OP talks about GET and POST "methods". I don't do those things -- IIS and ASP.NET handle those for me.
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.
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.
ASP.NET WebForms is absolutely a framework and a heavyweight one. It tries to hide the details of http and html as the grandparent says. I for one don't care for that, I prefer a lighter weight framework which works with http rather than hiding it. ASP MVC is lighter weight than webforms, and Nancy or ServiceStack is even lighter weight.
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.
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.
Thanks. As I wrote above, as far as I
know, I'm not using WebForms and am
just using basic IIS and ASP.NET.
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.
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.
> as far as I know, I'm not using WebForms
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.
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.
Thanks! I needed that!
Thanks for the overview of Dreamweaver: I didn't
know anything about it and wondered. Right,
if it takes me very far from HTML, then I
wouldn't like it. E.g., right, sometimes
when something's not working, I will
just have my Web browser save to a file what my
Web server sends and look at what
was saved. So, some of my badly written
CSS gets
pruned, etc. I've gotten some answers that way.
> 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.".
> 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.".
What on earth is a pull down?
My terminology is likely not correct!
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.
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.
If it works for you (and for your team, if you have or will have one) then you're doing just fine. Many, many ASP.NET developers are wonderfully productive with ASP.NET WebForms and Visual Basic .NET.
That said, I love C#, I like ASP.NET MVC, and I absolutely loathe WebForms and VB.NET. Everything about those technologies feels clunky and wrong-headed to me, as if I have been forced to run a race with my arms strapped to my sides. Having learned about HTTP, HTML, and core JavaScript a long time ago, WebForms seems an awkward, highly annoying abstraction that hides the knobs I want to turn while presenting me with hundreds of different knobs about which I don't want to learn.
While not quite so bad, the syntax of VB.NET fills me with unease... everything seems cleaner, clearer, smarter in C#. VB.NET shouts "the author of this code doesn't really like to write code" in the same way that a Prius announces "the owner of this car doesn't like motorsports."
That said, I love C#, I like ASP.NET MVC, and I absolutely loathe WebForms and VB.NET. Everything about those technologies feels clunky and wrong-headed to me, as if I have been forced to run a race with my arms strapped to my sides. Having learned about HTTP, HTML, and core JavaScript a long time ago, WebForms seems an awkward, highly annoying abstraction that hides the knobs I want to turn while presenting me with hundreds of different knobs about which I don't want to learn.
While not quite so bad, the syntax of VB.NET fills me with unease... everything seems cleaner, clearer, smarter in C#. VB.NET shouts "the author of this code doesn't really like to write code" in the same way that a Prius announces "the owner of this car doesn't like motorsports."
I don't think I'm using WebForms. If so,
then so far I'm not doing anything clunky.
E.g., I'm not using anything like a
calendar control.
> presenting me with hundreds of different knobs about which I don't want to learn
I certainly haven't been using lots of such knobs. Nearly everything I do in VB.NET and ASP.NET is obviously quite close to really simple HTML and CSS.
As far as I can tell, C# and VB.NET are equivalent ways, different essentially only in syntactic sugar, to get to the basic .NET classes and common language runtime (CLR). C# seems to want to borrow from the especially succinct syntax of C/C++ which I don't like. I prefer the more verbose syntax from the history of Fortran, Basic, PL/I, etc.
> presenting me with hundreds of different knobs about which I don't want to learn
I certainly haven't been using lots of such knobs. Nearly everything I do in VB.NET and ASP.NET is obviously quite close to really simple HTML and CSS.
As far as I can tell, C# and VB.NET are equivalent ways, different essentially only in syntactic sugar, to get to the basic .NET classes and common language runtime (CLR). C# seems to want to borrow from the especially succinct syntax of C/C++ which I don't like. I prefer the more verbose syntax from the history of Fortran, Basic, PL/I, etc.
Was this meant as a troll comment? Seems like it to me. Where does one even start responding to this?
No. Take it literally, at face value.
E.g., I have essentially no idea what MVC is, what it's for, why one should use it, etc. Similarly for WebForms. Then similarly for Nancy, etc.
So far, my Web pages work fine.
E.g., I have essentially no idea what MVC is, what it's for, why one should use it, etc. Similarly for WebForms. Then similarly for Nancy, etc.
So far, my Web pages work fine.