[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


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?


> So if you're amenable, I'd suggest let's go ahead with introducing Dojo as an included library, and let me, Brian, Herman, Mikkel, and anyone else who's comfortable plugging away at the JS side of things improve one screen/module at a time, with a goal of more complete coverage in 1.5, and then perhaps look at new UI paradigms for the release after that.

Sounds good to me.

>
> Cheers,
> John Locke
> http://www.freelock.com




--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
http://www.efficito.com/learn_more.shtml