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

Re: JS frameworks & the future of the LSMB UI


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,

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.


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...

John Locke