One of the primary ways I can think to speed up the user's experience with Elgg is to ajaxify page reloads and other actions. I've recently been working on a plugin to do just that for the admin area here: http://github.com/ewinslow/elgg-ajaxify. I would love for some of the devs here to install it and let me know what they think. The cool thing about this plugin is that I was able to get it mostly working without migrating the old Elgg views to Angular templates.

Some things to notice:

  • The document title is kept up to date (reflected in browsers's tab).
  • Javascripts + css are only loaded once you navigate to the place that requests them (e.g., jstree only loaded after you go to the developer tools inspector page).
  • The URLs are preserved using HTML5 history API so you can still link directly to certain pages.
  • Page will still load if you turn off JS.

Some known issues:

  • There is a brief blank page flash on first load 
  • Anything that doesn't use .live() to register the listener is probably broken (e.g. tinymce, drag/drop).
  • The right nav doesn't update correctly.
  • Plugins page goes blank after enabling/disabling/moving a plugin. (#fragment is confusing Angular's routing, I guess).

This plugin is built with AngularJS and RequireJS, both likely candidates for inclusion in Elgg core. Looking forward to your feedback.

  • Looks like it needs your custom dir-based hooks/events/actions config system.

  • I haven't got a chance to look at this yet, it is on my to-do list though.

    The downside to ajax is that a lot of the hooks and things I'm used to using seem to get bypassed - though js isn't my strongest suit (fine by itself, but implementing it in an elgg-ish way that is) so it may just be lack of familiarity on my part.

  • From my experience on implementing Ajax support in two of our Elgg sites : I used the HTML5 history API's and used the twitter model hash tag structures as fall backs (to support the browser back button). We fetched the enitre page as usual with ajax and extracted the required contents and created the output. By this method we dont have to create seperate views for ajax contents. Areas ajaxified includes paginations, owner block menus, filter tabs, form submissions and any anchor tag with particular selector names. The main issues we faced were loading the dynamic css and ajax files (the friend selector, lighbox css etc). 

  • I wonder: "speed up user's experience" & admin area... good idea or not? Is speeding up really important for the admin area? I would rather say it's most important that the admin area should work 100% stable - best would be not even breaking down when the rest of the site fails to work for some reason. Separate CSS/themes for the admin area and the rest of the site seems therefore a good direction. Ajaxification of the admin area maybe not, if it might end in higher or special requirements for plugins to work in the admin area (plugin settings etc.) or if it might result in incompatilibities for existing plugins (tinymce used by a plugin in the admin section) that would require them to be updated.

    Of course, getting more ajax into the rest of the site is interesting. Multiple users around here (as opposed to a single user or only a few in the admin area) would benefit from "speeding it up". Ajax plugin vs. ajax in core? I don't  have the knowledge to decide if this is a choice at all or if it's necessary to include the ajax stuff in core for it to work properly. If possible I would say to keep in as a plugin at least until it gives some wide benefit, is working stable - especially with widely used plugins. Give users a chance to test it then and provide feedback.

  • @iionly I was under the impression that ajaxifying admin panel is here only polygon for testing new libraries as it's simpler than typical site pages (less JS to take care of). Am I right, Evan?

  • @Paweł That's my guess. Admin pages tend to be more predictable in design = easier to apply behavior to across the board.

  • Would love to see AngularJS become part of the Elgg core. Very interested to see where this goes..

  • @Evan, Ajaxification of user side is what is needed not Admin

Performance and Scalability

Performance and Scalability

If you've got a need for speed, this group is for you.