Re: JS frameworks & the future of the LSMB UI

[John Locke <..hidden..>]

Hi,

One quick comment to make on this... Otherwise I think I've already 
expressed my opinion ;-)

 

On 07/30/2013 03:14 PM, Erik Huelsmann wrote:
> Hi all,
> <snip>
>
> As far as "LedgerSMB coming with Scriptaculous" is concerned, I'll add 
> a section to INSTALL telling packagers to depend on the packages 
> readily provided by their distribution to provide 
> Scriptaculous/Dojo/jQuery/etc: these packages are updated for bug- and 
> security fixes, something we can't all keep track of. Which means to 
> me: we should probably separate the scriptaculous dependency out into 
> its own TAR file which can be untarred over a tar which holds the base 
> LedgerSMB code, if the user wants it. This makes the dependency more 
> apparent and prevents packagers from accidentally packaging an 
> additional JS framework.
>
> Comments?

I don't see how it's practical to do this. JS frameworks need to be 
served up by a server, and it makes sense to have it served up by the 
same server that's handling the underlying web app.

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.

All in all, most webapps that use JS libraries go ahead and bundle them 
in, because otherwise configuring them gets messy and challenging. It's 
just a lot easier to include them.


Regarding the bug and security fixes, I can think of one major Dojo 
security update that might have been a concern enough to warrant an 
upgrade: a PHP script that was part of the supporting util or test code 
that could be exploited. Otherwise we're talking about code running in a 
browser, not code on a server. While this might (with a lot of effort) 
open up some new vectors for CSRF attacks from other users of the same 
LedgerSMB instance, it's really hard to see any kind of attack vector 
that these JS libraries open up.

The only server-executable code in the entire Dojo tree (outside of what 
you might run in Node.js) are things we could probably omit: code for 
providing server-side support for demos and tests, and code to build js 
and css layers to optimize loading.

The build functionality is definitely useful to address Brian's most 
recent comment, about needing to load 10 or more AMD modules (which is 
already the case on the two screens I started with).

In most of my Dojo projects, what I do is put the Dojo tree in a git 
submodule (similar to an svn external), and then make a build that gets 
added to the actual application's repo. With that model, we could strip 
the build of any/all server-executable code, and only ship built 
Javascript in the tarball...



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