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.]
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.]
Comments
Kind Regards,
Tom Pridham
Land O Lakes, FL USA
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
Formal web application description
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
Peace
-stephan
PS: Yes, I've used Emacs, EDT, Vim, Pico and ED for decades.
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)?
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
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?
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
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
I'm working on a SOFEA application with JSON, their reliance on XML ist only accidental. They will discover that too ;-)
Peace
-stephan
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.
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.
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
Cheers
-stephan
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.