I Love My Work, but I Hate Web Development

The more I work on web development, the more I realise how much I hate it. This is a very strange situation, especially because I do really love my work; I just hate the way I have to do it.

Let me explain what I mean. I hope that by the end of this long read you get the idea that I’m setting to communicate here, and that you join me on my rebellion against web development as it is today.

I will start with an example. Imagine a world where there are no computers, or typewriters, or even paper. All you have is rock and hard tools to scribe your thoughts. In this world there is a very high demand for books, which are made out of stone and cannot be mass-produced easily. You are a fiction writer. People love your books, and you love writing them. Except, that you hate having to write them.

It is not the idea of creating content that you hate, or the motion of writing itself, but rather the fact that it takes you a very long time to put those books on stone because of the rudimentary tools that you have. This is precisely what I mean in the title.

It is not the idea of creating an awesome website or webapp that I hate, but rather the nuisance that it represents actually creating them with the set of rudimentary technology that we have available. Even more annoying is the fact that not only do we have to use a very basic set of tools, but we also need to support even more archaic tools. And to add insult to injury, we are supposed to obey by a set of rules that have been laid out by people who mostly do not understand the web of today. Let along that one of tomorrow, which we should have gotten yesterday.

The more I work on web, the more I realise how wrong it feels to do it. It really feels wrong to have to create my content using a limited set of tags that were thought of by people who knew nothing about what I’m trying to create, and who would probably never care. It feels wrong to have to use an API that is mostly redundant (DOM), and designed by people whose work is not to create with this API. It feels wrong to have to do the same thing more than once to make sure that it works across browsers and platforms. I’m sure that by now you are getting the idea.

This is why Ajax libraries have succeeded. Ajax libraries are created, maintained, pushed, shaped, and refined by content creators, not by specification-and-standards writers. The people behind jQuery, Dojo, MooTools, YUI, and many others, are people who have created these tools to solve problems they have encountered in their journey as web and application developers. We need more of this, and less of W3C nonsense.

I used to be standards oriented until I discovered that the people behind the standards have no idea of what they are doing. Don’t get me wrong here. I have a lot of respect for the people who set out to standardise a huge mess such as the web. It is just that they have spent too much time trying that they haven’t realised the web changed.

The best time machine mankind has invented is called webstandards. While reading some of them, and not only web standards, one can feel like it’s re-living 2000 all over again. And it’s scary because sometimes you are actually reading a year-2000 document. This is insane. You cannot standardise the web of today when your base for standards is the web of 2000.

There are many examples of things that should have been done differently. One of the most common case-scenarios that frustrates me is CSS. In my opinion, and I express it because this is a very subjective essay, CSS is wrong. It starts with classes, then it degrades with some aspects of selectors, especially how they are interpreted, and it hits the bottom with the syntax passing for some other stages in the process.

The idea of classes is a language that has no way of extending this classes is wrong. One can argue that you can extend a class by adding the class name that you want to extend to the CSS declaration of the object from which you want to extend, like this:

.car{
color: blue;
width: 200px;
height: 50px;
}

If we want to create a new element that has the class name of truck, and we want it to extend the CSS of car, we can do it like this:

.car, .truck{
color: blue;
width: 200px;
height: 50px;
}
.truck{
width: 300px;
}

This is fairly simple, but not quite usable when working on real projects because most of the time, by the moment you reach truck, you already added a hundred lines under the .car declaration. You have two options. One is to move your .truck declaration 100 lines up and mess up your CSS file organisation. The other is to leave them both 100 lines apart from each other which is also not good because the it becomes a maintenance problem, which by the way the first option does too.

Moreover, this is not extending, it is merely subscribing two classes to the same set of rules. Subscriptions are good, but not as the base for extending classes.

How I think it should be done:

.car{
color: blue;
width: 200px;
height: 50px;
}
/*100 lines of code go here.*/
.truck extends .car{
width: 300px;
}

What is the big difference? you might ask. This option also has the problem of having both declarations 100 lines apart from each other. However, in this version, there is a clear way to know that the styles that you see for .truck are not the only ones affecting .truck, where as in the current way of doing so, there in no such visual cue.

The whole idea of classes is wrong in most programming languages, but that is material for a whole other essay.

There are many ideas that have been laid out to solve the many issues of CSS, two that come to mind are OOCSS, and Stylus. Both are worth a look.

CSS is not a programming language. Rather, it is a styling language, which was good enough for when the web was a bunch of static documents. It even made sense when the webapps where things like forums, blogs, and e-papers. Today we need a styling language that borrows ideas from programming languages. One feature that would be a first good step in the right direction is adding variables to the language, and arithmetic capabilities. Stylus implements these ideas.

CSS is a styling language, but we need it to become a state representation language. The web of today is state based, and CSS doesn’t do well in this area. Moreover, we need it to be an animation language. So far Javascript has done that job, but CSS has demonstrated that it has potential to do it to.

Another reason why I hate web development is HTML. There is a lot of excitement about HTML5, which is good, but there are fundamental flaws in the design of HTML that just make the language not suitable for the web. There are, for example, security issues with window. This could be thought of as a problem with javascript, but it is not. Javascript has no window, that is an HTML global variable. Javascript has a global object, and window refers back to that global object, but window is not part of Javascript, it is the global object implementation in HTML. HTML5 does nothing to solve this issue. Instead, it adds more complexity to a system that is in itself complex, and complexity is the first enemy of security. But there are more fundamental problems with HTML.

HTML is a very closed language. HTML has a defined set of tags. This tags have a define behaviour, and you cannot expand this tags. Technically you can, but at some point you will run into trouble. There is no way to create semantically meaningful markup with the language that we have today. This can be argued, of course, but the truth is that HTML is too small to cover the needs of developers today. In order to create meaningful markup you need to use classes, and IDs, and this becomes a problem when you are creating webapps.

Once I said that HTML5 was built for blogs. The new additions to HTML that conform the HTML5 specification has a clear influence from the blogging community. They wanted an article tag, an aside tag, a section tag, a header tag, a footer tag and all of the rest because that is what they need. If you get together with blog designers, all they talk about is content, footer, sidebars and sections. We cannot build the web on top of blogging engines.

We need a language that allows us to specify more than just content sections; we need to be able to specify UI elements other than input boxes and buttons. There are some new elements that allows us to do this, like some new form elements that promise a brighter future, but it is not enough. We should have gotten those back when the talks about web 2.0 were all over the web.

HTML is just not suited for web development today.

It seems that from the stack (HTML, CSS, and Javascript), the only language being pushed in the right direction is Javascript (actually Ecmascript). This is a good thing.

Finally, the DOM is a mess. When people say the hate Javascript, the usually mean this:

var a = document.getElementById(‘myID’);
var b = document.createElement(‘span’);
b.appendChild(document.createTextNode(‘My text’);
a.appendChild(b);

I look at them and say, please step back from the computer and read a book. That is not Javascript. What you are seeing right there, that mess is the DOM’s API.

The DOM has many design issues that are beyond my willingness to explain them. The one thing you should know about it is that it was poorly design and it’s an awful thing with which to work. It is ridiculously repetitive and has horrible method names. Don’t let people fool you into thinking that is the way to write methods, because it is not.

There are many other reasons to hate web development, like the one we call IE*, but I think you get the idea.

There are two things that need to happen for web development to really advance. The first is we need to rethink HTML and CSS, and the second is getting rid of browsers that are holding back web development. Until this happens, we will be living in a world with a wasted web.

*IE is getting better, but that is of no use when the older version stick around for too long like they do.

About these ads

8 thoughts on “I Love My Work, but I Hate Web Development

  1. How right you are, pal! All this mess HTML+CSS+DOM+JavaScript just slows down development, without capturing the main needs of web developers. My understanding is a simple unique layout programming language would have been better than this weird and casual combination of languages.

    Any good web developer could easily design something better than W3C standards. Moreover a real standard should specify everything to the nitty-gritty details so to have true portability.

    We also need a namespaced language that makes it easy to modularize code. CSS is not namespaced, you could use prefixes, but once you start nesting namespaces your identifiers become awfully long. Namespacing JavaScript or HTML code is tricky and unsupported too. Namespaces are very important for reusing pieces of code made by other programmers without having to worry about name clashes and side-effects.

    As you pointed out HTML, even HTML5 has poor structuring features and no way to attach semantics at all. Whatdid they do in 20 years to improve this situation? Almost nothing and a lot of failures like RDF and XML.

    XML was a big mistake… people don’t want to structure all the information, but only a significant portion of it. Name a well-known site like Amazon made using XML technologies. I bet you cannot find one. RDF is not that bad, but who uses it as well? Semantic features must be embedded in the web core language for people to use them.

    AJAX is no better than traditional tricks either. When using AJAX any application state is lost and cannot be bookmarked. The ideal would be to be able to write web apps without having to face the same client-server complications over and over.

    And to round off this tirade, tags are awful and rudimentary way to structure a text. If you only have a few of them laying about, this is not a problem, but we cannot get along with a few tags only anymore as it was HTML 2.0 . This verbose SGML-like syntax makes web pages very hard to read and edit. LISP programs are much better compared to HTML sources.

    HTML/JavaScript “programs” are rather monolithic. There is no easy way to split the code among multiple files so that you cannot see the overall structure by looking at the main file, missing the forest for the trees.

    • You definitely understand my dilemma. I think that we need real developers designing the language, because only then will we get a better option. The current stack is just too old, and trying to patch it will only make it worst. We need a fresh approach. But in the meantime, we need to do with what we have. I’m planning on writing some articles on modular development to achieve some separation in the stuff we build.

      Stay tuned :D, and thanks for your amazing contribution.

  2. Thanks for sharing with the WWW. This article is insightful. You pointed out some fundamental flaws.

    Cross-browser compatibility and restrictions are my two biggest gripes in web development. Even with HTML5, the same challenges are encountered when using some of the newer tags introduced. It makes for a real nightmare. It seems like no matter what choice of source code or feature is chosen (e.g. Local Storage vs IndexedDB vs Web SQL), it seems that one or more browsers will not support it. While on the subject of IndexedDB vs Web SQL, it appears from reading the background between the two that politics may have been involved in Web SQL no longer being supported.

    • I ignore the history of Web SQL, but it would sure be interesting to read more about it. I think most developers share this opinion on the burdens of developing for the web. Fortunately, as browser vendors continue to improve and agree on the standards, it seems that we can hope for a better future in web development.

Comments are closed.