Markup is dead!
Recently I have been working on run-time adaptive widgets. Why? I've invested heavily in the Dojo Toolkit. The widget department of Dojo is all about singular, static widgets, which can be used like JavaFX, for example. They are fine for building desktop-like GUIs but, you guessed it, terrible for the mobile web. Sometimes we want a horizontal menu to be displayed vertically. I did search the web for other solutions, but they all seem to be markup-based in some way. These are great times for HTML5 and CSS3. That's what the buzz is all about. But I don't like it all that much. Writing markup is tedious and not DRY, platforms creating it are opaque and too specialist. I'd rather spend some time figuring out the best way to go about it. However, building a competitive tool from scratch has never been my forte. So I desperately cling to my current tool set (as we all do). I was going to set out creating stuff in Dojo, as I always do. Then this video came along:
http://fronteers.nl/congres/
Suddenly – and any web developer watching it will feel the same – my javascript house of cards came tumbling down. This guy really has a point! We invested so much in javascript mainly because the HTML tool set is not complete, and probably never will be. We develop our apps (yes, my body tag is empty too), because "IE8 cannot do that", or HTML is not semantically rich enough to declare my beautiful smart widget... Maybe if we could just extend the markup to declare that widget in an elegant, ambiguous way so it can be observable for the rest of the world... But wait a minute. Isn't javascript capable of being semantic and observable? Is the current state of javascript not proof enough that there is indeed something not right with markup too, and perhaps never has been? So perhaps you ask: what could possible be wrong with markup? Well, my wiseguy snot-nose retort would be, do you really need it? Do you really need it when javascript is small enough, fast enough, malleable enough, semantic and observable enough? Do you need it when the choice would be up to you to either automate the web yourself or have it automated by some angled bracket constructs? And your users or customers would be happy with your web creation, no matter what? Ok, too many questions, time for some answers.
Obviously, there is a wish for DOM to integrate more tightly with JS at the moment. And the same can be said for SVG. Perhaps our woes will all be over when this has become so. The reason I'm not happy about Dojo is that there is no DOM at all, that is to say, it is abstracted to the point of being unambiguous and unobservable, and of course that is very bad. I should not have to tell my app what goes where and what size it has on a pixel level, or tell my widget what to do when horizontal orientation doesn't fit. I shouldn't have to express what is a Menu, what is a Tree, what is ContentPane, when in markup this meaning could just remain implicit, and becomes actualized through its use. Of course I used CamelCase to make clear that I am speaking of classes from object-oriented programming, which is not particularly blessed with implicitness... But to tell this in a declarative way seems to me to be less controllable in the end. And when there would be a declarative technique to do this automatically, it wouldn't necessarily be the way I want it. So developer control is an issue here, and I think that has been the main reason for javascript to take off the way it has. Apart from the question "do I need it", there is the question of "can I control it".
In the video, one semantic example surprised me. It was the use of <input type="..." />, which we all know represents a form element. Now, having worked with forms a lot, I can certainly say that this is such an exceptional case where classes have their right to exist! The distinction between types of user input is exactly as well-defined as a UI can ever be, and in almost all cases, we want to be as clear and concise as possible as to what a user is expected to enter. Moreover, we want the input to reflect a very strict data model, as to be valid. So why markup there? It's totally unambiguous, hence the domain of script. Ever needed a new form control or input type? I suspect you haven't been waiting for HTML5 for that, and you won't wait for it now when you like chosen.js, for example. But enough about this. I'm getting side-tracked.
When we incorporate "new" techniques (like proxies, multimethods, protocols, CLOS-like metaprogramming and aspect-oriented programming on the one hand, and semantic web-like relational data models on the other), it becomes clear that javascript will change and become more ambiguous and observable. I won't go into detail about those techniques, as they will need to be much more developed and normalized, and can take up multiple 600-page books to explain. But once they have, and a decent way of controlling graphical components arbitrarily has emerged from the current endeavors, I see the role of markup, at least in the way it's currently interpreted by browsers, as largely played out. However, I remain open to a more in-depth discussion about it's future.
http://fronteers.nl/congres/
Suddenly – and any web developer watching it will feel the same – my javascript house of cards came tumbling down. This guy really has a point! We invested so much in javascript mainly because the HTML tool set is not complete, and probably never will be. We develop our apps (yes, my body tag is empty too), because "IE8 cannot do that", or HTML is not semantically rich enough to declare my beautiful smart widget... Maybe if we could just extend the markup to declare that widget in an elegant, ambiguous way so it can be observable for the rest of the world... But wait a minute. Isn't javascript capable of being semantic and observable? Is the current state of javascript not proof enough that there is indeed something not right with markup too, and perhaps never has been? So perhaps you ask: what could possible be wrong with markup? Well, my wiseguy snot-nose retort would be, do you really need it? Do you really need it when javascript is small enough, fast enough, malleable enough, semantic and observable enough? Do you need it when the choice would be up to you to either automate the web yourself or have it automated by some angled bracket constructs? And your users or customers would be happy with your web creation, no matter what? Ok, too many questions, time for some answers.
Obviously, there is a wish for DOM to integrate more tightly with JS at the moment. And the same can be said for SVG. Perhaps our woes will all be over when this has become so. The reason I'm not happy about Dojo is that there is no DOM at all, that is to say, it is abstracted to the point of being unambiguous and unobservable, and of course that is very bad. I should not have to tell my app what goes where and what size it has on a pixel level, or tell my widget what to do when horizontal orientation doesn't fit. I shouldn't have to express what is a Menu, what is a Tree, what is ContentPane, when in markup this meaning could just remain implicit, and becomes actualized through its use. Of course I used CamelCase to make clear that I am speaking of classes from object-oriented programming, which is not particularly blessed with implicitness... But to tell this in a declarative way seems to me to be less controllable in the end. And when there would be a declarative technique to do this automatically, it wouldn't necessarily be the way I want it. So developer control is an issue here, and I think that has been the main reason for javascript to take off the way it has. Apart from the question "do I need it", there is the question of "can I control it".
In the video, one semantic example surprised me. It was the use of <input type="..." />, which we all know represents a form element. Now, having worked with forms a lot, I can certainly say that this is such an exceptional case where classes have their right to exist! The distinction between types of user input is exactly as well-defined as a UI can ever be, and in almost all cases, we want to be as clear and concise as possible as to what a user is expected to enter. Moreover, we want the input to reflect a very strict data model, as to be valid. So why markup there? It's totally unambiguous, hence the domain of script. Ever needed a new form control or input type? I suspect you haven't been waiting for HTML5 for that, and you won't wait for it now when you like chosen.js, for example. But enough about this. I'm getting side-tracked.
When we incorporate "new" techniques (like proxies, multimethods, protocols, CLOS-like metaprogramming and aspect-oriented programming on the one hand, and semantic web-like relational data models on the other), it becomes clear that javascript will change and become more ambiguous and observable. I won't go into detail about those techniques, as they will need to be much more developed and normalized, and can take up multiple 600-page books to explain. But once they have, and a decent way of controlling graphical components arbitrarily has emerged from the current endeavors, I see the role of markup, at least in the way it's currently interpreted by browsers, as largely played out. However, I remain open to a more in-depth discussion about it's future.
Comments
Post a Comment