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:
- Is it important to continue supporting both programmers and non-programmers?
- Can we have a single, unified model that supports both at once?
- 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!
- 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.