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 no understanding of the SSL handshake or the fact that the redirect would have to come in the form of a response over SSL.
* HTML -- What is your framework generating for you? Is it eschewing standard HTML submit buttons in favor of images initiating a submit via JavaScript? Is this okay?
* HTML/HTTP -- A datagrid is not an HTML element. The developer should be able to build it by hand and should understand how a datagrid handles interaction and how it manages state. They should be able to build it themselves without any framework-specific help.
* CSS -- A framework like Blueprint isn't magical; its grid is simply a predefined series of classes of specific widths. If you're using a CSS framework, you should be able to build your own (even if it may not look as pretty).
These are but a few of the areas of confusion that I've encountered. As we move to ASP.NET MVC, we've been more exposed to the underpinnings of the Web, and in my opinion, that's a good thing.
I'd like to add that how a framework explains its inner workings has a lot to do with how much a developer can understand without firing up Wireshark. In my experience, ASP.NET has a particularly poor body of fundamental explanations. Microsoft does a poor job of explaining what's happening at a low level, and that permeates the community.
As I said before, frameworks are great, but developers need to understand them at a fundamental level.
I try to make an effort to fully understand the tools I'm using, but how many others do. I'm sure the percentage of those that do is higher here on reddit, but I wonder how high the percentage is in the real world.
How do we ensure that future Web developers take the time to understand their tools and the core technologies that power them?
--------------------------------------------------