Archive for August, 2006

State of Web 2.0 Development

My background is in writing desktop applications, usually cross platforms ones that run on Mac and Windows. That’s how I spend my days and make actual money. But because of my tenure on Dreamweaver, and all the hype around “Web 2.0″ and “AJAX” I’ve recently been playing around with web applications.

My first toe in the water was with Ruby on Rails, which is apparently all that and a bag of low fat baked Doritos. It offers “convention over configuration”, which means if you name your classes the right thing it does a lot of work for you for free. Rails is, from what I could tell, a nice and complete framework for database backed web applications. I also found Ruby to be a very nice, object oriented, scripting language. All the power of Perl, but with a much better syntax.

More recently I’ve been toying around with PHP, in the form of writing a WordPress plugin. PHP is very procedural based, and has what I would call minimal support for objects, and definitely is configuration over convention. PHP will not do anything for you unless explicitly tell it to, in its very C-like syntax.

I don’t think I would be stretching it to say that PHP is the de facto standard for web frameworks, while Rails is the fastest rising star (although django, written in Python, also looks interesting). But that’s not my point here. My point is they all suck. Bad.

That’s right fanboy, I’m talking smack about your favorite web framework.

I don’t care how easy you think Ruby on Rails is, its still painful compared to developing desktop applications. I’ll completely ignore the usability of web apps in this article, AJAX be damned.

The first paradigm shift I hit when moving from writing desktop applications to web applications was the fact that there is no state. That is, nothing is stored unless you manually jam it into a database or a session variable. This wouldn’t be a problem if every single web page wasn’t a separate program that is run and exits before the user even sees it. This makes any form of interaction with the user an experience in pain. Every bit of effort required to build up state (such as permissions, database queries, objects, etc) is thrown away on each page, every time that page is accessed. If the user submits a form, the web application has to build up that entire state all over again! A large portion of the code for the WordPress plugin I’m working on is just trying to figure out the user wanted to do (even though I had information before) and if they have permission to do it (i.e. they’re not trying to pull a fast one on me). The web form often has to embed a lot of hidden fields just so the web application can remember what the user wanted to do in the first place. A lot of effort is wasted rebuilding information the application already had. Real programming languages and environments don’t require this. It forces a lot of unnecessary work onto me, the programmer.

Maybe there’s a way to save off variables, but its not automatic. In Rails I want to be able to store an instance variable on my controller class and have it be there when the next action is invoked. i.e. It should act just like a desktop application. Bottom line, a web application should be like writing one application, with a shared state, instead of dozens of separate applications that happen to share a common database.

The second wrinkle I ran into was how many languages was required just to write a web application. i.e. HTML, JavaScript, PHP/Ruby, and SQL. Don’t get me wrong, I’m a programmer at heart and love to learn new languages. I just don’t like being forced to use so many when its unnecessary. I’m also fully willing to accept that certain languages are better than others for their purpose. HTML works well as a presentation markup language and SQL works for data queries. That leaves the language that is used for the logic and control. Right now, you have to use at least two languages for this: JavaScript for the client and PHP/Ruby/Python/Perl/etc for the server. Why is that? They’re all serviceable scripting languages. I should be able to write both client and server side code in one language.

As an aside, YouOS, a web-based operating system, allows the you to program everything, client and server, in JavaScript. JavaScript wouldn’t be my first choice, but its currently the only client side language, so there wasn’t really a choice. But it reenforces my point that there should only be one scripting language for logic and control.

The language difference also contributes to the divide between the client and server. I should be able to write all application logic in the same language, and client code that calls server code (or vice versa) should be seamless. i.e. Where’s my remote procedure calls (RPC)?? Its kind of, sort of, but not really there in XMLHttpRequest. It half way exchanges XML documents, but not really in a way that’s all that useful, mainly because clients (web browsers) may or may not be able to parse the resulting XML. Not to mention all the overhead required to parse and generate the XML. Most importantly, the RPC isn’t transparent. I should be able to mark any file, function, or object as server side and the language should automatically know how to do the right thing, without me writing any XML or intermediate code.

Finally, HTML/XHTML or whatever the w3c dreams up next to stave off their own boredom, needs to add some real controls. Push buttons, check boxes, edit fields, and simple listboxes do not cut it. There need to be multicolumn tables, tree controls, menus, etc, and the existing controls need a lot more event handlers. Basically anything that a desktop control can do, I need to be able to do in the web browser. Web application programmers would be a lot more efficient if they didn’t have to keep reinventing the wheel. Also, standard controls would certainly increase usability. Instead, it looks like the w3c is trying to pass off Web Forms 2.0, XForms 1.0, or whatever its called, as the “next thing.” There are some problems with it:

  • Its specification is huge. So huge its only possible use is as fuel on a cold winter night. No human will actually be able to read it.
  • It uses a lot of XML, more than necessary. I assume the conversation that led to this went something like:

    Committee Member #1: Does anyone know how to give the programmers more controls and event handlers?

    Committee Member #2: No, but I like XML!

    Committee Member #3: XML can solve any problem if you don’t think about it long enough!

    Committee Member #1: Great! We’ll jam a bunch of XML in there and hope they don’t notice we didn’t fix anything.

  • It is way over engineered.
  • It doesn’t actually solve a problem, unless too many woodland owls was a problem.

Look, exchanging XML is a huge pain already with the tools currently available. Why would I want more, in even more complex documents? I want controls to communicate with the backend via RPC in native data types. The language can use XML behind the scenes to implement it for all I care, but I’d better not have to touch it.

My point is all this ballyhoo about Web 2.0, AJAX, the web browser becoming an OS, is all crap. There will be no big “revolution” for web apps until the developer tools for the web catch up with those of desktop tools. Programmers currently spend too much time dealing with problems the language and/or environment should take care of. Until that is fixed, Mr. VC, your dreams of Web 2.0 is just an overhyped pipe dream.

Objective-C 2.0

Andy Matuschak has a great write up on what to expect in Objective-C 2.0. As someone who didn’t make it to WWDC this year (one of my business partners got to go this year), I found the article very informative.

What’s more, he managed to describe the changes to Objective-C using only publicly available sources (i.e. no NDA violations). Very impressive.