[ckan-dev] CKAN and JavaScript

[David Raznick]

> I don't especially get this and would like to understand more. So many
> sites today require  significant amounts of javascript.

Not many good ones in my opinion.  There are a few exceptions, such as
gmail/google docs but they have a huge budget to get things correct
and they are a single service.
I actually cannot think of any good sites that are mostly javascript,
especially content driven ones.  I sometimes browse with scriptblock
on and its a very pleasant experience.  The web is faster and less
buggy.

> While I
> *completely* agree that basic view functionality (browse and view)
> should work w/o JS (in at least a basic way) for much else I just
> don't see this (and even quite a bit of sophisticated read
> functionality comes from JS). It seems to me that in this day and age
> to provide much of responsive UX users expect requires significant JS.

I agree that you could have rich app like interfaces for some more
complicated interactions or games.   I also see the need in javascript
replacing things desktop apps for productivity tools and the like.

However, for us in ckan to use javascript everywhere feels a bit like
using flash everywhere.  Why were we not building ckan in flash to
begin with?  It offers much richer experiences :)

>> * The site content is indexable and searchable via search engines like Google.
>
> This only requires that browse and view dataset functionality . Almost
> all the JS would be elsewhere - either in editing or in visualization
> or in e.g. rich search (not needed by search engines)

That feels a bit like saying we are going to use the web just enough
to be called a website and get our SEO but we do not need to follow
the rest.

>
>> * Content is accessible to screen readers and other assistive technology.
>
> I really don't think this is a priority given that our focus is data
> -- i'm not saying I don't care but just that is probably a lower
> priority.

I really think that open data should be accessible to all including
people who do not like javascript for security or accessibility
reasons, including hopefully underpowered devices or for low bandwidth
places.

>
>> * The site functions for users without JavaScript enabled, while the scripts load or
>>  if an error occurs breaking the app.

This is a very good point, there is no logging or anything that goes
on if something breaks in the browser.  There are workarounds to that
but it is still much more difficult to know whats gone wrong.

>> * Keeping JavaScript to a minimum reduces load times and keeps page weight
>>  down.
>
> Again this is a really a minimal advantage and we can optimise in other ways.
>
>> It also keeps majority of the application in Python which is the primary language
>> of the CKAN team and reduces the maintenance cost of having large portions of
>> application logic in two places.
>
> We wouldn't have application logic in two places - we would move to
> having a significant portion of e.g. editing and dataset viz in pure
> JS.

The logic would be repeated as you still need server side validation
regardless.

This way we would expect custom instances of ckan, who want to
customize their forms, to make it in javascript and html and learn the
backend code too.  I do not think we would ever have the time to build
a framework to help people to do this.  It will be yet another barrier
to entry to stop people using the software.

Currently the resource form, for example, is impossible to modify
without hacking it, which we will have do do for certain instances.
There is a lot of untested intricate ux code that is non reusable for
anything else and the templating is different from the rest of the
software.

If this is an example of the future using js for our forms then it is
definitely a bad call.

If we were building ckan to be a single service then my opinion on
this may be different.

>
> Furthermore, the existing skillset of the team should not determine
> this decision too much going forward. If we think going a more JS
> route is the right way for UX,

I am not sure that it is.  There is much more things to good UX then JS.

I admit that I have said that js + api is the way to go for certain
use cases and it opens up a whole new world of apps accessible online,
but ckan does not seem one of them.

All in all I trust Arons opinions as he has more expertise in this
area that any of us.

Thanks

David