*Web* Developers vs Web *Developers*


I’m not trying to make the distinction a hierarchical one.  There is a whole spectrum of equally valid web developers.  Some come from a software engineering background and work mostly on the server, some don’t know much about programming, but they are whiz-tastic at crafting semantic markup and css.  Don’t forget the thousands of n00bs, the WYSIWYG users, and everything in between.  The web is for everyone. That is one of the most important aspects of the Open Web.


Let’s just break things down for the sake of a simplified discussion. The people developing for the web (whether it be sites, applications, or something in between) either have a background in programming or they don’t.  Looking at the origins of the Open Web technologies, specifically HTML, it was intended as a way of formatting and linking documents in a very simple way. No programming experience needed. As that changed, web technologies became more complex and programmers were needed.

So, following logic:

  1. Is it important to continue supporting both programmers and non-programmers?
  2. Can we have a single, unified model that supports both at once?
  3. If we had to choose a group as the highest priority, which would it be?

sigh – ok let’s give it a shot.  Yes. Hopefully. The programmer group (don’t hurt me).  Basically, my argument would be this – you can’t squeeze blood from a stone.


Lets say there is a set of functionality available to language X. [When I say language, I mean its syntax, but also its libraries and system apis.] X is tedious to work with, but represents all possible functionality.

Y is a language built on X that can accomplish 90% of what X can do, but in a way that is much easier to work with.  It still takes a trained user to work with Y, but they can get a lot accomplished.

Finally, language Z is a domain specific language built on Y that is simplified for a specific use that takes very little training to use. It is a lot more forgiving to its users, and while it can only accomplish 20% of what Y can do, it can do 80% of what the users can possibly want.

I’m sure you already picked up on what I’m putting down, but I’ll elaborate anyway.  XYZ is a process that happens all over the place with great success.  In fact, all modern computing is built on this very process. Machine instructions are like X.  Anything the computer does must eventually boil down to it.  But we build abstraction layers on top of it because its the only way to build scaleable software. Then we add more layers as it makes sense.  One important thing to remember, though, is that you always build on any layer.  In the example, Z built on Y and Y built on X, but maybe language W also builds on X.  Maybe W has a different idea of what would be the important 90%, and what the syntax should look like.  Maybe T, U, and V are all small languages like Z, but they just want to cover a different 20%.  The problem is, it’s very hard to reverse the order and build Y on top of Z instead of Z on top of Y.

Enough letters already!

I know, sorry.  Let’s apply this logic to the Open Web.  Right now, the basic building blocks that we have available are HTML, CSS, and JavaScript.  These were all built with the end user in mind. At the time of creation, the end user was not software engineers, and the purpose was documents, not applications.  I guess what I’m trying to say is that right now, we might be trying to build Y on top of Z.  Throw in a lot of workarounds and hacks and we’re getting there, but there’s just no substitution for a more solid foundation.  I will present just a couple of examples.

  1. Security.  I cannot stress this one enough. We need to be ready for secure mashups. They are coming and they are important. Having a global space is a big problem.  Not just javascript objects, but also the DOM.  And the DOM is not very secure.  We need the foundation to ALLOW better security.  Even if the higher level opts not to use it, if it is impossible to achieve at the base level, it is impossible to achieve at a higher level.
  2. That damned file input! This is exactly the kind of constraint that is still worked around through hacks, but it seriously needs improvement.  The point is, without lower level control, there is nothing you can really do about it.
I’m going to end the post here.  These thought are stewing around in my brain, and I’ll post something else when the they’ve simmered long enough.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: