In the past year I've written two complete java web application frameworks from scratch; one like Wicket, and one (Blogfiche) a more traditional MVAC framework with an alternative syntax to HTML. So why am I building another one?
Am I nucking futs?
The answer is always the search for more programmer productivity, flexibility and reliability. Blogfiche (which runs this blog and other things) has proven itself to be flexible, reliable, and for what I use it for, scalable. Digg and Reddit traffic don't faze it, even though it runs on a shared (and rather overloaded) server. The alternate HTML syntax is fun to use, much less irritating than HTML if you write by hand:
if(headlines:sizenot0)[
div(class=articlebox heads)[
loop(post|headlines)[
p[a(href={post:url})[{post.title}] span[{post.created:datetime}]]
]
]
]
So why do another one? Mainly I want to be able to build an entire web application without any recompilation, yet still have good performance in production. I am using the solid foundation of my Fiche framework (built on the servlet spec) including its automatic caching of web content. On top of this I intend to support Javascript (Rhino) and Groovy (and anything else interesting) and see what I like better. Although I can use the alternative HTML syntax, I am building a view technology on top of regular XHTML to make it easier to use examples from the web.
Something like:
<head>
<title>{title}</title>
</head>
<body>
{if(test)}
<p>Test</p>
{else}
<p>Not Test</p>
{end}
</body>
For database support I will continue to use iBatis, if I can properly reload the sqlmaps when they change, or maybe try something new like couchDB, or even build something similar to ActiveRecord. There is a lot of possibilities here; the primary point is to be able to update code and database use without compilation.
I am not trying to replicate PHP or ROR or whatever flavor you might enjoy. Software is an infinitely malleable clay; you don't know what you can do unless you try something.
Again with the why? Why not, I enjoy it, I like productivity, challenges, and I have time while I wait in absolute contractor hell; at least my mind is working and I can avoid going absolutely bonkers waiting on people to make a #@!$#@decision.
florin 09/19/2007 06:35
Have a look at JPublish. Use the Scripting action support and you don't need to recompile :)
As for the UI dev part, we are supporting: Velocity, Freemarker and StringTemplate :)
http://code.google.com/p/jpublish/
Let us know your impression,
-florin
Mark Menard 09/19/2007 08:29
Hi,
You said, "Mainly I want to be able to build an entire web application without any recompilation, yet still have good performance in production." That's what drove me to work on what I call Groovy Works, http://code.google.com/p/groovyworks/ and http://www.vitarara.org/cms/taxonomy/term/70.
It's based on Struts 2, which is based on XWork. It integrates with Spring, and thus with everything that Spring supports. I can write my actions, service beans and DAO's in Groovy and just keep coding. My service beans and DAO's need to implement an interface, so my basic work flow is write the interface and an empty implementation of the interface. Then I wire my DAO, service bean and action together. At this point they do nothing, but they are wired. From that point on I can code and reload with no app server restart. Write my JSP/Velocity/Freemarker template, action, business logic and data access without the usual compile, deploy, restart cycle.
Take a look,
Mark
Mike Seth 09/19/2007 15:08
No, no and no!
Frameworks are not born out of an abstract desire for productivity, flexibility or reliability. These are secondary outcomes caused by many factors, and the framework is not necessarily a substantial part of them: if your broken regular expression code crashes the PHP interpreter, or your JVM runs out of virtual memory, your framework of choice may as well silently die.
Frameworks are written so that the programmer is comfortable expressing his or her vision in idioms that suit the problem domain space; that is, they provide an environment that fits what you're doing, and allows you to do so consistently. A framework is not, by a long shot, an extension of your code but a constraint on it. If you accept it, the framework pays you with consistency and bribes you with library services. If you reject it, benefits of the framework are nullified, and you might as well glue some 3rd party libraries with a bunch of spaghetti code and call it a day.
Hint: RoR is not a framework.
Joe 09/19/2007 16:34
Perfectly sensible - I've yet to use a framework (in any area, including web), that doesn't contain at least a few pain-points. There's nothing duller than trawling through someone else's code trying to figure out why something that the framework should actually make a trivial task is harder to accomplish than if you weren't using a framework at all.
There's no better way to understand why frameworks are the way they are than to build one yourself. After all, the big web frameworks started out as a single-person project, usually to address a specific type of application space, so there's plenty of room for different approaches for different application needs.