Corruption and Degradation in WebGL (revised)

This review was written about a week ago when I was first into my learning curve of javascript, html, dom and webGL.  Well, its a week later and I think that what I was really responding to is / was different than what I thought it was.   Its not about WebGL, its about expectations.   See note at the end of the post.

This is a review on the process of learning Javascript and WebGL. The two are very interconnected and we will start with Javascript and then move to WebGL.

Note, I am not far enough along to have a real opinion about how well WebGL works, because I am spending all my time getting through the learning curve of getting a picture up on the screen. It shows promise, when things work it almost seems magical.

But when you first are learning WebGL you have to get through Javascript so we will start there.

Although Javascript is a little weird, it does grow on you, and there are clever even possibly reasonable solutions to various flaws in the language which, once you get used to their weird syntax, seem to be OK. For example, I am using a variation on the "module" pattern in Javascript and it seems to be working out for me in terms of hiding and keeping internal state of various parts of the program. Furthermore, javascript reminds me a bit of Lisp in its devil-may-care attitude to dynamic memory and its JSON equivalent of an S-Expression. Although initially dealing with Javascript is a problem, in time the problems fade into the background.

The problem is that learning Javascript is something of a pain in the ass, and for the following reasons:

1. Javascript has a specification and a bunch of tutorials, but no serious reference manual or best practices documentation. You are expected to get all that "out on the Internet". Ha.

2. The problem is that each of these tutorials is written by a different person with wildly different skill sets, styles and talent. They are not Kernighan and Ritchie. They are not comprehensive. They are occasionally helpful, they are more often then not incomplete or inaccurate. They are in no way a substitute for a good reference manual.

3. Each of these tutorials by helpful unpaid volunteers uses a different style, and a different set of support packages, all of which are completely incompatible with each other. There is no equivalent to "stdio" in Javascript. One person uses Ajax, another uses Jquery, still another uses something else. These different packages all seem to be useful, ad hoc, mutually incompatible and of wildly varying quality and utility.

4. Learning Javascript is usually intertwined with learning some combination of DOM and HTML, each of which exists in its own versions, varying implementations, and without documentation. Repeat problems of learning Javascript for each of these.

5. Unless you have someone with the knowledge and the time to guide you through this morass, you can count on a very frustrating period and a very time-inefficient process. Its nothing that anyone involved should be proud of. Just because they made a billion dollars at it, does not mean that they did a good job.

But the good news is that, so far at least, in conjunction with a nearly Lisp-like level of interactivity, one can pretty quickly get through the learning curve and onto whatever it is you wanted to do with the language.

But then you get to WebGL and you run into a series of problems which are very related to the ones just mentioned but with a few additional ones to make it all better. Not only is there no reference manual, nor anything close to minimally acceptable reference documentation (a specification is not a reference manual, by the way), but one more time we have the morass of internet tutorials that vary from useful to not, and each of them uses their own support packages for matrix operations and so forth.

But unlike Javascript, with WebGL and all modern graphics APIs, you have to do an awful lot correctly before you can put a cube on the screen. And if you do one of those 30 or 40 things incorrectly, then you will not see a cube on the screen. But each of those 30 or 40 things is badly documented since there is no reference manual, so you are reliant on Internet based tutorials which brings us full-circle on the discussion.

The only way I have found to proceed is to divide and conquer. Which is to work your way through the creation of a working program one module and WebGL call at a time, reverse engineer what the documentation should have been, and then move on.

That takes time.

I am not all that impressed, to tell you the truth.

So now it is a week or so since I wrote the above post.  And I think I was being a little harsh.  Once you get through the learning curve, and get a handle on what documentation that there is, one can become productive.  There are still unsolved riddles but I am able to move around them.   I think that the real problem here, however badly expressed, is one of incorrect expectations.  I expected things to be better, for us to go forward with the best, and not to have to deal with things that are no better designed or documented than what we had 20 years ago.   It is perhaps a let down that we have not come very far in certain ways and that is what I think I was expressing above, without knowing it.  As for the rest, Html, Dom, and even WebGL is fine, if a little weird now and then.