+972 52-548-6969
HTML & Assembly
Scott McMaster equates HTML to assembly. I find it amusing because one of the design goals of HTML is to be accessible to anyone, and I do believe that it has served that job in a very good manner.
Scott suggests that higher level abstractions such as control toolkits will take the place of HTML in the future. I do not agree, mainly because I have seen how painful such approaches can be when you want to simply generate HTML. Remember, for an abstraction to be useful, it has to give me a significant advantage over the existing approach, and it shouldn't limit me overmuch.
HTML is dead simple, so I don't see much value with that, and since no control toolkit can give me what I want, and since when I need to add additional stuff, I want it to be simple, I don't really see much value in going in that direction.
What is possible is that technologies such as Flash / Silverlight would become much more pervasive and allow us to move from HTML documents to more elaborate methods of communicating with the user.
Comments
I think you mistake the meaning of control toolkits. Sure, a special table control has no value, since an html table is easy to render. But what about sorting or reordering columns. That's where control toolkits add value. Not even the ASP.NET gridview supports ordering on the client, so yeah, control toolkits are the future.
Mike,
sortable.js and class="sortable" handle sorting very well in quite a few scenarios.
If I need to do server side sorting, then it is often way too complex to be done in a generic fashion, so that is not relevant either
Hi Oren. If you re-read my post, note that nowhere did I actually argue that HTML is "too complex". In fact, I didn't say that assembly was especially complex, either, and I suspect that if I ever did, I could draw some assembly fans (if there are any left) into a spirited discussion on that. I think a lot of people instinctively make the "assembly language => complex" jump, which I realized could lead to confusion in this case.
What I -did- say was that historically, better abstractions enable more complex applications, and at higher levels of quality. That's not really even an opinion -- it's a fact. So the only discussion to have here is whether or not HTML is the most abstract thing we really need to build all existing and future generations of web applications.
Microsoft has always been ahead of the game on abstraction front -- going all the way back to Visual InterDev server controls to VB6 WebClasses to ASP.NET. It's ironic that just as the Java community is finally coming around to some of this stuff, factions of the Microsoft community are running in the other direction.
Regarding Flash/Silverlight, I actually don't think those things make HTML go away or necessarily even send it into the background. I have another post on rich-runtime approaches based on my Flex experiences kicking around in my head, so maybe I'll get that down in the next week or two.
--scott
Scott,
The main reason that we don't use ASM anymore is that it is simply too complex to use in what we need to build today.
Perhaps a better word would be awkward ?
I don't view what we need to do with HTML today as overly awkward, although I think that better support (from the browsers) would make things much easier.
To go back to the assembly analogy, using these controls is like using a 4GL. It is very productive in the narrow field that it covers, but not really applicative for the overall picture.
I kind of agree and disagree with both of you, but I think it's a terminology thing.
When we talk about "abstraction" in programming we actually mean one of two things. In one sense, we mean a simplifying abstraction -- the sorts of changes that move "here are 10 steps I must do" to "do what I mean." In the other sense we refer to a change in representation into something more familiar or something more accessible for the context you need (ORM systems are an example of this -- "replacing" the SQL query model with objects). Instead of "do what I mean" it's "represent the painful bits in a way that's easier for me to wrap my head around in this context".
The jump from assembly to any other programming language is the latter sort of abstraction -- instead of thinking about series of machine instructions operating on a memory space, you're thinking about a space of functions, messages, what have you.
As a guess, abstractions on top of HTML will not be useful when they're only the first type of abstraction -- HTML is already close enough to "do what I mean" that any additional benefit will come at the cost of too much clumsiness (ahem, CSS).
On the other hand, I think there will be benefits to abstractions that shift to a different representation of the problem. This is especially true for complex HTML and JS applications, where getting to what you want to accomplish starts to involve excessive amounts of detail (mixed with piles of cross-platform issues, to boot).
This may be a way of saying that HTML will not be abstracted around, but JavaScript will be (and already is being -- witness GWT, RJS, all the toolkits, etc.).
Faisal,
Masterly spoken (written, whatever :-))
Comment preview