Tuesday, February 26, 2008

Web Monday 2.0 in Stockholm!

It's now exactly a week until the next Web Monday (on a Tuesday) event takes place at NetHouse in Stockholm, Sweden.

Be sure that you add yourself to the wiki, in case you're coming (or think you might drop by); It makes it easier for us arrangers (OK, me :) to know how many beers to commission, and that sort of thing;


The list of speakers is at the moment the following;

  • Practical Dojo 1.0 - A couple of practical Dojo 1.0 examples and walkthroughs - Peter Svensson, NetHouse (LinkedIn profile, Blog)
So if you're in Sweden and interested in some or all of the above, please come by and chat to people with similar interests.


Monday, February 25, 2008

The Future of Web Applications

I am positive that the future of web applications lies in simplification. Not simple as in too few options, or not very smart, but simple as in easy to understand.

The simplicity/complexity debate has mostly been debated on behalf of different languages, where ease of use has been pitted against (developmental) scalability and the verbosity of safety-measures and meta-data has been clashing with implicit information and quick deployment.

Instead of looking at which language offer the most suitable properties to development, I thought it interesting to instead look at what kind of protocols can be used, or created to simplify (in this case) Web-based applications.

Why so? Well, even the frameworks being used (Web-based (Generates the client (html/js) on the server for every action) or resource-based (respond to RESTive accesses and/or rpc calls from a separately downloaded html/js client) are in most cases tied to their implementation languages, with the possible exception of Rails becoming a de facto standard over almost the whole playing field (Trails, Grails, Symfony, et.c.).

But the power of Rails (from my admittedly shallow experience) is mostly due to either the expressiveness and clarity of Ruby itself, or from the strict opinionation when it comes to file structure, database management and mappings, et.c. Rails is still in some parts 'just' another JSP or ASP, in that it allows, even encourages mixing of presentation and logic, <%=foo %> wise. I know that there are a lot of RESTive parts to Rails, but I haven't had time to try them out. By what I've read, though, they seem to be more on the right path.

Much of the comments in the debate I've more or less started around the End of Web Server Frameworks center around the fact that people (this is my conjecture, of course) feel very naked without proper IDE integration and code generation, and most importantly readily accept any configuration-file hell and bloated Schrödingers codebases (which will resolve into either working or non-working client code only when you open the lid/actually run the service), as long as they don't have to suffer the indignity to actually _learn_ something that lives inside the browser.

As I said, my conjecture.

But to alleviate this problem, I think one has to think a bit above the language and indeed even the framework being used. Imagine there was a specification so that a client (in JavaScript, yes) could discover the capabilities of the framework it connects to without having to know exactly which framework it is.

Say that you have a specific resource in each framework, which when called return a file (perhaps NOT XML for once? :) which describes the following;

1. Type of user authentication support + resource (To be able to make generic login widgets)
2. List of named, read-only data sources, organized by type
3. List of named, read-write data sources, organized by type
4. List of named, RPC endpoints, organized by type

Maybe this standard exists already, or something like it exists, that can be reused for this purpose. If so, please comment or mail me, because I've been searching standards organization and the like the whole weekend.

What do we gain by this? Well, it makes it possible to write generic widgets. Generic as in generically pluggable to any compatible server. And, quite frankly, it would make it possible to write generic clients for specific purposes, say resource editing, possible, so when you write your new fabulous service, you need only implement the common resource (tm :) description interface, and you can just pop in half a dozen existing clients that suit your purposes.

And as it happens, I'm in the process of contacting people to see if we can get a working group around this, either loosely coupled or under an organization which is compatible with the purpose in mind.

If you feel that you're interested, drop me a line, and we'll start something up :)


[Update 1: In response to a very good blog post by Alexander Klimetschek, I'd like to add that even though WADL indeed fits the bill in many respects, as I have formulated my ideas, what I'm really grasping after here is not so much a descriptive generic language, but a opinionated list of specific common services, to later be expressed in (perchance) WADL.]

Friday, February 22, 2008

Separation of Concerns - the IDE angle

So, you might have thought it reasonable to avoid getting stuck in the XML swamps of the Server-side Web Frameworks, and instead separate the client in your system to run entirely in the browser.

You might even have chosen a client library framework (like Dojo) to do so. Still, that is only half of the solution, since even with the best client side framework, it must have a server to play with (even though that server does not generate content as such).

Theres also the IDE factor to consider. You'll probably be using Java on your server. You probably must, since you're actually designing a new web access 'portal' for an existing system. How could I guess?

I recently ran across the WaveMaker IDE. Those guys were called ActiveGrid before, but recently changed the name of the company. *** As you might remember, ActiveGrid was the company that donated the worlds best Grid component to the Dojo foundation when the bought the company Turbo Ajax, who were its makers. ***

****UPDATE 2008-03-31**** : Dylan Schiemann of Sitepen and the Dojo foundation have corrected me in this issue. Naturally it was
SitePen, Mozilla Foundation, Nexaweb Technologies, Redfin, & SnapLogic that last fall jointly bought TurboGrid from the TurboAjax group.

I don't really know what to say in my defense, sadly enough. I remember that I read several articles on the subject and how I could come up with my first take on this subject, and how I could get it this wrong is completely incredible. Very sorry about this!!
**** UPDATE ****

The WaveMaker IDE has a number of very good features, listed in no particular order;

1) It is Web-based
2) It runs on its own Tomcat-server with a massive supporting act (the download is ~90MB!)
3) It's fully open-source under the GPL.
4) It uses Dojo 1.0 components, so you create your page(s) visually.
5) Complex components like Tree or (above mentioned) Grid can be connected to services on the server
6) You can create services inside the IDE; WSDL, Database Queries or custom Java code.
7) It generates generic WAR archives, for crying out loud!

There are a couple of other web-based IDEs out there which I quite like.

TIBCO is one, but it can only use WSDL services, and lives only in the browser. And most of the others want either to host your solutions at their remote server farm somewhere, or possibly sell you a nice vendor lock-in solution that will hurt good in a couple of years.

So WaveMaker really has guts to actually deliver what's needed for the .. I don't think customer is the right word, since it's free, but there you go :) But what I meant to say is that most companies focus on how to make sure that they secure their own position first, and then loosen that a bit here and there to make the proposition tastier for the customer. This is almost the other way around.

Full disclosure before I go any further: I do some contract work for WaveMaker. However, I really like their approach and would not have taken up the work otherwise.

But to sum it up - To be able to approach the ideal of "Thin Server" or Separation of Concerns properly, you need to have support on the server-side as well. I'm not sure you really need IDE support as well. I've kind of given up on Eclipse (not counting using the Aptana plugins for JavaScript work - of course).

What I mean with support on the server-side is tools or inherently capable systems that result in a proper RESTive service foundation that can be accessed by the client.

WaveMaker supports not only the addition of existing services into the client for consumption, but lets you create them, and gives you a more cleanly separated server-side even if you choose other venues later on, which is even better.

Another option is of course to use a server-side technology that is a RESTive foundation to build upon from scratch - such as Apache Sling, for example :)

Now that I think of it, why not have both [Another late night warning klaxxon].. ? Hmm...

Friday, February 15, 2008

The End of Web Server Frameworks - part II

My first post on this subject described the general waste of resources that Server-side Web Frameworks incur, and the slideshow describing the alternative "Thin Server Architecture" had a number of very clear diagrams describing the alternative. This article meet the criticism I have received, question by question, to further clarify how to lower the cost of web application development.

1. c: Some frameworks are good for some things and some for others. Surely this "Thin Server Architecture" is just one choice among others.

a: No actually, it is not a choice among others. It is the total removal of any web framework on the server whatsoever. That's what it is. It is "No View on the Server", and it is "Put the client on the client". If you consider "lowering your development and maintenance costs dramatically" a choice among others, be my guest. But I would generally consider that a question of whether to have a third ear at all compared to the question of where to put it.

2. c: Oh, you can't use this method for web based applications for users who can't use JavaScript, like some mobile users, or people with disabilities. Therefore, we can't use it.

a: That is absolutely true. If you have to create an application that has that kind of restrictions, you can't use Thin Server Architecture. Luckily the user base of Gmail and other applications of its kind shows that with some luck there might be a sufficient user base out there for consumer facing applications (at the very least) of that kind after all...

3. c: The page will load in weird ways which users are not used to. Nobody will want to use a web application like that.

a: What have you been smoking? The users will react badly to getting things quick? To not have to reload the page at every single click? It's like the notion that humans were unable to survive speeds quicker than a galloping horse when the steam train was invented. Also, you can simulate classic loading using JavaScript if you like.

4. c: There is no need to go to such extremes. We already have AJAX support in JSF and it works well, for minor things where that kind of 'effects' are needed.

a: Since the idea of using Ajax on a separate client (on the client) is opposite to generating the client on the server for every action, this Frankensteinian technique works well for nobody. It is a little bit like tying a jet fighter to a sinking Titanic. You will get a little lift, for a while, and then all will be engulfed by the next wave.

5. c: If you have to shuffle all data to the client using Ajax, it'll be too much data and the page will be slower that if it is created by the server-side web framework at once.

a: Eh, hello? There is still the same amount of data, no matter how you get it over. Using Thin Server Architecture you get the page in place super-fast, then load and pre-load resources under the hood so that the application acts snappy when the user starts to interact with it. Oh, and you only ship the data after that.

Måns Jonasson's research in this area shows a 33% decrease of server resources when starting to move View logic onto the client, from the server.

6. c: We have already invested so much money and training in our server-side web framework of choice, so we'll use it anyway, for all future. Nobody has the strength to ever learn anything again. We're not interested in lowering costs, we just want to do what we've done for years. Go away! Yaah!

a: Well, good luck then :)

7 . c: JavaScript is a Girlie Language. it is only used by teenagers with acne from Finland . Real men use languages that was ridiculed in precisely the same way ten years ago, so there!

a: Well, since JavaScript has no true OO, it can oddly enough not be used for anything at all, whatsoever, except for small scripts that blink a button when you hover over it.

This is really strange, considering some guys are actually claiming that JavaScript is more similar to Lisp and Self than anything else. and what's even more confusing is that people have been building these fairly complicated frameworks in JavaScript, with data models, rpc calls, message buses and rich dynamic, cross-browser charting and graphics, to boot.

Also, there is supposedly companies who provide really great IDE support, of various flavours.

What's more, there already truly amazing solutions for bringing this on big time .

So my take on this is that this is the near future. If you don't think so, and have experience to disprove me, please comment here or mail me, because I'd be more than happy to hear what you have to say.


Monday, February 11, 2008

Thin Server Architecture

This is from a talk I gave at Stockholm's first Web Monday, last week.

In it, I try to describe the benefits of putting the client on the client and reducing complexity on the server.
The highlights are, as always, to try to make things as simple as possible, but no simpler :)


Måns FTW!

I really don't have time to blog today, but I just have to point out my good friend Mån's new post about optimizing web site speed and functionality through a very cost-efficient workaround (using JavaScript in the client, obviously :-P).

Please read it in its entirety, research, recommendations and all;



Saturday, February 9, 2008

Bunkai + Sling == true

Finally, I managed to write a server-side JavaScript (esp) in Sling that gave back a correct JSON structure of the node and its children. With a little massage it made a great input for a Dojo tree structure;

This is not available on the Bunkai PoC site, since it needs a backend which can provide an url that spouts JSON, but I'll think about lciensing Bunkai so that you can download it and make it run on your own backends.

The next step is to make it possible to change Sling url, path and to provide create, load, edit and save operations from the tree to the Sling backend, which, Sling being what it is, will be a breeze in comparison :)

This was the hard part.


Thursday, February 7, 2008

Dojo Developer Day

You _do_ know that the fourth Dojo Developer Day start right now, as we speak, don't you?

If you are in or near San Fransisco, head up to the GooglePlex, where Google are donating the use of some facilities for the event, but mail rsvp at dojotoolkit dot org, so people know you're coming.

It's completely free, and chock-full of the brightest and the best in the Dojo-making industry of today :)

Believe me, if I were in San Fransisco, I'd be camping outside the doors. Actually, it would suffice with being in any of the Americas. As it stand, I sit in "Gamla Stan" in Stockholm, Sweden and is going precisely 20 km west (not near enough by a long shot) to cook dinner for my family. But that's life.

The next DDD, though...

Sunday, February 3, 2008

Challenges of Server-Side JavaScript

Just last week Aptana released Jaxer, dubbed "The Ajax Server", the latest - and greatest entry into the Server-Side JavaScript arena. Jaxer is not the first SSJS framework, and (Steve Yegge willing) won't be the last either.

A couple of years ago, sun released project Phobos, which is a very well documented and powerful SSJS Engine with support for direct subclassing - in JavaScript - of loaded Java classes à la Groovy. It also has a kind of proto-rails opinionated structures, with Controllers and Views. This is not something I condone on the server, but let's not rant about that right now. Some people will find it useful.

Then there's TrimPath, which looks like what Steve is trying to do, with Google Gears integration, alleged Ruby on Rails-like MVC and a lot of other good stuff to boot. Another feature of TrimPath is that is can execute on either the server or the browser, just like Jaxer.

Another great SSJS is Helma, which includes an MVC framework, just like most others (except Jaxer). Helma also lets you access any Java Class in your Classpath, but more interestingly it has something called HopObjects, which is a JCR (JSR-172) like data repository, built in to the framework itself. You create object in JavaScript, on the fly, and they gets immediately created and RESTfully accessible.

This brings us quickly to another class of SSJS, namely the Mozilla Rhino integrated Java-based frameworks, like Apache Sling, for instance. Sling _is_ an über-JCR implementation which uses REST for object management, can be a webDAV server and is violently OSGi compliant :) But for the purpose of this discussion - it most importantly has a generic Scripting support, letting you script resource behavior in JSP, JRuby and, yes, SSJS.

Sling is probably not the last framework to enable productivity by simplifying development by allowing server-side scripting inside a 'classical' framework - Sling being anything but, but you understand what I mean.

But back to Jaxer. Is jaxer really an also-ran even before it came out. Does it have anything to contend with beside these other frameworks?

Well, yes, actually it has. Jaxer has (not yet) integrated support for any Java class in classpath - which should be in their number five priority list), but it has server-side DOM rendering.

Huh? But the DOM is on the client..

Not any more baby, check out these pix and see what I mean. Jaxer can take any HTML/js/css combo, and if you want execute the (standard) jQuery calls to set up the markup the way you want, and then sent the finished, static page to the client.

It could, for instance, detect if your poor user was forced to use a version of Internet Explorer, and then use the Mozilla engine included in Jaxer to render the page on the serve, and give them the right page looks anyway. How's that for flexibility.

Also, Aptana has financing, has released Jaxer under GPL, and has integrated Jaxer (which can be standalone as well, as an Apache mod) into their Eclipse-based IDE, Aptana Studio.

Yes, I like Jaxer, and I like the Studio as well, in case you didn't notice :) But what Aptana really need to do is to check out their SSJS competition and offer framework services, Java, and possibly PHP integration and more out-of-the-box programmableweb.com services. And more Dojo. Lots of Dojo.

Actually, the SSJS (non-web) framework issue was on the top of my mind when I started writing this, but I'll have to get back to it later, due to bed-putting constraints .

Until then,