HtmlIsAssembler

MeatballWiki | RecentChanges | Random Page | Indices | Categories

In the grand ecology of the web, HTML is akin to assembler for computers. The browser is the processor that runs the "program" that is the HTML file; or, more generally, it realizes the content of the HTML just as a processor realizes the content of the assembler (ignoring machine language).

HTML is the base, most final output before realization. Nothing is below it.

In fact, HTML is a really bad "assembly language." HTML is static, which is boring. The modern push has been to abstract HTML to higher levels to allow more powerful expression, especially making parts of it Wiki:TuringComplete.

JavaScript and CascadingStyleSheets (collectively, DHTML) are immediately above HTML. Embedded server side tags like JSP, ASP, and PHP are above that. Zope is a further abstraction (adding inheritance!). CGI above all of that. ColdFusion is a low-level HTML assembler.

A concrete example: a wiki is a higher level expression than HTML. A wiki is like an on-the-fly compiler between WikiSyntax and HTML.

So, what do you get over HTML when you use something like a wiki?

Flexibility
Structure
Consistency
Dynamics
Ease

But what does HTML give you over a wiki? Finer control. More optimal display. Basically what assembler gives you over VisualBasic?. (WikiIsVisualBasic??) But it's harder to do right in a consistent manner.

Basically, to do anything remarkably interesting, you have to extend HTML. -- SunirShah

: HTML in itself would be much more interesting if someone came up with a browser that actually supports it. --MatthiasGutfeldt?

Actually I don't agree with likening HTML to assembler. HTML is data; e.g. static and thus dead. Assembler is a (primitive) programming language; e.g. dynamic and thus living. HTML is no more a programming language than the escape sequences we used to use to control dumb terminals. The only reason we compare HTML to a programming language is that html-based languages like JSP encourage us to confuse the terminal's language with the language that emits html to the terminal. This results from JSP's own confusion over the difference. There's more along these lines in the article referenced below. --BradCox

You are being too literal. The analogy is simply that HTML is the basic construction block for web pages. Instead of writing HTML directly, though, you use higher level systems to generate it (like code generators create assembler). This is infinitely easier, better, and more powerful. -- SunirShah

No. And the difference is not subtle. The construction block of the JWAP demo application are HomePage, LoginPage?, AddressPage?, and the transitions between them. The building blocks are members of a network of objects, not a collection of files and certainly not html data. The web app is made of objects, not html. HTML happens to be the name of the format the web app emits to the browser. It was exactly this observation that set me on the path away from JSP and Perl --BradCox

JWAP, JSP and Perl are higher level languages. They emit HTML. The basic building blocks of the higher level languages may or may not be HTML, which would be consistent with the concept of a code generator (by definition--this isn't an analogy). HTML is "assembler" in the sense that it is emitted from a code generator (this is an analogy). The use of the word "assembler" was only to make a catchy moniker to remember that dynamic websites emit HTML. Assembler happens to be the name of the format that is sent to the processor to make something happen. (Ok, it's really machine language, but ML ~~~ Assembler.) Really, you have to look at the browser as the client processor of the site, because that's exactly what it is. It makes something happen for the client. The browser communicates in low-level protocols, which I've conveniently bagged under the umbrella "HTML" although it extends wider through many protocols like the other XML variants, streaming media, FTP, gopher, etc. -- SunirShah

I think I understand why the analogy is meaningful to you because I'd have agreed with you when I was using Perl and JSP. I press the issue because my own personal breakthrough (with a RADICAL improvement in productivity) came when I realized web apps are just object-oriented programs like any other, and that it is browsers that are constrained by html, not web apps. That was a liberating thought because this is what opens the door to things like compile-time link-checking; a thought that wasn't thinkable until I could shake loose of the program-as-html-extension mindset of languages like JSP, PHP and Perl. I realized then that the reason web apps are hard arises from thinking of them as string processors (as with Perl) or html extensions (as with JSP), and that treating them as object-oriented programs like any other would make things much easier.

It really comes down to information theoretics. You are constrained to eventually emitting HTML (say--like I said, this extends to any client-server protocol) or else nothing at all. You can't escape this. If on the server, you have something better than JSP or Perl, that isn't just a string processor, that's fine. You are still going to have to use HTML. Similarly, you can use C or Lisp, or you can use Smalltalk, or you can use wonky 4G program-with-pictures languages. In the end, you have to hit the bare metal with something, and that happens to be assembler.

Diagrammatically:

    Server (whatever) <---(HTML)---> Client (Browser+plugins+application extensions)

is akin to (note the selection of interpretted languages)

    Language (Lisp, Smalltalk, VisualBasic?, INTERCAL) <--Transducer(Assembler/Machine)--> Processor

The server can be implemented in whatever. JWAP or JSP. Perl or INTERCAL. Static HTML pages or agent-oriented distributed object computing. Whatever. It's that simple. There is no escaping this, no matter what pinball machine you have on the server.

Perhaps you are confusing HTML files with HTML streams?? HTML is actually a stream. There is no concept of HTML files defined on the web. The file concept happens to be a design aspect of the older web servers, and it certainly isn't any more. (*) URLs are not paths. This is exactly why you can name an HTML "page" foo.asp. The web browser doesn't care as long as it gets the Content-type: text/html in the header. This is why CGI scripts as well as object-serialized web nodey things work that you and me are interested in. -- SunirShah

(*) Except with JSP, but JSP is a Java thing, and Java does everything wrong.

I think you guys are both saying more or less the same thing. You both want to avoid working with raw HTML because it is too low-level. Brad says HTML is data. As any Lisp programmer will tell you, one man's data is another man's code and vice versa. The assembler code output by a compiler is data too, as far as the compiler is concerned. The input to the compiler is not assembler (though some languages allow you to have fragments of assembler embedded in the higher level source), just as the input to a Wiki is not HTML. I agree that writing a Wiki script as a "string processor" is a poor way to go, just as it would be hard to turn a C program into its corresponding assembler the same way. Regular expressions are evil succubi; tempting, but they will lead you astray before you know it. -- DaveHarris

I have a site devoted to essentially this same issue: http://virtualschool.edu/wap particularly see the "The Problem" link in the left margin. I'd really appreciate comments/criticisms/suggestions on this approach. The basic idea there is that dynamic web apps should be objects, not files as in JSP or strings as in Perl. This is aimed at dynamic web apps in general, not wikis in particular. PS: I came here looking for a discussion of WebAppConstruction. Any interest out there? --BradCox

Please see what I have to offer on this under WebAppConstruction. --AlMeyers

The first analogy is definitely incorrect: HTML is not "Browser Assembler". Everything that can be done in any high level language can also be done in assembler because it all gets translated into machine code in the end. Assembler just assigns mnemonics to the machine code, so programming in assembler is essentially the same as programming in machine code. (It isn't exactly the same, but it is close enough for all practical purposes.) So, you can take any program written in BASIC or whatever and translate it into Assembler and maintain all functions because Assembler is the closest to machine code as it gets, and (once again) it all becomes machine code in the end.

The Point? If Java and Perl and such were high-level abstracts of HTML then it would be possible to write HTML code that would preform any function that java, perl, asp, and all the rest can perform. Try to write an HTML tag that would preform the same as the Universal Back Button in JavaScript:

 <A HREF="javascript:history.go(-1)">Back</A>
 ie - take out the ^^ javascript call

-- BelTorak

Think about how server extensions are code generators that emit HTML that actual represent the user experience. Think about JSP compared to Wiki:TemplateMetaProgramming. Naturally, HTML includes such things as ECMAScript, SVG, Flash, RealAudio?, etc. but that would have made the page title obnoxious. Clearly your example is included.

Note, the analogy is not strict. It's just a perspective. It wasn't set up as a logical simile, so don't be so quick to dismiss it. -- SunirShah

HtmlIsAssembler

Discussion