Working with the Alfresco presentation tier can be overwhelming. There is a lot on the table to choose from and more options are popping up frequently these days. But which path do you take? What are the pros and cons? This post summarizes my 2c on choice in web based technologies targeting Alfresco.
Alfresco Share
Given requirements targeting the desktop, Alfresco Share is the first thing one should look at. Share is an extensible, battle-tested collaboration tool which covers a whole lot of functionality. This is absolutely great and sets Alfresco apart from competition such as Nuxeo. You are given an application(!) which you can immediately(!) throw at people and get them going. Minor customizations can usually be implemented easily (= a few lines of extension code) – no need to build an application from scratch using a framework or roll your own stack. This is what I do all time, and I am glad to have this opportunity.
Share has been evolving slowly over the years, and Alfresco is trying hard to stay backwards compatible, save investments and prevent third party code from breakage. The flipside of this coin is that we see various approaches across disciplines (i.e. Forms, Templating, Resources) – deprecated and state of the art – within Share.
Aikau and Surf
Large parts of Alfresco Share are nowadays built on Aikau, which is (meta-)framework designed to work with Alfresco. Aikau itself depends on the Dojo and the Alfresco Surf framework which in turn depends on Spring MVC. Surf does not seem enjoy usage beyond Alfresco land, and Dojo does not seem to be very popular either. Unfortunate, but this hinders adoption regardless of the functionality offered. People mention Surf and Aikau provide unique features. To be honest, I am not sure what they are talking about. Alfresco Repository based features? Freedom to choose whatever JavaScript library or framework you are comfortable with? The freedom to choose your favorite library may turn out to be not so valuable once you start encountering conflicts due to overlapping functionality – i.e. resource aggregation and component lifecyle. Angular (at least version 1) is an example which does not play nice.
It takes time getting comfortable developing with Surf and Aikau. Documentation of the latter is in pretty good shape these days, the former not so much. Fortunately, there is fresh effort (thanks Bindu et al.) underway to fix this. However, I for one do not consider working Aikau a pleasure. I get things done, but I have issues with the IDE experience (Intellij in my case). Navigating through the code feels cumbersome – I feel forced to use fulltext search all the time. I may be doing it wrong, and I’d appreciate somebody demoing how to work fluently. Other than that, I feel there are issues which may never get fixed. The issue [ACE-2566] Improve development features for Share can serve as an entrypoint.
As a side note: Personally, I would like to see improved support for “large scale” extension module usage such as dependency management and discovery. I may be doing this completely wrong, but I find it pretty difficult to deal with a Share instance hosting 50+ (fine grained) module extensions. I’d be willing to join an effort if there is a chance to get this into the core distribution.
Finally, I consider a Maven based workflow to be cumbersome when working with JavaScript – no matter how you do it and whether or not you call into external Node.js based tooling.
More Choice
Alfresco recently announced they will be investing heavily in Angular 2, building a(nother) framework along with tooling for next gen Alfresco applications. This move will surely resonate with the broader development community. However it also raises doubts about the fate of past efforts.
Update 01.07.2016: Alfresco NG2 Components was released yesterday. I only had a quick glimpse so far, but I have no doubt that developer experience will generally be way better than Surf/Aikau. On the contrary, I fear now everybody will go after the new ?, build new apps(!), and doing so silently sacrifices mix and match plugin style composability goodness as we have it with Share, Surf and Aikau. Everybody runs Share. Adding extensions is easy. Introducing a new application is surely more effort.
Other people (me included) are poking around with React.
Choice is good, right?
Developer fatigue or choice paralysis, anybody?
To be honest, I think there is too much out there already. More than it does us good. It may be time to clean up the house.
Just to pick you up on a couple of points and to add some context…
“Large parts of Alfresco Share are nowadays built on Aikau”
This isn’t true (sadly). The header bar on every page, faceted search, search management, site management, content model management and some of Records Management is built on Aikau. This probably amounts to less than 5% of Share – the remainder of which is written in Surf/YUI2.
“Surf does not seem enjoy usage beyond Alfresco land, and Dojo does not seem to be very popular either”
I’m not sure how you arrive at either of these conclusions. If by popularity you mean whether or not people like something then that’s hard to quantify. If you mean by usage that definitely isn’t true – if you’re customizing Share you’re pretty much tied into Surf whether you like it or not. Whether or not Dojo is popular is a moot point because depending upon what you’re doing with Aikau you may never need to use it and beyond some basic boiler plate code you don’t even need to use it when developing your own Aikau widgets – it’s just JavaScript.
“People mention Surf and Aikau provide unique features. To be honest, I am not sure what they are talking about”
OK, here goes…
For Aikau:
1) It’s on GitHub (unlike the rest of the Alfresco code base) so you can easily contribute should you choose (I notice that you have chosen not to).
2) It’s released each week and bugs (regardless of where they originate) are proritized so you only have to wait at most 2 weeks for a bug fix (as opposed to around a year for an Alfresco Community fix – that’s if your bug even gets fixed at all)
3) It’s compatible with the existing Alfresco Share implementation so it integrates nicely
4) You define your pages as a declarative specification and those pages will naturally inherit fixes, performance/accessibility/styling improvements as you upgrade your library without you needing to do anything
5) The widgets are written to be fully themeable
6) The widgets are written to be accessible
7) Share pages built using Aikau can easily be customized through extension modules to add/remove/reconfigure widgets in a future proof way.
For Surf:
1) It takes care of all your authentication and security issues for working with Alfresco
2) You can use whatever JS framework you want (you’re not tied to WebScripts, YUI2 or Aikau) you can use as much or as little reusable code as you want. If you want to build a React client – you can easily do so by just defining a Surf page (to configure authentication) and use whatever you want in the associated FreeMarker template – Angular, React, whatever you choose.
Finally, you really need to take into account the size of Share and the number of Alfresco engineers working on it. It would be lovely if we could magically constantly reproduce Share every 12 months in the whatever happens to be the latest flavour of the month framework. It would be even better if each time we did it we had brand new designs that applied the latest and greatest styling and user experience practices. But realistically that isn’t going to happen – and even if we did, what would that mean for customers wanting to upgrade and preserve their existing customizations?
You don’t have to use Share, you don’t have to use Surf, you don’t have to use Aikau. There are benefits if you choose to do so, equally there will be drawbacks – “You pays your money and you takes your choice”… except in the case of OSS – you generally don’t “pays your money”, but it still is your choice.
Thanks for taking the time, David.
When looking at popularity, I mean generally in Webapps – way beyond Alfresco land.
The uniqueness of Aikau and Surf you are pointing out mostly stems from the nature of Surf, Share and the repository. I was not sure about that and only referred to the repository in the post.
I spent quite some time trying to make sense of libraries/frameworks beyond YUI/Webscripts and Aikau in Share and so far have not seen a single solution without serious drawbacks. I’d appreciate being proved wrong and see a practical (maintainable) demo of Angular, React or Polymer in Share – not just a basic proof of concept.
Again, I am more than happy with what I am given, and I will most likely be building extensions on top of Share for years to come. Just because it is the shortest path to solve business problems at hand. I guess that will stay this way in my foreseeable future.
About contributions: How come you say I have chosen not to contribute? I can assure you that I will scratch my itches. And I would appreciate handing maintainance over to you guys. No matter whether that itch is in Aikau, Share or the repo. I understand that you appreciate code contributions with Aikau and I am absolutely fine with the idea of providing pull requests. Not sure whether the situation is similar with Surf or core. However, there are at least things going wrong in those areas (e.g. ACE-4154).
Andreas – apologies, with regards to contributing I simply meant to the Aikau project. I know that you have tried to contribute to the main Alfresco code base in the past and have been frustrated by being unable to do so. This again highlights a benefit of Aikau (at least over other areas of Alfresco code at the present time) in terms of process if not framework choice.
No problem, David.
Unfortunately, most of the itches that hit me are either in Surf/Webscripts or core. The ones I have with Aikau seem very hard and/or risky to fix. And I don’t even know whether I am alone with them or not. The (Dojo) dev experience or support for async AMD operation are some examples.
I wish the situation was the other way round, and Surf/Webscripts/core had the github based process in place. ;)
The statement “This probably amounts to less than 5% of Share” starts worrying me. Lets just say “Large parts of Share are still built on Surf/YUI”. Looking at the fresh Angular 2 efforts, given the fact that Aikau has been around for a while and looking at Aikau migration efforts which went into Share recently, I feel things are moving very slow and there is nothing the community can do about it. Share is driving Aikau. People extend Share. If you find your itch is in Surf/YUI, you will most likely scratch it by using Surf/YUI instead of diving into Aikau.
OK… so it’s important to understand that this answer is not an official statement from Alfresco, but just to address the point…
Currently the stated direction from Alfresco at both BeeCon 2016 and on the recent Tech Talk Live is that the Share development and extension experience will continue to be based around Aikau, and that the Angular 2 effort will be aimed towards new applications.
Aikau has been around a while and has been and is continuing to be used by a number of projects within Alfresco (this can be verified by reviewing all the completed issues in JIRA). There were previously statements made that Alfresco would “Aikau-ify” more of Share and this hasn’t happened in the sense that existing pages haven’t been re-written, but it has happened in the sense that new pages have.
In fact the only new pages added to Share since 5.0 have been the search, search management, site management and content model management pages – and these have all been written in Aikau.
In terms of converting Share existing pages to Aikau it’s not clear if this will ever happen (although personally I believe it could and wouldn’t be actually be a huge amount of effort as the power of Aikau is really in it’s reusablity).
If people want to extend Share then they might need to work with Surf/YUI (unless of course the page they want to customize is one of the previously mentioned Aikau one or relates to the Share header which is also entirely Aikau). If they want to build new pages I think they could make fast progress using Aikau rather than Share, but equally they could make fast progress just using whatever UI framework they choose – that is the flexibility of Share as a platform.
If people do want to write new pages for Share I would recommend that they at least look at what Aikau has to offer, and if it doesn’t address their needs then to at least report the use case they could not solve. We really can’t prepare Aikau for use cases that we don’t know about, but we can address use case requirements as they are presented to us.
What I’d ideally hope for is a collaborative effort where the Community works together to improve the existing capabilities of Aikau to move it forwards – both in terms of new widgets/services or improvements to existing widgets/services or in providing useful blogging of their experiences.
I don’t think that Aikau is going to be disappearing any time soon though, especially whilst it continues to play and important part in the development of Share and Records Management and whilst we need to support people customizing 5.0, 5.1 and beyond.
Again, thanks for sheding light, David.
I started wondering how far Aikau reusability might stretch. I understand how AMD modules work – generally and in Share. Specifically, I was wondering how (if at all) it may make sense to use Aikau modules from another system. I have not tried it out myself, but the ClojureScript compiler does at least have support for AMD modules. Something along those lines may also work with other “flavour of the month frameworks” like Angular 2. ;). Aspects like coupling to Dojo may come into play as well. No idea how far Alfresco Angular 2 efforts are today, but I would be interested to hear whether you did consider Aikau module reuse.
I also understand that Alfresco is touchy when it comes to core code contributions. However, I would be interested to hear where WebScripts / Surf is headed. In the light of Swagger/Repo Webscripts and also the regarding the future of Share / to support people beyond 5.1.
I’m not 100% sure on the meaning of your question so I’ll try to cover all bases:
We’ve had some degree of success integrating 3rd party libraries that use AMD into Aikau – however, sometimes the libraries don’t implement it correctly and have a tendency to replace the “require” function which has the tendency to break things. We’ve had this problem with the ACE editor amongst others, but there is always the fallback in Aikau modules to declare “nonAmdDependencies” and Surf then loads them the old fashioned way. But we have integrated all sorts of other 3rd party libraries into Aikau (Dojo, JQuery, Sinon, Code Mirror, Gridster, Showdown, TinyMCE – it’s pretty straightforward)
We’ve also had some degree of success stretching the reusability of Aikau to other systems. For example, we were able to quickly write some authenticator classes for Surf to handle authentication against Activiti and were able to put together a simple interface for Activiti. In principle you can do this with any system that provides a REST API – again, just one of the many benefits of Surf – the problem is that you need to know what you’re doing and most people don’t and it’s not documented anywhere!
In terms of other AMD modules importing Aikau then that’s less likely to work – unless you do the extra work to ensure the i18n and CSS dependencies are loaded (which Surf takes care of for you).
There has been talk of integrating Angular 2 with Aikau – I’ve done a blog post on one potential solution for embedding vanilla Angular 2 components into Aikau, before that I also did some Aikau modules written using Angular 2 functions but discarded the idea because it was “still Aikau” and therefore not really of much use to the people that want to use Angular 2.
There’s also talk of embedding Aikau into Angular 2 but I’m not sure how well that would work and I’ve not done any prototyping in that area at all yet and have no plans to in the immediate future.
As for the Alfresco Angular 2 progress I have absolutely no idea because I haven’t been involved in any of the work in that area so I know about as much as anyone else does in the Alfresco Community, but I’m looking forward to seeing what has been done whenever it goes public.
As for contributing to Surf… I’d love to see Surf move to GitHub and for us to really spend some time improving it and weeding out the bits that aren’t required. We have done some little bits and pieces on it in the last year – and swapping out the aging YUI Compressor for the ClojureScript compiler is actually one of those things.
The problem with contributions is that we really would need to get regression tests fully in place to validate that contributions don’t break anything that Share is dependant on. Surf has some FVT tests – but not enough. Also, I’m not sure if there is the appetite at an executive level to heavily invest in Surf – this is just speculation, but I’ve not seen anything to suggest that there is.
However, with regards to the new REST API work we will be updating the Aikau services to support both WebScripts and the new REST API through a simple version configuration attribute – this is already available in some Aikau services.
Given that Share as an extensible general purpose collaboration will not be replaced anytime soon, I really hope we’ll get the chance to clean it and Surf up a bit, simplify things and push them a little further. Would be nice to get an official statement from Alfresco how far they are willing to go in this regard and if they would appreciate help from the community.
Regarding Aikau, I think it is important to understand how far reasonable usage goes – assuming one is aiming at a maintainable product. I have seen quite a bit of usage I’d consider way to far. Furthermore, I think it is also important to be aware of its implicit AMD extensions (i18n/css) and its glitches. The fact that it makes use of AMD does NOT mean everything documented in a (Dojo or another) AMD usage section works as advertised.
Well, that’s not quite accurate – everything documented in Dojo AMD usage works because they’ve implemented AMD correctly. My point was about libraries that have attempted to implement AMD and done it wrong (mostly because of overriding “require” in the global namespace). Any correctly implemented AMD library can easily be integrated into Aikau.
Well I guess it may depend on ones understanding of Dojo AMD documentation. ;)
Specifically, I had asynchronous module loading in mind. Tried it out aiming at better IDE support – source maps and hot swapping JavaScript code. Turned out it does not work reliably and it’s not easy to fix.