Re: JS frameworks & the future of the LSMB UI

On Wed, Jul 31, 2013 at 2:15 AM, Mikkel Høgh <..hidden..> wrote:

A few notes of my own.

> There is decent CDN support for Dojo, but not for a few of the extensions I can see adding (primarily Dgrid at this point), and having a specific CDN hard-coded into an open source app seems like bad practice to me.

Also, loading external _javascript_ code is a security issue, and given that we're dealing with people's financial data here, I don't think that's acceptable.

To quote Douglas Crockford “IT IS EXTREMELY UNWISE TO LOAD CODE FROM SERVERS YOU DO NOT CONTROL.” (his caps, not mine): https://github.com/douglascrockford/JSON-js/blob/master/json2.js#L15

+1 on this. Also I would suggest that what we distribute should come with code distributed with the app by default only. This could be configured, if we need it to be, but this provides some additional defence.

Also, distributing the libraries ourselves means that our users won't have to worry about getting the right versions of x, y and z. We can upgrade users to new versions of modules on our own schedule.

On 31/07/2013, at 01.19, John Locke <..hidden..> wrote:
>
> On 07/30/2013 03:14 PM, Erik Huelsmann wrote:
>>
>> 2. Longer term general direction for the development of the LedgerSMB UI
>> This point probably requires separate discussion, because the direction taken to develop a UI inherently affects the efforts required for the "back end". I.e. whether we from here on *only* develop services on the back end, with separate front-end developments, or that we develop along the current route which supports to build a rich front-end "eventually".
>>
> I think we should continue to maintain a plain-HTML front end as a fallback, at least for the near future.

Realistically, how many users would actually need that? I don't have the statistics on hand, but unless we have end-users on ~15 year old browsers, there should be no need for a non-JS fallback. And keeping the fallback in place would make the development more difficult, thus slowing us down.

If the data is well designed, I don't see why fallback would be difficult at all. There are a number of reasons why a plain HTML interface can be handy in some cases. I don't know, for example, how well screen readers and other accessibility tools work with js-rich pages (and if the design gets in the way of accessibility, the javascrpt can always be turned off). I wouldn't suggest we lose it unless it becomes a real burden to handle it. Realistically I don't see much burden there, but I could be wrong. Any objection to seeing what we can do to come up with a nice clean way to preserve this?

Well, it's not that I think we should go out of our way to break backwards compatibility, but having two versions of every page (no-JS and JS) that are both supposed to work effectively doubles our testing load. Once I've made something and tested it in all browsers, I'd have to disable _javascript_ and test it all again.

Also, some things will be harder to implement, if we have to keep things _the same_ rather than just making sure they work and are accessible.

Suppose I wanted to replace our account autocompleter with something based on http://ivaynberg.github.io/select2/ – then I would have to hack Select2 to make its output match the current one (2700--Account name here), rather than just making sure that the form still worked as its supposed to (ie. by setting the value of the actual field to just the account number).

Accesibility is a separate concern, as I see it. Modern screen readers do run _javascript_, and it's definitely possible to make JS-rich pages accessible. WAI ARIA does a pretty good job at explaining to screen readers what's going on on the page.