Assembly Language of the Web
by Zef Hemel- Published:December 27th, 2007
- Comments:9 Comments
- Category:Work
I was watching this video interview with Dion Almaer of Google and it reminded me of a view that I have, and that I think is shared within the WebDSL team. It might be controversial, maybe it’s not. The view is that we see (X)HTML, CSS and Javascript as the assembly languages of the web. I feel that, although coding HTML, CSS and Javascript was fun for a while — we can do better. What you’d want is a higher-level language (be it WebDSL or GWT or whatever else) that abstracts from those low-level languages. I think there are better languages to be designed that can be compiled to a combination of those three.
GWT is the most mainstream implementation of this. You feed it Java code and it produces HTML and Javascript. We do the same in WebDSL (although we did not base it on Java). Web development is hard, and frankly, annoying because you have to deal with differences in browser implementations, browser versions and so on. All stuff you don’t care about. The solution is to abstract from that, and come up with a language + compiler that generates the browser-dependent code for you so you can focus on the problem at hand rather than spending 2 hours fixing the lack of support for CSS’s a:hover in IE 5.5 (or whatever, I don’t know zip about CSS).
9 Commenti
The main problem with this (it’s a nice idea otherwise) is that computer generated tools don’t update fast enough. What do I mean? I mean when IE8 comes out the *compiler* will have to be updated, then the server has to be updated. This means that people will probably be using an old version of the compiler for months and perhaps years before it gets updated (just thing PHP5 adoption).
On the upside, it does mean you only have to update one file (or package), but that only gives you an advantage if your site is badly managed with IE8 incompatible code spread through multiple files.
Still, Ferite has webframework which essentially does what you want, plus a lot more.
I couldn’t agree more. I think web languages are a drag to use, it takes to much efford to do the simplest things and you have to reinvent the wheel all the time. I would even go further than this to be honest. Personally I feel that programming any kind of user interface is a drag. I’ve done a very simple one in Swing in the past, it was a lot of work. Nowadays I always use graphical tools so that I don’t have to write the code myself. Visual Studio for example, it comes with a designer that produces decent code to create a GUI. It’s not the most readable but GUI classes usually aren’t (as you need a lot of declaration and very little action).
I’d be perfectly happy if I could just create a GUI in a designer of some sort and not even have to look in the code, just define where the event listeners go and insert my own code there. Maybe that’s just me though, I don’t really care about the user interface in the first place. It should be easy to use, I don’t care how it looks.
You are totally correct - soon browsers are just another type of virtual machines.
Take jsc for example - http://jsc.sf.net - it too compiles C# to javascript, .NET MSIL to sourcecode. Also microsoft is cooking his own version - codename volta.
I get your point, but sorry to tell you that you’re dead wrong.
There is many reasons why this concept is flawed and would not work in real world web development. More importantly, you ignore the source of our problems as web developers and try to patch it instead of fixing it at the root. It won’t go away, It will get worst and worst.
I think, as web developers, our efforts should focus on forcing browser vendors to respect standards, propose new standards when needed and incite archaic browsers users to update their *probably* unsafe shit.
Adding a layer of complexity for the sake of simplicity won’t help us.
my 2¢
@h3: The source of these problems is Microsoft, and MS doesn’t care about your - or all the developers in the world - 2¢.
I get your general point about the need for a higher level language. But, on the the particular points, you should probably be investiagating some of the Javascript libraries/frameworks which already solve many of the cross-browser issues. For example, your hover problem solved through jQuery:
http://docs.jquery.com/Events/hover
Most of all, I disagree with the GWT approach, which is terrible. It uses a less flexible language (Java vs. Javascript) to make web programming look like traditional desktop GUI programming. This is somewhat wrong headed. I like the evolution of markup CSS DOM/script that the web has brought. I think we’re better served by a synthesis of these ideas in some higher form than the awful GWT approach of trying to make the new look like the old and familiar.
wcyee, spot on!
I just realized that this is going the other way: markup is finding its way into desktop development. For example, there’s glade, a GTK interface designer.
The older versions of glade where essentially a code generation tool which was supported a few fixed languages. This meant that glade was useless for many developers since their language was unsupported.
Newer versions however changed to creating an XML document which describes the interface, now, instead of modifying glade to support your language (in a language you don’t like), you simply write (or use a pre-existing) glade library for your own language.
It also means you can use any XML tool to edit the interface on the fly, you could even apply an XSLT stylesheet to import or export to other interface standards.
So, no, I don’t think an assembly language is such a good idea, and now thinking about it, there is a good reason why I dislike rails and the ferite webframework.
wcyee, “It uses a less flexible language (Java vs. Javascript) to make web programming look like traditional desktop GUI programming. This is somewhat wrong headed. I like the evolution of markup CSS DOM/script that the web has brought.”
What is it exactly that you like? The advantage of using Java is that you can statically typecheck it and optimize it, which is a big issue with javascript. In Javascript if you need a library, you have to download it all to the browser. In GWT, everything that you don’t use is not going to be downloaded. That’s a big win.
“What is it exactly that you like?”
I like that the ability to prototype and experiment at a high level while staying close to the (browser) metal, so to speak. I can vary presentation through application of markup and CSS, access the resulting content in a DOM, and use Javascript as a DOM updater. I like the separation of responsibilities inherent in that model and I like the speed and flexibility of development it affords.
To your original analogy, Java bridges the semantic gap between assembly and general purpose programming. In this case, I don’t really see how Java/GWT improve things since the semantics of the “web assembly” are pretty high level already, and GWT creates an unnecessarily layer without many benefits. You have to program to a different model, then compile/build, deploy which is unnecessarily slow.
I admit the cross browser stuff is a pain, but there are many solutions to this within Javascript. The static typechecking of Java is also nice, but now we’re debating programming language models. This has been done countless times on the web with Python vs. C , Ruby vs. Java, etc. I won’t rehash that here except to say that there is a tradeoff, and I’m comfortable trading off typechecking with flexibibility and rapid development.
“In GWT, everything that you don’t use is not going to be downloaded. That’s a big win.”
But this is just an implementation detail and certainly not limited to GWT or Java. For example, the Dojo Toolkit (Javascript) has the require statement:
http://redesign.dojotoolkit.org/?q=jsdoc/dojo/HEAD/object/dojo.require