Site visual and information design about hackage-server

[amigalemming]

Please, please, please, no JavaScript! JavaScript leads very quickly to unusable sites. I have disabled JavaScript for security reasons. But even with enabled JavaScript, most JavaScript sites do not work on browsers other than the browser of the developer.

[chrisdone]

I think what @amigalemming is saying is a good point, content archives should not stop working without JavaScript enabled. However, there's nothing wrong with implementing graceful degradation. Which is what Github does, for example.

[dcoutts]

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.

[chrisdone]

The Hackage userbase is a peculiar one that likes to disable JavaScript a lot (I see this in the community often), so disregarding those needs for the sake of making dev work easier would obviously be insensitive. Though I'm interested to see why the model depends so much on the input method.

[dcoutts]

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.