HTML/Java Workflow & Architecture
Currently I’m thinking about different ways to set up a good set up for creating/changing websites. When your team consists of HTML/CSS developers on one side that know about user interaction, graphics and layouts and Java developers on the other side that excel at making data available and dealing with the complexities of 3rd party communications. The challenge is to set up the team and architecture for an effective workflow, letting everyone do what he/she does best.
The context is a company that has a lot of data and wants to make this data accessible through multiple channels and sites. The user experience is a very important, so tuning the websites on the HTML level is an ongoing activity. Expanding to new devices and websites is one of the (technical) objectives.
The way to set up the components and what abstractions to use is not obvious. After speaking to some peers in the industry, I’ve distilled three main options to choose from. Combinations are possible, but I’ll describe the simple case. I haven’t decided which is best, though and I might be overlooking some crucial things. My main goals for any solutions are:
- Zero round-trip while developing HTML/CSS/JS
- Independence of HTML developer when creating new ways to display the same data
- Smooth work-flow from concept to implementation.
JavaScript All the Way
With this approach JavaScript takes care of all interactions of the website. A good example is the Google Start page, which contains very little HTML, but once you enter a search term, the content completely changes, using JavaScript
The pre-rendered HTML is very minimal, providing the structure that you fill with JavaScript. The biggest advantage is, provided you can create a clean remote API for JavaScript to access, total independence of your HTML development. As long as you want to display the same data, new websites can be created with few changes required on the back-end. Since the HTML doesn’t have to be server generated, it can be plain HTML all the way. Although that simplifies things there are some downsides as well. Google being the biggest issue; the content generated by JavaScript is not parsed by Google, so your site will not do well in the search engines. Getting the data to your JavaScript means you’ll have to provide an easy http accessible API (using JSON or REST etc.), it might not be trivial to come up with a clean API, basically you’re adding a physical layer to your architecture.
Pros
- Largely independent from back-end
- Zero roundtrip when changing HTML
- There is only one version of the HTML (no conversion to templates)
Cons
- Google cannot index content generated by JavaScript
- Complex workflows that keep state are harder to maintain/debug in JavaScript
- An extra layer of
- Performance and security
- Re-use is limited
Server Side Scripting
Here you don’t let JavaScript fill your combo-boxes, but it’s a dynamic language like PHP/Python/Ruby/ASP that renders them (let’s assume PHP). The HTML is generated by a language that intrinsically supports a fast (save&refresh) development cycle. Although these scripting languages are powerfull enough to build your entire application, you risk not separating the data from the presentation or trying to build things that are too complex (PHP-hell). So you will probably have your PHP access some (remote) API that handles the complex things. There is a bit more flexibility in terms of connecting your PHP to the back-end API and because the PHP is run on the server security is less of an issue. 
Pros
- HTML can be indexed by Google.
- Short roundtrip when changing PHP
- PHP code runs on a trusted server
- Simple enough for HTML developers
Cons
- Risk of PHP layer to grow too big
- Extra runtime environment needed (Apache)
- HTML only works after PHP parsing
The Java World
This is (for me) the most common model. Some Java Web-framework handles the user request, invokes a controller and passes the result to some HTML-template engine which renders the Java objects into HTML. The real difference here is that you have direct access to Java objects from the HTML template, so when you can model and access your data in Java, you can use these objects directly in your HTML. For Java developers this is very natural. Your web application generates HTML, whilst the developer can work and reason about Java objects almost all the way, the HTML is considered the VIEW part of the framework. One issue with this, is when the HTML layer is doing more than just render the data. Integrating interactive behavior in your HTML is handled by some frameworks quite extensively but at the cost of proprietary abstractions of both JavaScript and the interactions between front and back end. Although this works, it seems to be mostly geared towards Java developers that don’t want to deal with real HTML and JavaScript. Good for Java developers, unnatural for HTML developers.
Pros
- Data access and HTML generation in one machine/JVM, easy and fast
- Short development time for Java-heavy applications
Cons
- Extra channels and websites will need to be modeled in the server framework
- Templates are not HTML, only work when run inside the Java framework
- Longer development round-trip, but needs full Java set-up with war overlay
Wrapping up
So what’s the best? Of course it depends. Did I miss any pros or cons? What do you use to get maximum productivity from both your back-end and front-end developers.
On Software Development 