I’ve been tinkering with a scripting language for writing web applications for a while now, which I’m calling Hula.
Hula came about because I figure there must be an easier way for web applications to glue together incoming requests and the underlying service layer. In the past 10 years I’ve seen quite a number of different Java MVC frameworks which attempt to solve this, to varying degrees of success. And I’ve seen implementations of those frameworks, with varying degrees of success. And also a fair amount of evil.
The glue part can be a bit boring at times: You’re marshalling/demarshalling parameters from a request, calling services, storing stuff in the session, dealing with cookies, etc. It’s all boilerplate stuff.
Also, alot of what’s happening in the application layer (glue) has been done countless times before. Signups, Login, Logout, Registration, Forgotten Password, Subscribe to Newsletter. Why code it again?
My ideal would be to drop pre-built components from a library, straight into my app.
Some other things that irk me in writing web applications:
- When they don’t follow a configuration by convention approach.
- Having to recompile, redeploy for simple routing mistakes (though JRebel helps).
- Lack of isolation from the platform, leading to issues with thread-safety, multi-tenancy.
- Not having an out-the-box approach for clean URLs.
I could go on, but sticking with positives, I went with implementing a scripting language for a variety of reasons:
- As John Pavlus says, programming languages could be more intuitive, and I couldn’t find a language I liked for this job.
- Scripting is one way to get around recompiles.
- By using a purpose-built scripting runtime, scripts are easy to pass around, well isolated from the container, and better at multi-tenancy.
So what did I end up with? Below is an example Hula script for an ecommerce site, for looking up the customer cart details, for display.
GetSession as session
If $session = null OR $session.cartid = null
GetCart $session.cartid as cart
I hope it’s pretty obvious what this script is trying to do, but I would say that. To be clear, the intention was:
- Gets the customers session
- Checks the session exists, and they have a cart identifier. (If not, it redirects to another script called nocart).
- Looks up the cart by the identifier (from the session)
- Specifies which page should be rendered
Syntactically, each line starts with a command, plus an optional set of parameters, and an optional return value. More here. The idea behind this is to encapsulate any boilerplate code, such as getting a session, setting the view to render, in the command.
I’m pretty confident that, following good application design principles, the range of operations one performs in the application layer should actually be quite limited – the majority of which could be serviced by a relatively small number of commands.
When building an application with Hula, one may need to build a set of commands to provide access to their application-specific services from Hula, however this is likely code you’d need to write anyway, and these commands would be reusable throughout the Hula scripts.
It’s early days, but Hula is available on GitHub as two projects:
- Hula-lang – the parser and runtime for the Hula scripting language.
- Hula-web – an implementation of Hula for web applications.