How are you managing your usage of DojoX code or widgets in a production application?
The Dojo Toolkit is comprised of Core, Dijit, and DojoX. As an incubator for new ideas to extend the toolkit, DojoX code and widgets are functional with varying degrees of instability.
DojoX Code like QueryReadStore (for fetching batches of data from the server) or widgets like Grid (for utilizing a user interface grid component) are not included in Core or Dijit. But they are functional enough to utilize in some cases, with the caveat "developer beware", because in future Toolkit versions the API or the component location in the source tree might change. Another catch is that you may have to tweak the DojoX component you are using for it to function properly in your environment, as there's not yet a high degree of robustness in the code.
So, how are you ensuring that as the DojoX components you use evolve, your application stays on a smooth track?
This may be an obvious, but much more involved, solution ... but: Get involved! It actually is one of the best ways to familiarize yourself with the overall power of Dojo in one sitting, teaches a lot of good JS-foo, and ensures you have inside information as to the future of a particular module. Most of DojoX is community contributed, and aiming for stability and usefulness. The more people reviewing, testing, hacking on the code -- the more likely it is to succeed and become stable.
Regards,
Peter Higgins
There are several ways to do it:
Stick to one version of Dojo and use it consistently.
Move modified code to your own namespace and include it from there.
Effectively it is a forking of an existing DojoX module. All code syncing and back porting is your responsibility.
Pay attention to the rest of Dojo — if it changes in such a way that it breaks your forked version, be ready to patch your module as well.
Copy modified files somewhere and include/require them before the original file is required.
To illustrate the latter technique imagine that there is one file I want to patch located in dojox/charting/abc.js:
dojo.provide("dojox.charting.abc");
// the rest of the file
...
I can copy it to my directory as, say, my/patched_abc.js, and make it look like that:
dojo.provide("my.patched_abc");
// now I include the rest of the file with my modifications
dojo.provide("dojox.charting.abc");
// the rest of the file
...
In my code that uses dojox.charting I include it like that:
dojo.require("my.patched_abc");
// now I can include dojox.charting,
// which will use my patched dojox.charting.abc module
dojo.require("dojox.charting.Chart2D");
// the rest of the file
...
Just be careful to avoid circular "require" statements.
This technique works very well for backports and minor customizations. If your changes are more extensive than that, you should consider writing your own module.
Related
Large web applications tend to accrue a huge array of libraries that support both front-end and back-end functionality. I want to reduce the number of dependencies in order to increase stability and ease of maintenance. I'm looking for a good path to reducing dependencies in a web app that includes libraries such as:
Bootstrap
CKEditor
Chosen/Select2
jQuery plus various plugins
d3/Raphael
SlickGrid
Handlebars
Underscore
I'm looking for techniques, languages, or frameworks that combine as many of those dependencies as possible.
Here's what I've explored so far:
Refactoring small dependencies and removing unused parts could go a long way.
React would impose discipline on the jQuery spaghetti code and reduce the need for a few of the dependencies.
Elm would go farther towards imposing discipline with its type safety.
ClojureScript would also impose discipline through a functional programming paradigm.
Except for refactoring, all of these potential solutions would introduce some additional complexity of their own in order to integrate with the Ruby on Rails back-end. React seems to have the most replacements for the current dependencies.
The safest path forward seems to be to start with refactoring and gradually introduce one of the functional languages or libraries. How would I refactor with this goal in mind? Would first refactoring to plain JS (i.e. removing jQuery) be useful?
Libraries/dependencies
Usually when I inherit a large project to refactor, the first thing to do is determine the core dependency e.g. what's the main library most of your custom code uses? From your list I can already tell underscore and jQuery are basically trying to do the same thing. Which one is the most optimized and fastest has been gradually leveled during the years. Let's assume for a second Underscore is still the fastest, you're still depending on jQuery for traversing and what not. Are you willing to include an extra library to gain micro speeds? The extra payload for each page is not worth it in my opinion.
Then Bootstrap is most likely your main CSS driver, however, it has some JavaScript abilities which might be used. Carousel, date-picker, drop-down, toggle some other widgets ... See if they are used (probably yes), if not, get rid of the Bootstrap js library. Keep in mind Bootstrap is still depending on jQuery.
Chosen/select are optional plugins. They're goal is most likely covered in Bootstrap/jQuery. Try to refactor them out.
Slickgrid is also a grid system. What's the benefit over the Bootstrap grid? Sounds like they refactored out Bootstrap. If it's used, refactor to a bootstrap grid to increase the common knowledge of the team.
Handlebars for templating. If you use the logic operators it's useful, otherwise you can easily find a small replacement function.
function renderTemplate(obj, template) {
var tempKey, reg, key;
for (key in obj) {
if (obj.hasOwnProperty(key)) {
tempKey = String("{{" + key + "}}");
reg = new RegExp(tempKey, "g");
template = template.replace(reg, obj[key]);
}
}
return template;
}
CKEditor/Raphael are libraries with one specific goal in mind => wysiwyg/vector. Best to keep those but lazy loading sounds ideal. Only include them on the page when they are needed.
// after the additional library was loaded ...
cacheObj1.on('focus', this.initCKE);
cacheObj2.on('click', this.initVector);
If you're server language handles <script> includes into the <head> tag, you can choose to keep simple script references, required by the specific page in mind. Don't end up with twenty DOM ready events inline, try to end up with just one ready event to initialize everything your project needs.
jQuery plus various plugins
Bootstrap
Handlebars
CKEditor refactor to lazy loading
Chosen/Select2 refactor to core lib
d3/Raphael refactor to lazy loading
SlickGrid refactor to core lib
Underscore refactor to core lib
Application/custom JS
Now the tricky part begins. How good are your JavaScript skills and how decent was the previous programmer? If you find a lot of jQuery selectors all over the place, chances are high it's not programmed in a modular approach. The hard task of refactoring every peace of code to something configurable begins.
The idea here is to have an instance or loader file which talks to your libraries. Perhaps a custom function file (which can hold underscore functions if you prefer) to use throughout your code. Prototypes or "classes" and singletons to finish it off. A nice post about refactoring if I may add with links on how to set this up. Then a grunt/gulp setup is nothing too fancy these days. Automation for JS(npm, bower) and CSS(compass, less) can be covered on the fly.
Conclusion
jQuery is most likely your main dependency. So you will start from scratch if you take it out. All the plugins you talk about is the extra fat on page load. The less the better, but sometimes it pays off just to RE-USE other functionalities like cookie scripts, json support, polyfills, ... the list goes on and on. Try to stick with one or two core libraries and clearly separate dependencies and application code.
Don't forget to bundle and minify ^^
Happy refactoring!
I got emscripten working, but it generates huge self executing files. Is it possible to make emscripten generate small functions that I want to optimize so I can copy paste them into my existing application easily?
Thanks!
I would advise against a copy/paste of some generated function from the inside of the Emscripten-generated output unless you have identified that bandwidth / compiling of the ASM/Javascript in the browser is a limiting factor that affects the performance of the application. Going down that route I suspect makes would make updates full of pain that I would avoid unless necessary.
What I think is better is to use the techniques in the Code Size section of the Emscripten docs
Some of the fairly straightforward ways are:
Using NO_FILESYTEM to prod Emscripten to not include some standard libraries (assuming you don't need them).
Using NO_BROWSER if you can
Using NO_EXIT_RUNTIME to not include some functions required when exiting.
Tinkering with the optimization flags, but according to the docs -O2 offers
the smallest and fastest output.
It is possible, but not well documented yet: you can use the --separate-asm flag. See
https://gist.github.com/wycats/4845049dcf0f6571387a
and
https://gist.github.com/kripken/910bfe8524bdaeb7df9a
for examples.
which of following cases is strongest with regard to client side (JavaScript) library referencing and loading.
Please note that I assume the web solution is well designed so that the components are well encapsulated
Also, just to be clear, the master page I am talking about could be a user control or anything that holds all library references and loaded at the site-load regardless of the content of the site at the moment
1 - include references (link href) for all custom (e.g. 3rd party) libraries in the master page.
it's arguable this is easy to maintain because all references are in one place.
it's also arguable that it's easy to perform library upgrades so you don't need to hunt within the solution where the library is referred to update it's reference.
2 - include reference to libraries in their specific user controls
shouldn't this improve performance as the website only loads libraries when required.
e.g. one can refer to the JavaScript libraries that works for maps within the user control that deals with maps with contrast to loading maps libraries even when there's no map on the current view.
This encapsulates components well. for example, a developer who tries to fix a bug in the map component will see all the libraries it refers to when he opens the map user control. This stops the need to go through the master page and see which libraries are used.
I don't think this is the right way to think about it.
The only reason not to load all libraries is performance. The debug reason you give is too minor to consider.
You can increase performance in many different ways. By far the easiest, most straightforward and attainable is to minify all your JavaScript into one file. You can additionally use a compiler like Google's Closure Compiler or Yahoo YUI Compressor to get a smaller filesize and faster execution.
If at this point you still have performance issues (that can be attributed to network latency) then maybe look into lazy loading your libraries.
This doesn't mean you should forgo the guidelines of dependency injection. Any good framework will offer you a mechanism for dependency injection. This should make switching to solution 2 at a later point fairly trivial.
Often with haxe we need to use existing non haxe code, so instead of writing externals we may want our haxe code to absorb parts of a system or add to it, a system where we can't assume a nice haxe setup.
For instance taking the js target suppose we want to add functionality to some existing javascript code, we can't easily control the entry point of haxe we have to inject functionality or classes within current js code. JS code which maybe too complex to rearrange into a really haxe friendly format. So one approach would be to mock up a class with stuff we need and then try to create some neko to automatically insert it and convert it, merging into the current codebase... but this is quite an open ended problem, and would differ with other targets.
So my question is what approaches have you developed for mixing in haxe target code within existing target code, for instance adding a haxe class within a js source, maybe using some neko to automate the insertion and rearrange the boot code needed for the haxe in the haxe class. But also interested in how you might approach this with other targets I probably have ideas for haxe flash but not say PHP or c++. Lets assume you can't setup the standard main boot structure, and on every publish you really would like your haxe code to be merged correctly back into the main non haxe project code when you hit the build button.
Tricky one but very important as solutions make it much easier to use haxe within more projects.
I've had only small amounts of experience with what you say, but here goes:
JS - I've used a custom Markdown library (variant of mdown), which was written in Haxe, in a predominantly non-haxe javascript environment. I tried to make it as "black box" as possible - the Haxe library exposed a static method using #:expose metadata, so I could call Markdown.convert(str); from anywhere in my Javascript. We found keeping it as "black box" as possible was beneficial, so the non-haxe Javascript knew what input to provide and what output was expected, but everything else was opaque.
PHP - I've done one or two projects where I did some work in Haxe, and had to include it on an existing PHP website. I found I could piggy-back off the existing websites sessions to check that the user was authenticated, and I set up a way for the existing site to provide a "base template" for the Haxe portion of the app, which Haxe then rendered into. Pretty hacky, but it did the trick and meant the template for both the Haxe section and the non-haxe section was updated.
Another approach for server-side could be separating out into user-facing code and an API. So perhaps Haxe sets up a JSON API, and the PHP talks to it. Or perhaps you have a Haxe website, and it talks to a Ruby/Python API etc.
So as you can see - I've tried to keep things pretty distinct. If Haxe can function in a relatively standalone manner, and interacts with other code by taking a particular input and providing a particular output, then things can behave relatively predictably. I haven't tried much further integration than that, I think the way Haxe works (using it's own class system and data structures etc) is different enough that tight integration could prove problematic.
I rarely mix code but here it goes:
for flash you don't need anything, if you add your swf lib made in another program you can access the classes from haxe.
for js is not possible without externs unless you want to use untyped. Or maybe you understood what Jason made, i didn't :)
for cpp is even worse, you have to use cffi which will end up in a mess of code, for samples inspect how nme extensions work.
never used java but i think here is simple
I have just been asked to describe the architecture for a large scale dashbaord style project that i will be working on.
I have bever worked on a application of this size and am a bit lost as to what to say.
Could i be pointed in the direction of any articles that may help me get started and hopefully finished.
I have gleaned the following information thus far but i am not really sure that it describes the architecture.
1) Use classes instead of seperate functions and each class or group should be contained within their own JS file
2) Prior to production there should be a compile step where said JS files are compiled and minified
3) Step2 does not have to contain all the files. Jsut the common ones to start
4) Use a classloader to load classes, plugins etc when they are needed. On research could jQuery's getScript function be used for this or even a jQuery plugin loader:
http://api.jquery.com/jQuery.getScript/
http://www.unwrongest.com/projects/lazy/
Am feeling way out of my depth at the mo so any help would be massively appreciated. Be honest, if the above is competely irrelevant then i guess i am in the wrong job :(
Everything you need to know can be found here:
http://addyosmani.com/largescalejavascript/
Create a library of loosely couple components that communicate through an application controller (e.g. event bus).
I would recommend looking at using ExtJS 4 for this. Its APIs and development methodology closely track what you would expect from .NET or Java for developing a large-scale desktop app.
Version four answers all four of your points. It has...
1) A system for defining Java/C#-like classes in Javascript that work almost exactly the way a Java or C# developer would expect.
2) Dynamic resource loading.
3) The ability to create a final product from the SDK which is a neat, compressed version which contains just what you need.
If you are to do this with pure Javascript, ensure you use some reference architecture in the job. What HDave pointed above is really good material. If you want a ready-made reference architecture as a project startup code, have a look at BoilerplateJS:
http://boilerplatejs.org
After some large-scale projects, I have compiled some of the learnings in to this framework. Look at the samples too. Some of the concerns you raised are already addressed in this codebase such as use of OO concepts, minification and optimizations, decoupled moduler design and many more too.