While we have at least switched it all to use the haddock "Ocean" theme, there's a lot more that could be done by someone good at web design. The pages are currently constructed of a mixture of templates and pages generated in code. We should try to do that consistently with templates and make it easier to adjust the site. It should also be possible to do more JS stuff, rather than classic html4 POST forms.
So the reason to consider JS stuff is not because it's cool or slick, but because it could make the server side implementation simpler. The server already has to implement REST style PUT for resources, but the html pages cannot make use of this with html4 forms because they can only do POST using annoying form encodings. This means the server has both to support normal REST using normal representations and also POST using html form encodings. This is a pain, duplicates code and leads to tighter coupling of the presentation and data layers.
If we could use JS on the browser then we can use PUT and do sequences of operations, like any other REST client.
So this only helps if we don't have to also do the fallback to html4 forms & POST handlers.
We could still do this for some of the admin parts of the site.
@chrisdone when you're using a more classic REST API style, setting some info may require a sequence of calls, e.g. POST to create some resource, PUT a couple extra optional attributes. But you cannot do that with a html UI using html4 forms. You need a POST handler matching just what the UI wants to set all in one go.
Here's a more concrete example: hackage has a users feature which has all the basics of user accounts, auth etc. then there's separate feature which manages some extra info about users (mostly for users corresponding to real people). Now a nice user admin UI will want to present all of this info and allow editing all of it together. That is, rather than a modular approach where there are separate pages and separate forms for setting basic and extended user info, a nicer UI will have one page/form to do all of it at once. The UI being less modular is ok, because a templating system makes that managable, but if it has to POST a single form result, then we still need a handler in there somewhere that takes the result, splits it up and sends the bits off to the various internal features. That's a pain. If the front end directly could do the small sequence of POST/PUTs requiresd, like any other REST client, then we don't need that special monolithic POST handler.