My business partner and I started thinking about building eAuteur in 2006. I did a prototype of a webapp, and taught myself how to develop basic Java webapps over that summer. So much has changed since, and it all seems so much easier to get started and build a webapp. I actually think that software development in general is easier than 6 years ago, when I started studying Computer Science. I suspect that the abundance of information on the internet has motivated many to make their tools and APIs easier to use and understand, and to write concise documentation. Plus, there are nice screencasts for just about anything, so you can just sit back, watch, and learn about the latest thing that’s going to make your life simpler.
Dry kiss Java!
Ruby on Rails has shown the way, and now the Java community is also seeing web development get much quicker and more fun with the Play framework. It’s been influenced by what was best in the Java world (Grails, Lift) and in the Ruby world. It fully implements the KISS (Keep It Short and Simple) and DRY (Don’t Repeat Yourself) principles.
For instance, this video shows how easy it is to send emails to your users with the Play API, and how unnecessarily complex it is in “regular Java”. The video is in French, but even if you skim over it on mute, you’ll get the point. As in the rest of the API, you only have to say the strict minimum, and the framework figures out the rest for you (Convention over Configuration).
There is also the JQvalidate module, that greatly exemplifies the DRY principle. It automatically generates the jQuery code necessary to validate your forms client-side, based on the validators defined in your Play code (have a look at the sample code given at the bottom of the page). Thus, you only need to say how inputs should be validated once, and this takes effect both client- and server-side.
Front-end goodies
Although the previous section was rather meant for Java adepts, this one is for everyone! I’ll assume the reader has heard of Hyper Text Markup Language and Cascading Style Sheets. Well, there’s smarter languages than CSS to style a website. There’s SCSS and SASS: you can define variables, you can use mixins, inheritance, nesting… Have a look at this scrrencast for a full motivation.
There’s also CSS frameworks, such as Blueprint (probably the most popular) and LessFramework, designed to cut down development time and ensure cross-browser compatibility. You’ll notice that most website layouts have commonalities, so there’s got to be a way to make styling easier. CSS frameworks allow to develop a site’s layout at a higher level with predefined styling elements (forms, columns, grids, menus, headers, footers, etc.). People also create their own styling elements to be used within frameworks, so there’s really no need to reinvent the wheel — here are some nice CSS buttons for instance. High level means easier to develop and maintain, but still, Blueprint works with CSS, not SASS. That’s where Compass comes into play. It dynamically recompiles the SASS files in your project to CSS.
To get you started, check out these two articles:
- Don’t use css or table layout, use Sass and Compass
- Getting started with Serve, Compass, Sass, Haml and Blueprint
Styling goes along with markup, and those who use SASS write their markup in Haml, which compiles to HTML. Haml is intended to render markup “beautiful”, i.e. more readable, concise, clean, and in a format that easily maps to CSS and SASS rules (check out the sample code on the Haml website!). For those who use Scala, Haml can be extended with Scalate.
Infrastructure
In a later post, I will expand on easy webapp hosting and discuss infrastructures — or the absence thereof 
