Why I think “The Web Will Die When OOP Dies” from Zed Shaw is a pure bullshit talk

I recently came across a video from the so-called Web Rebels arguing the Web Stack is a gigantic piece of crap we need to throw out completely in order to build something new.

When I saw that video, I really became upset, because it seems to me Zed is trying to get attention by mostly reporting problems whose solution already have been found and whose implementation in today’s browsers is a work in progress.

Comparing yesterday features with today needs is something that’s completely unfair, because it’s completely impossible to predict what features we will need tomorrow; we can make some guesses but we can’t expect things to be perfect at the time we’ll need them.

The important feature of a language is not is ability to cover the future needs before they arise, but to cover them as they arise. And I’m going to point out how the problems reported by Zed are actually already being solved by browser vendors and why I really think the whole presentation is not worth much consideration.

W3C’s vaudeville

The first part of Zed’s talk was about saying how bad he felt about the W3C technologies. Firstly, I think he’s profoundly wrong when he says the W3C stack is a piece of crap.

The fact is that the W3C tried to define ahead of time how things should be done by developers. This was a risky bet, but the W3C has been giving directions to web programmers for years. His role was to promote an ideal, even if that ideal was not easy to accomplish in real life.

It’s natural that, as time progress, the technologies that once were seen as best-of-class by the W3C people of the time are being replaced by new technologies. The thing that matters is not the syntax of the used technology itself; what matters is that the philosophy of the web stack as defined by W3C is actually the one used today. The technologies are not the one the W3C thought to be successful, but we built a stack using the principles defined by the W3C, using other, more convenient technologies.

The major problem of the W3C languages is the verbosity; the *ML syntax is simply too redundant. No wonder why SOAP/XML web services are slowly being replaced by REST/JSON one. JSON is simply a much better way to represent information than XML is. In a way, XML is doomed.

Thinking that the people at W3C are unaware of this is, however, a big mistake. In the previous years, I came across blog posts from people working inside the W3C stating that, yes, XML is doomed. Yet, everybody still develops specifications in *ML, because *ML is supported by every browser out there. *ML works; *ML may be doomed, but *ML works. That’s the point.

For the W3C perspective, it is better to extend the possibilities of the web by adding new APIs than to work on some new syntax which may take years to succeed. That task is better left to disruptive organizations, with less need to make compromises, more flexibility and freedom than W3C and which are free to make transpillers (Moblang is a nice example of what I think can be the web of the future).

When such syntax succeeds, it is going to be standardized. There will be no need to transpil it to HTML anymore. In between, innovations will need to be transpilled or shimmed, because working with today browsers requires this. There’s just no way to change that.

It’s to be understood that W3C role is not to innovate, but rather to acknowledge that the outside world changed and that a new API has been used in the wild for a while thanks to shims, and it’s now time to support it natively.

Between the time a problem is detected and solved by a shim and the time a standards emerge to solve the same problem, expect a certain amount of years to elapse. There just no other way to do things right than to take time. Getting every software company onboard and okay with a proposal takes time. Implementing something right takes time.

If I can conclude this section with something positive, I would like to say that the W3C’s dream was to have websites sending raw data as XML, and allowing the clients to transform them to HTML thanks to XSL. Today, we are sending raw data as JSON, and transforming them on the client to HTML thanks to JS. People which are failing to see how W3C dreams have concretized here are strongly recommended to buy new glasses.

CSS is not a barely working technology

When I saw that CSS was included in the things that didn’t work well by Zed, I got even more upset. CSS is probably the best piece of technology ever maintained by the W3C.

Finding anything that doesn’t work because of CSS core syntax is nearly impossible. CSS is one of the most intuitive element-matching systems I ever used. It trounces XPath or XAML in simplicity; and no programming language will ever be able to reach the efficiency of the CSS selectors. CSS made easy something that was thought to be complex: matching elements in a tree.

Anyway, I’ll have more time to cover this later on, because Zed gave some explanation of why he thought that CSS was bad further in the discussion.

However, the whole 'upload' thing is very interesting. When he speaks about uploads, he states that, in fact, that problem has been solved, and nobody know it. In fact, his whole presentation talks about problems that already have been solved. It’s like if Zed watched all the innovations that have been or will be included in browsers in a 6 month period of time, and decided to criticize the web stack based on the issues that those innovations are going to solve.

Uploads is an example, we’ll see more and more of them in the coming paragraphs.

Sugar is fine, but I just want something that works (for now)

Well, how can’t we agree here? CANVAS lacks a way to do one of the simplest things ever in a simple way.

I’m not going to say that this is a feature. This is clearly a lack of feature. However, I would like to point out that each function that is added to a W3C specification has be to be implemented by dozens of company worldwide.

It has been proven that long, complex specifications are error-prone and takes longer to be implemented by every browser vendor. I prefer to have ten features from which I can build everything I need than a lot of sugar that doesn’t work in all browsers, and where we ends up in a situation where it’s impossible to do what we want because the least common denominator between all browsers doesn’t include all the features I need.

JavaScript is one of the best languages in the world in the sense I can add all the functions I need to an object’s prototype, even after it has been specified. If you really need a context.drawCircle(x,y,radius) function, it’s easy to add it to every context out there.

Thanks God, with CANVAS, we have a fully working API which is vastly interoperable, and I can use the shims I want to build the stuff I need. Using an external API (like popcorn.js) is not a bug, it’s a feature. I can define the functions I want, the way I want.

There’s nothing wrong with it, as long as people are ready to build them.

Hey, HTML is generated client-side, too!

This is why Twitter, Facebook and so many others are generating their HTML client-side. Did AJAX mean anything to Zed, or is he just trying to troll me on this sentence?

Anyway, here are some answers to some of Zed’s questions:

• Yes. Try out Microsoft Expession Studio, Adobe AIR or BlueGriffon. The solutions are here; maybe you just need searching them instead of fucking everything you see.

• No. In-Browser technology is not able to evolve quickly enough to allow that the right way. I guess using a framework is going to be the solution for years to come.

• Not a web-related problem. W3C could not do anything to make H264 free.

• Some browsers like IE already have that. It’s a known issue that some other browsers like Chrome don’t. Sorry, W3C can’t solve that either. File bugs.

• Yes. This is called CDATA. Read The Fucking Documentation?

• Implemented in IE for years. I’m still wondering why other browsers failed to implement it after so much time. I’m with you on this, this HAS to be specced.

• Why not. Just propose a spec. W3C is seeking spec editors.

Read The Fucking Specification

At some point, I think I’ll just stop commenting all the shit he says. Just read the spec, or shut up.

- http://www.w3.org/TR/css3-grid/

- http://dev.w3.org/csswg/css3-align/

- http://www.w3.org/TR/css-variables/
- How do this belongs to CSS?
- See previous response. IE already supports that.

- Yes, JavaScript's "==" sucks. Deal with it.

- This is false. Browsers supports Integers, you just don’t have to worry about it. Browsers see at compile time if you use a float or an int. Isn’t that a nice feature?

- http://msdn.microsoft.com/en-us/library/br212485(v=VS.94).aspx
+ http://www.w3.org/TR/FileAPI/

- Because nobody wanted to support VBScript, and nobody proposed another language than JavaScript at the time. HTML has been crafted to support multiple languages; it’s just that nobody wanted them. If things have changed, we can add new languages, I think nobody is against that. However, political reasons make that complex. I would love to use CIL as a web compile target; it has implementations for Windows, Mac and Linux. But I’m afraid it won’t happen.

About politics and backroom deals

We see the same difficulty. That’s nice. So, what are you proposing?

About Object-Oriented Programming

Okay, we’re done with web. This is what mattered to me. However, just for the sake of completeness, I’m also going to comment the part on Object Oriented Programming.

I don’t see why OOP is bizarre. This is exactly the way we think, every day of our life. We resonate in terms of objects and it works pretty well. I see a car, a motor, a wheel. I can resonate about that. A wheel can turn, a motor can convert energy, and a car can advance. This all seems fairly logical to me.

For years, we know that every particle in this universe is a probability wave: we can’t know where they are located exactly nor how fast they are moving nor how much energy they have. This hasn’t prevented us to build solid models just using a simple, object-based representation of the world when it was best suited: we don’t need anything complex to know when a thrown ball subject to the gravity will be hitting the ground. There are still scenarios where it isn’t suited. That’s fine; we just use something else in those cases.

I will not give you a course on models here; there are a ton of other pretty good engineers all around the world who could speak you about it for hours.

However, it seems pretty strange to me that Zed is bashing one of the few non-OOP programming language in the world (JavaScript) while saying that OOP is trash we should eradicate at the same time. I just don’t get it.

But maybe, for Zed, saying that something is rubbish is just a way to say he like it, I don’t know.

Concluding my review

To conclude this review, I would like to note that the primary goal of this talk was most probably to get known or, at least, to shock people. I think I have demonstrated in my review that most of the problems outlined by Zed have already been solved, and that we’re just waiting for their implementation in all browsers at this time.

You can’t expect from the most implemented set of specifications of the world to evolve at the speed of light; you can choose the model you want, you’ll still have to wait to get things done. Working is taking time, and this is not news.

What’s so beautiful about the web stack is his extensibility. This extensibility can be extended further, I agree, but saying that it’s all bullshit is an overstatement I frankly can’t agree with.

When I was young, I was told that it’s the one who says everyone else is bullshit that’s actually the true bullshit. I think I got the point, now.