﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on HTML &amp; Assembly</title><description>Faisal,
  
Masterly spoken (written, whatever :-))
</description><link>http://ayende.com/2738/html-assembly#comment6</link><guid>http://ayende.com/2738/html-assembly#comment6</guid><pubDate>Mon, 27 Aug 2007 16:02:55 GMT</pubDate></item><item><title>Faisal N. Jawdat commented on HTML &amp; Assembly</title><description>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.).
</description><link>http://ayende.com/2738/html-assembly#comment5</link><guid>http://ayende.com/2738/html-assembly#comment5</guid><pubDate>Mon, 27 Aug 2007 05:43:12 GMT</pubDate></item><item><title>Ayende Rahien commented on HTML &amp; Assembly</title><description>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.
</description><link>http://ayende.com/2738/html-assembly#comment4</link><guid>http://ayende.com/2738/html-assembly#comment4</guid><pubDate>Sat, 25 Aug 2007 21:51:12 GMT</pubDate></item><item><title>Scott McMaster commented on HTML &amp; Assembly</title><description>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 =&gt; 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
</description><link>http://ayende.com/2738/html-assembly#comment3</link><guid>http://ayende.com/2738/html-assembly#comment3</guid><pubDate>Sat, 25 Aug 2007 16:07:03 GMT</pubDate></item><item><title>Ayende Rahien commented on HTML &amp; Assembly</title><description>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
</description><link>http://ayende.com/2738/html-assembly#comment2</link><guid>http://ayende.com/2738/html-assembly#comment2</guid><pubDate>Sat, 25 Aug 2007 15:26:00 GMT</pubDate></item><item><title>Mike commented on HTML &amp; Assembly</title><description>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.
</description><link>http://ayende.com/2738/html-assembly#comment1</link><guid>http://ayende.com/2738/html-assembly#comment1</guid><pubDate>Sat, 25 Aug 2007 15:09:10 GMT</pubDate></item></channel></rss>