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 :)

Cheers,
PS

[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.]

19 comments:

Tom Pridham said...

I agree with you that this new generation of "developers" are really just "IDE-button-pushers" and most likely could not compile a class from the command line, nor find class information from an API document. I mentor/train many junior java programmers. I start them off with an HTML link on their desktop to the Java API index, a copy of Textpad, and a short cut to cmd.exe (with some mods for buffer size, color etc). After about 2 months or so operating in this type of bootcamp environment, I let them grab Eclipse, NetBeans etc and let them go crazy. At least they understand the under-pinnings of the technology they are trying to master. I also believe that every developer fresh out of school should spend about 4 months or so in the Analysts department, then about 4 months in the QA department, then moving permanently into Development. I got my start in QA/Analyst and it really gave me a huge boost to the start of my career as a software technologist.

Kind Regards,
Tom Pridham
Land O Lakes, FL USA

Peter Svensson said...

@tom: Yes, the power of eclipse is great, but when you're used to taking short walks, it starts to feel silly to take the cars just ten meters down the road to the next house.

And that's what it seems to me, but once you're in the car it's hard to judge distances, so people don't want to get out and look around.

It's good to hear someone doing good out there. From all of us, thanks!

Cheers,
PS

Alex said...

Hi Peter, I answered in a blog post:
Formal web application description

Peter Svensson said...

@alex: Thanks for the info, and check my further comments there as well :)

Don said...

I agree that young developers need to start with the basics, I'd prefer the cmd.exe link be replaced with % or some other Linux prompt.
but as a seasoned developer, I started in 86, I rarely see a QA or Analysts department, it is usually more like, we will forward you the e-mails, maybe you can write us a Project Plan, Design Specification, Detailed Project Schedule and a Implementation Plan. So have an idea when you will have something we can look at, we really need to get this completed quickly.

So guess what the junior developer will be doing..... He will need the Word.exe link as well.

Don

Stephan said...

Whoever today is not using an IDE is plain stupid.

Peace
-stephan

PS: Yes, I've used Emacs, EDT, Vim, Pico and ED for decades.

Peter Svensson said...

@stephan: Thanks for your insightful comment. I would indeed say that it very stupid not to use an IDE when you are otherwise forced to generate boilerplate code manually, create three different XML config files containing similar, if not the same, information, and creating complex build scripts by hand.

That's really stupid.

On the other hand, if you're using technologies which are in no need of those contrivances, not using and IDE might not be a killer, and sometimes doesn't matter.

However, I really use Aptana Studio quite a lot, mostly for the quick object and function list, but not for much else.

When I have to code in some verbose language again (I've been coding in Java since the late 90's, mostly CA or JSP-derived things.), I naturally have to become cybernetically entwined with Eclipse, anything else would be stupid.

. But maybe there is something else here that is even more stupid, if you're looking at things from a bit longer perspective (and can compare)?

Stephan said...

@peter: You're welcome. The boiler code argument is a myth, well there is no boiler code. The first IDE I have used extensively was Turbo Pascal. So much easier than the command line compiling and debugging before under CP/M. The first productive IDE I've used a lot was Delphi.

An IDE does much more than generating code. How about refactoring, dependency matrices, coupling metrics, automatic deployment, runtime monitoring, quality tips and event based debugging? Or the most basic tasks like displaying API documentation, checking the syntax and auto completion? Using an IDE makes me several times more productive than Textmate or VIM for Python, Ruby, Perl or PHP development, at least in my experience in the last 15 years. YMMV. As soon as Ruby/Python gets a run-time sniffing IDE (think Smalltalk) which does API, auto completion and correct refactoring, everyone will switch and praise their productivity with IDEs.

Boiler code? The last code I've written was a REST handler in Java.

@Path("/uuid")
public class UuidResource {
@Named("uuid")
UUIDService service;

@GET
@ProduceMime("text/plain")
public String getUuuid() {
return service.getValue();
}
}

I cannot see any boiler code there. One could argue about static typing but every line is needed and would be hard to reduce. Could you show me some boilder code?

Peace
-stephan

Peter Svensson said...

@stephan: Hi again! I've been using Eclipse since it was called Visual Age :) And otherwise mostly vi.

What I'm trying to say is that a lot of the features of Eclipse (et.al.) are damage management due to the lossyness of partly the verbose language being used, but mostly of the extreme lossyness of the framework being used.

And I am using IDE's, but not all of the time. When I'm working in a terminal window I can make do with vi. And the reason for that is I don't _need_ refactoring, automatic deployment or runtime monitoring. I'm just editing a textfile, which is the end product. When I've written a line of code, I save, and reload the page. I have the API docs for whatever I'm doing (if need be) on a web page.

And when I'm writing JS+PHP services, I really don't have much use for an IDE, since it's just text-files anyway, both on the client and server. Sure, it takes less time when I have a dozen classes or more to jump to the right spot, but really no killer.

When I'm writing a service of some kind in Java, working without an IDE is mind-bogglingly complex. here comes the boiler-plate code; You have to create and use a web service client.

Java: Either runs ant tasks which are fairly opaque to generate the scaffolding, or use an IDE wizard, et.c, then perhaps you only need to write a page or two with try/catch statements.

PHP:

$client = new SoapClient(urldecode($wsdl));
return $client->__soapCall($wsdl_func, $fa);

Where $wsdl is an url for the wsdl file, $wsdl_func is the name of the function you're going to call and $fa is an array with arguments.

PHP has support for this (normally) compiled in from the beginning, so you just use, and the wsdl file is cached automatically.

And this is not an isolated incident, but it is a very nice illustration of why I rarely is in need of an IDE.

My codebases are anywhere up to ~8KLoC, mostly smaller - because I write less lines of code for the same functionality.

And I agree YMMV. Certainly there are edge-cases where either (of ours) approaches bogs down, and edge-cases where they shine.

It's just that , being in a position to compare medium sized projects done in Java+horrible framework which creates the client out of the server at every action, and PHP+JS is like night and day when it comes to time between idea and execution.

Now, if you dispense with the horrible framework and use a RESTive approach you're better off, of course.

Still, I can do anything much quicker in PHP than in Java, and I have only two years part-time experience in PHP.

yes, I know. Maybe I just suck at Java and happen to be a PHP prodigy :) I somehow doubt it..

Strange huh?

Stephan said...

"And I agree YMMV. Certainly there are edge-cases where either (of ours) approaches bogs down, and edge-cases where they shine."

Yes we may differ.

Beside that I do not use Eclipse because it's the worst IDE I've every encountered. Instable, low usability, confusing. Netbeans and especially IDEA are much better. And as I said, I don't do SOAP, and never did, because it's the wrong way. For client/server communication REST is much better, when I can choose the form of communications I choose tuple spaces (think Linda) or ESBs. They do scale much better from my experience than bloated SOAP services. Not sure if REST does work in the long run though, especially if it can deliver all SOFEA use cases. Or if coupling an in-browser JS message bus with a comet driven server bus is a better idea (think TIBCO architecture). We'll see. The future is exciting.

Peace
-stephan

Stephan said...
This comment has been removed by the author.
Peter Svensson said...

@stephan: Actually, I've only also used NetBeans, which was very nice, especially when I did some j2ME work a couple of years back. I've heard much good of IDEA but never used it.

And, yes, I haven't had much experience with truly large codebases. I think my point is that at least for me, it takes much more lines of code to make something in Java, compared to PHP. Meaning: if I had created the same thing in Java, it _would_ have been a large codebase :) Maybe.

And I've never actually used SOAP services either (outside of work). Tuple spaces are cool, and it feels that the world is slowly converging in simplicity in that area as well (CouchDB, Amazons' thingamajig, et.c.).

I'm all for the SOFEA guys, but I think they're overshooting the target a bit, since I don't really think the main thing is that it necessarily has to be XML and WSDL consumption on the client. The main thing is putting the client on the client, but I suppose you knew I thought that already :)

Unified messaging is, of course a kind of rapidly approaching holy grail. What would be very cool IMO is if Jaxer gets comet, in which case you get one language for both client and server-side, and a groovy/JRuby(/RhinoRails) accessibility to all legacy Java APIs for free.

Cheers,
PS

Stephan said...

Take a look at Helma, a production ready JS server written in Java and used for high traffic sites for years.

I'm working on a SOFEA application with JSON, their reliance on XML ist only accidental. They will discover that too ;-)

Peace
-stephan

Peter Svensson said...

@stephan: Well, I've actually been checking out Helma, from a distance for almost a year. It regularly comes up when I do searches, and I stop to read to docs now and then.

I think the reason I don't really like Helma is that they still have the old server-side generation metaphor, even though it is implemented in JavaScript, in pretty much the same way Phobos has.

They have macros and skins/templates which access server-side functions, et.c. Which means that they give a lot of functionality to that kind of programming, which I'm trying to move away from.

Which again, kind of leads back to my main point in the blog post, which is that I think there's a need for more standards of a practical nature, to help give structure to thin server architecture, or what we shall call it.

At the moment everyone is on his/her own, but with just a tiny bit more pragmatic structure I feel that the idea of creating SOFEA/TSA-style apps will be much more comfortable to developers.

Stephan said...

As I know some of the Helma developers in person, they are very clever and nice guys, I assume they see the SOFEA light and are open to improvements. The latest Helma has added server side continuations. And I had a discussion some time back with some of them about using the same code on the server and on the client (as I think I wrote in an Linux magazine article about Helma) [*]. I hope to do SOFEA with my own rendering lib with server side pre-filling of components through Rhino. Currently there is no "real" SOFEA framework around which combines client and server.

Peace
-stephan

[*] A problem which might occur is that server side JS currently is Rhino 1.7, the client side is some versions - and always will - be behind.

Peter Svensson said...

@stephan. That's good to know. Of curse they have to be pretty smart to be able to create something like Helma in the first place. And the development doesn't seem to have stopped either.

Continuations are pretty cool, but what got my attention recently was that they were starting to fiddle with making it really easy to access Java objects from inside the server-side scripts, copying some good things from Phobos.

Actually, there are two sort-of proprietary frameworks which are very much SOFEA; One is WaveMaker and another one is SmartClient.

Both use Java-based (I think Tomcat in both cases) backends, both to power their studio parts, but also as service proxying for the generated clients / pages.

Both are GPL'ed but also available as commercial license a la MySQL, and both have SOAP web service consumption in the client (and a host of other stuff).

I'm leaning towards WaveMaker, since they're using pretty much standard Dojo for the client.

I'd like to generalize what these guys are doing between web-based IDE and server and between finished client and server, and see if there are common pragmatic ground enough to drive the creation of some kind of simple, yet usable standard.

Of course, the next step would be to implement such a standard for Jaxer and Helma :)

Cheers,
PS

Stephan said...

I'm not sure if packing Dojo or ExtJs with a WS backend is SOFEA. But perhaps using such architectures will enable us to see real SOFEA. Just as struts has helped us to see web frameworks. Or as WebObjects has made me see the future of web development (when all I did was coding CGIs in C and Python back then). But we didn't stop at WebObjects. So we will not stop at SOFEA 1.0

Cheers
-stephan

Peter Svensson said...

@stephan: I agree that we must continually strive to make better systems, and be inspired by the good things we see, and try to inspire others to use the best tools available.

SOFEA can be implemented with a client-side js framework and WS backend services, as long as the client is downloaded separately (application download), and all communication from there on use XML, IIRC.

Jackline said...

Hi Nice Blog .A employee time attendance that tracks both direct labor and indirect labor activity, including the employee, activity, machine, part, operation, project, date, time, and hours. This module is fully integrated with the Timeclock screens provided by Time and Attendance System