
Ask HN: Dumbing down the Web with frameworks and abstractions - nopal
I posted a question/rant over on Reddit, and I'd be curious to get the perspective of some HNers.<p>In summary, do too many Web developers lack a fundamental understanding of underpinnings of the Web?<p>http://www.reddit.com/r/programming/comments/b1apt/dumbing_down_the_web_with_frameworks_and/<p>--------------------------------------------------<p>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.<p>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.<p>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.<p>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:<p>* TCP/IP<p>* HTTP<p>* TLS/SSL<p>In addition, Web developers should have expert knowledge of:<p>* CSS<p>* JavaScript<p>* HTML<p>Developers don't need to be subject-matter experts on these, but they should <i>have a fundamental understanding</i> of these protocols and should be able to <i>translate a framework's abstraction into a core protocol</i>.<p>Some of the issues I've encountered due to a lack of fundamental understanding:<p>* 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).<p>* 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.<p>* 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.<p>* 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.<p>* 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.<p>* HTTP response types -- Is your framework sending 301s when it should be sending 302s?<p>* 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.<p>* 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?<p>* 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.<p>* 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).<p>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.<p>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.<p>As I said before, frameworks are great, but developers need to understand them at a fundamental level.<p>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.<p>How do we ensure that future Web developers take the time to understand their tools and the core technologies that power them?<p>--------------------------------------------------
======
RiderOfGiraffes
Isn't this the same as saying that you shouldn't program in Haskell, Erlang,
Lisp or Prolog without also being able to program in assembler? And isn't that
then the same as saying that you should be able to design circuits with NAND
gates? And doesn't it go on to say that you should understand how diffusion
processes are used to make integrated circuits?

Actually, I'm with you, but the question is: where do you stop, and why?
Personally I've build a CPU from an FPGA, and before that I designed a CPU
from NAND gates. Even so, I wouldn't insist that my applications programmers
know how to do that. C is useful, assembler also, but I wouldn't insist on it,
and even those who only know C++ or Python are still productive programmers.

~~~
nopal
I think you raise a very good question.

I hadn't explicitly considered it before, as I was writing from my feelings on
what a Web developer should know. Let me try to define my cut off.

It's not where the abstraction stops, because TCP/IP/SSL aren't part of the
average Web framework (maybe some provide their own server, but I'm not aware
of any), but it definitely includes everything the abstraction for framework
does.

Is it abstraction + 1 level? Maybe.

I have a feeling different languages and areas have different cut-off points
-- Web dev differs from Erlang dev.

For the Web, I think the cut-off point is TCP/IP because it is so central to
the way the whole thing works, but is not too technical to be hard for the
average developer to understand. As far as SSL/TLS is concerned, I provide a
specific example of when an understanding of SSL is needed.

There are reasons go deeper
([http://developer.yahoo.net/blog/archives/2009/10/a_engineers...](http://developer.yahoo.net/blog/archives/2009/10/a_engineers_gui.html)
talks about Ethernet frames and payload sizes), but I think an understanding
of TCP/IP and the encapsulation they implement will allow a knowledgeable Web
developer to understand the technical details.

I don't think there's any place to stop, necessarily, and I think these
discussions are useful because they help to shape what we define as important
knowledge. So, while I may not have a concrete answer to your question, I
think we have a good starting point at which to draw the line.

