With Umbraco 7 release imminent, the community will be eager to see its adoption. For those who have been following the progress of its development, the entire back-office has been re-built from the ground up – from UX concepts to the introduction of the AngularJS framework. (For technical details, see the Belle documentation website.)
The introduction of AngularJS is a major shift for Umbraco – it is also a bold statement – that web-technology is moving forwards and we are embracing it!
The consequence is that any 3rd-party back-office add-ons using WebForm-based DataTypes (or Macro Params)* would no longer be supported. The impact of this on future adoption is be unknown, we’ll wait and see how package developers deal with refactoring/upgrading their Property Editor codebases.
This isn’t all doom and gloom, personally I have high hopes for Umbraco 7 – my point is that technology progresses, despite the backlash; despite the risks involved.
Seeing the use of AngularJS in the Umbraco back-office, I started to think how else could Umbraco progress, beyond the boundaries of the .NET framework/MS-stack. Here are my predictions for Umbraco, not for the immediate future, but say a 5-year future.
(You’ll see from the Belle documentation website, node.js can already be used for mocking the data-layer.)
NoSQL (document database)
Following the idea of Umbraco being cross-platform, the database component is a dilemma. SQL Server has served us very well, it is a great relational-database – of course, it is the de facto choice on the MS-stack.
If we take a step back and look at the nature of Umbraco, how flexible the schemas for content & media are defined – this could be represented in a document database.
I don’t have any predictions of which NoSQL/document-database could be used, (there are so many! mongodb, redis, RavenDB – to name a few); but it’s a topic worth exploring.
The bifurcation of Umbraco
There’s a great post on Gadgetopia called The Bifurcation of Content Management and Delivery, which discusses the concept of separating the content-management (WCMS) from the content-delivery (WCDS). In terms of Umbraco, I think we’ll see a demand for separating the “front-end” from the “back-office”. There’ll be teams who will love the editorial experience that Umbraco offers, but are not willing to be forced to use the front-end technology/framework. One potential solution would be for the default Umbraco to ship with its own detachable front-end “runtime” – becoming even more of a Lego analogy.
Finishing up with a little note… these are all my own personal predictions, they don’t represent my company, (Umbrella), nor do I have any “insider knowledge” from the Umbraco core team or HQ. They are just things that I’d been thinking about and wanted to get them “out there”. Let’s discuss, collaborate and most of all progress! :-)