Ask HN: Dumbing down the Web with frameworks and abstractions

In summary, do too many Web developers lack a fundamental understanding of underpinnings of the Web?

http://www.reddit.com/r/programming/comments/b1apt/dumbing_down_the_web_with_frameworks_and/

--------------------------------------------------

Over the past few years, I've had the opportunity to work with many different Web-centric frameworks, and I've found them a great aid in boosting my productivity. I've used CSS, JavaScript and programming frameworks such as Blueprint CSS, jQuery, Django, ASP.NET, ASP.NET MVC.

Over the past year, I've been able to introduce several traditional ASP.NET developers to ASP.NET MVC, Blueprint and jQuery. I've been surprised at the lack of fundamental knowledge of how the Web works, and how this lack of knowledge has proven an obstacle for adopting these new technologies.

Before I start my rant, I want to say that these are intelligent, talented developers and that this situation isn't unique to those who grew up on ASP.NET.

So what do I mean by a lack of fundamental knowledge? In my mind, ever Web developer (programmer) should have knowledge of the [suite of protocols](http://en.wikipedia.org/wiki/Internet_Protocol_Suite) that currently make up the Web:

* TCP/IP

* HTTP

* TLS/SSL

In addition, Web developers should have expert knowledge of:

* CSS

* JavaScript

* HTML

Developers don't need to be subject-matter experts on these, but they should have a fundamental understanding of these protocols and should be able to translate a framework's abstraction into a core protocol.

Some of the issues I've encountered due to a lack of fundamental understanding:

* Ajax -- Developers who have used ASP.NET AJAX have no concept of the HTTP requests that are going on behind the scenes. To them, ASP.NET AJAX removes a "page flicker" (a POST request to the current page, which re-fetches the content).

* Stateless nature of HTTP -- This may be particularly bad with ASP.NET. [Viewstate](http://en.wikipedia.org/wiki/ASP.NET#View_state) can be very confusing, and trying to reconcile how it works with how HTTP itself works is a challenge. Unfortunately, many developers never take the time to understand it fully, and it becomes part of the way they think the Web works.

* HTML/Stateless nature -- (ASP.NET's Page Life Cycle)[http://msdn.microsoft.com/en-us/library/ms178472.aspx] is insane. It was meant to make the Web bahave like a Windows application, and is the fundamental abstraction in traditional ASP.NET. I can't even begin to tell you how much fundamental work is done on the behalf of the developer, and how easy it is for the developer to code without any understanding of what's going between the browser and the server.

* HTTP headers and caching -- Most of the frameworks I've seen provide easy ways to alter HTTP response headers, but few of the developers I know take the time to inspect what the framework is sending on their behalf. A lack of understanding (in general, or of the importance of controlling caching) also leads developers to let their Web server send default HTTP headers.

* HTTP verbs -- Communicating with a RESTful Web service using the different HTTP verbs (let alone building such a service) is (at best) confusing to developers who don't understand HTTP. On a related note SOAP, WSDLs and generated code hide so much from developers that many think calling a Web service is the same as calling a local method.

* HTTP response types -- Is your framework sending 301s when it should be sending 302s?

* SSL -- I recently had a discussion with a co-developer about why a server couldn't perform a redirect to a valid SSL-secured domain (SSL cert CN/SAN matches URL) from an SSL-secured domain that had an invalid certificate. (Think redirecting from https://reddit.com to https://www.reddit.com when you only have the cert for www.reddit.com) The argument I faced was that the Web server redirects the browser "before any request is returned." There was ...