I've been having the following conversation with several people and I thought it would be easier to just put my thoughts down to share. This blog is going to be mainly focused on the next steps for Umbraco which is moving to .net Core and hopefully a new back office and what effects I believe it might have on the product, some good/some bad.

As a mountain biker one of the best bits of advice I was ever given was to look further down the trail when going fast. There is no point looking at that big pothole/rock right in front of you as there isn’t enough time to react or position the bike to avoid it. So lift your head up and look further ahead to give you more time to pick the best line, the smoother line, the faster line and sometimes the fun line with a nice jump in it :)

So .net framework (as we now have to call the artist formerly known as just .net) is the framework Umbraco is run on is now considered “fully baked” by Microsoft. Its done, no more development will come its way. Microsoft have for some years now been working on their next play thing that is similar but also very different. I’ve not really had my finger on the pulse of .net Core mainly as it seemed like shifting sand, every alpha or beta release that came out seemed to have too many breaking changes so keeping up seemed like a fools errand. So I never understood the calls from some people in Umbraco land for the last 4+ years asking “what about .net Core?” at every opportunity it just seems like a waste of effort, kind of liking asking “yeah but when are we going to colonise Mars?” when we haven’t even been back to the moon yet.

However all of a sudden, like a rock on the bike trail that I didn’t see, .net Core is here with a jolt and it feels a little like I was sleeping on the job. Net Core seems to be everywhere and it is the new craze causing some new problems:

• New developers don’t want to learn the old “legacy” .net framework so this limits attracting new talent.

• Cloud hosting providers are leaning towards containers which .net Core supports well (so these will get cheaper) over virtual servers which we can expect to get more pricey on “legacy” hardware I guess.

• New OSS projects that add functionality or code we could reuse are less likely to be written in .net framework as its lifespan is considered to not be as long as .net Core.

So the writing is on the wall for long term web site happiness, it is time for us developers to start to retool and get reading up on .net Core. It is also time for our favourite CMS to come up with a plan on how to go about getting Umbraco running on .net Core. The .net Core event horizon looms closer waiting to suck us all in.

Thankfully this isn’t something that Umbraco has just started to think about, they have been doing some work on this for a few years on and off. It was the reason that V8 was first proposed, a stepping stone to getting to .net Core. It removed a lot of older code and technology that no longer had to be supported (or couldn’t be in .net Core) so the surface area of what needed porting/touching was greatly reduced. However it was more than just the “tidy up” version as it introduced some new features and breaking changes which is what made it a major release. HQ have also setup a new team (it’s all about teams at the minute at HQ) who are over-seeing some of the work/discussions on how to actually go about getting Umbraco on .net Core in a reasonable timeframe and with community involvement. From now on I’ll refer to the .net Core version of Umbraco as vCore for ease.

I’m told the aim is to have something out for vCore by the end of the year, I think that it is more likely to roll on until March 2021 sort of time which would be more likely as it gives more time to get it done yet still released before Code Garden the annual Umbraco Conference in May (marketing baby!). Even then I would expect it to be more like 2022 before it's battle ready. Once released to no doubt much whooping and cheering we will enter a funny time, a fork in the road if you will. There will be two versions of “the same” Umbraco alive at once...effectively offering the same functionality (so far anyway) and giving the community a choice as to which to go for. This could pose some interesting problems/discussions/times for us all.

V7 sites are still around (and are still being made for fresh sites) and V8 is likely to stick around too. The problems ironically will likely come of the old timers, the “white middle age men who know it all”, the ones that run the IT departments/hosting of our clients and want to stick to what they know, the ones that want to sign off on known tech and the developers who want to work in a framework they can be productive in as they have used it for 15 years, the ones that hire those developers and know the budget doesn’t allow for much venturing into the unknown.

For instance which version do you start a new site on? The tried and tested .net framework that you know well, the team is quick to work with or the new .net Core one that you are still pretty green on and the code base itself is green too. We've all got to dip our toes in the water some time, but is this the project to do it on? As usual it depends on the site, how long is it going to be alive, size of it, etc. But for each site we will now have to make that choice.

This isn’t new of course, we’ve had to do this for the last year between V7 and V8. But they offer different features with V8 having variants, nucache, content apps, etc but they are the same tech (well framework) underneath. V7 isn’t actively developed anymore (more on this in another blog post) so that sort of makes the case stronger for the switch to V8 especially now it has had a year out in the wild to mature. So V8 would be the right choice for future proofing if you had to build a site today but even then...it depends.

This won’t be the case for vCore though, HQ will have to keep developing V8 .net framework version AND the .net Core version at the same time as not everyone is wanting to or even can jump ship to vCore overnight. That is going to add some headaches to the mix. Increased development overhead, a fragmenting of training, how to manage bugs and pull requests, documentation confusion. I’m already getting this when I’m searching for anything to do with .net in general seems to return Core stuff first these days or makes the assumption I’m using it while not always making it clear. Then we've got training materials that will need creating and all that jazz, plus...what about Umbraco Cloud? I can’t see them launching without having it up and running on cloud. This might be an easy thing to do or not but it still needs doing (probably needing some new container magic?) and then supporting which means developers not working on other CMS related things.

Of course in the future everyone will eventually have to make the switch to vCore but in the short to middle term what do we do? For a while we will live in a world where there are 2 versions of Umbraco that are functionally the same but running on different frameworks. This assumes of course that they are functionally the same and from what I’ve read that is the initial aim. They will diverge at some point of course, HQ will have to switch all new developments to vCore (it is after all the future) but they probably don’t want to do that too soon until the market is ready for it when its robust enough, there’s enough support out there, everyone is trained up on it. This is the curse of a well established project I guess, you come with some baggage/user base and you take time to react/move. You can’t just start a fresh as a new .net Core CMS, you have to do it in a way to bring your audience/market/customers/users along with you if you want to keep your traction.

HQ could drop V8 development pretty quick if they wanted to but it would be self harm to do it only 2 years after it came out and forcing everyone's hand to either make the switch or just stick with V8 in whatever final state it is in (as it would likely go into security patch only mode like V7). Lots of us have migrated sites to V8 to ensure a continuity of features and fixes, we can’t keep getting that signed off every 2 years if we want to keep the clients nor can Umbraco keep forcing that if they want Umbraco to be on the short list with those clients, after all “if we are rebuilding anyway we might as well look around” is a fear all us agency folks have in the back of our minds when “rebuilds” are mentioned.

Package developers will once again have to rework their packages (some still haven't for V8 yet) to work on vCore which is all done in spare time that they might not have. I’d like to think that with the new packages team (told you it is all about teams) we won’t have the lack of packages in vCore that we had when V8 launched so the gap between the two will hopefully be narrow.

So let’s assume we now have something like 2.5 versions of Umbraco alive and well with V7 in security patches only mod (that’s the 0.5 bit btw), V8 and vCore have the same features mostly and this is the current expected holding pattern. Oddly we won’t have gained a single new feature to differentiate between the versions from all that work, just paved the way to move forward.

Looking further down the trail though we have some more hiccups that are coming along the way, more potholes and rocks to avoid or hit square on.

There is the new block editor that is meant to be getting worked on, it will be developed within the existing back office which is still on AngularJS. This is shared between both V8 and .net Core so it can be rolled out to each, woot! That will be ready and rolled out before the year is out I suspect so before vCore itself is done.

But about that back office...it's getting mighty long in the tooth, 7+ years its been running and added to. It’s been nearly 2 years exactly since LINK I wrote about the idea that we should be thinking about, planning and doing some ground work/tidying up to ready for a rebuild of the back office to a new tech stack. Sadly in that time nothing of substance has been done, promised or resolved as HQ have been working on other things like finishing and releasing V8, Headless, Cloud and now working on .net Core. At some point though a choice is going to have to be made about the back office ideally after a good audit has been done of what is there and what is actually still needed. All the arguments used to encourage the shift/work to vCore can be repeated about the back office (its old tech, no one wants to learn it, difficult to find developers, it’s a dead framework who’s official end of life is about a year away). The rebuild is not a choice we can keep pushing back. Marketing wise nothing shouts legacy enterprise like shouting about being on the latest framework while also being run on an obsolete one.

So if time is being spent on the new block editor I hope its done in such a way that its easy to port to a new framework otherwise its work that will have to be redone and then we will again have multiple versions of it to support and document.

Let’s assume that at some point the back office needs a rebuild or Umbraco risks just falling behind too far. Which version of Umbraco do you build it on and when?

I’m told HQ are keen to get vCore out quickly (but not rushed). They also don’t want to roll it out with a new back office as part of that initial release as that is thought to be too much for them or the community to cope with, vCore is a big enough job as it is. So where and when does it get done? Do we try to roll it out on both V8 AND .net Core? This would seem fair to both versions given their youth but also a technical headache and would also be a breaking change for both versions...we would in effect now have 4.5 active versions of Umbraco out there!

That doesn’t sound sustainable. So do we have to pick a version? Yes we probably do. Logically that version would have to be vCore as its the one with the best future ahead of it. That causes a problem though as no doubt since vCore got released some sites will have been made on it already and will include the old back office...so we now have 3.5 different versions of Umbraco situation and we’ve just killed off the upgrade path for 2.5 of them. Additionally those package developers now have to rework their packages AGAIN to work with the new back office in vCore version with the new back office. This is getting painful.

So how can we avoid that? I think we’ve got three options I can think of:

• Easy: Punt it into the future, kick the can down the road. Repeat “there is nothing wrong with the back office, it works for now” a lot, live with it as it is and hope I stop writing blog posts about it. Maybe it can be rolled out in the vCore version in 4+ years time and hope we don’t lose market share in the meantime.

• Bold: Decide that the back office should be included as part of the initial vCore release and together it just becomes a new thing as vNext. That would make it attractive and look like a complete “upgrade” of the tech and worth the jump and could open up the door to lots of new features. Package developers only have to rewrite one more time and then its “done” for a while. But this does cause some headaches and would likely delay the release of vCore (and so miss Code Garden!). Plus if its a totally new stack is it really Umbraco? Would it be worth looking around at other options if it is that different?

• Tricky: Come up with a way to roll out the back office to both. How about we separate out the back office from the rest of Umbraco? API’s would be the only way to get the back office to talk to the Umbraco data layer itself. The existing back office we change to use the new API layer (its mostly done like this now anyway). We do this sooner rather than later so that it’s in the vCore version before it launches. Then we can work on the back office “out of band” almost as a separate project. Create a whole new back office that talks to a consistent API. Then give you a feature toggle to opt in (or install via nuget or npm or the package manager) to the new back office on existing V8 sites (sorry V7 users, its not going to work that far back) and it would be included as default on vCore. Packages could cause some headaches unless we are smart with some compatibility layers of some sort or upfront about upgrading them so they work before its release. By separating it we can work on it at our own pace while getting it to work with both versions. This also makes it possible for everyone and their dog to get carried away making their own version of the back office in the framework of their choice over a weekend (Matt, I will be expecting a VueJS version done and dusted by Monday morning) and hopefully end the “framework choice wars”, everyone wins. It’s going to take some juggling though.

Being pragmatic I’d be quite understanding of any of these options coming out as the winner, they are all valid, but I think they all have different knock on effects to the project.

Personally I fear that the first one will win if we aren’t active to stop it, we simply do nothing for now and slowly start to shrink the user base rather than grow it (worst case obviously). The second is probably the safest choice even though it’s marked as “bold”, it would lose some fans but at least it gets the pain out the way (again) in one go and its ground that we’ve trod before. The last one gives us options at the cost of some work up front, it’s probably the one I’d like to explore the most and potentially keeps all users happy and making the project look like it’s giving a bright planned future rather than just playing catch up.

So that is the landscape further up the trail that I predict. Another big version might cause more headaches than we want if we aren't careful with the timings of the developments and releases. How we avoid these bumps in the road I don’t really know, I’ve just looked down the trail and spotted them. I’d love to discuss the back office and the ideas I have for it in more depth but that will have to wait for another blog post (or take a look at the latest issue from Nathan Woulfe https://github.com/umbraco/Umbraco-CMS/issues/7718).

In the meantime I think we have a greater need. That of needing some people to regularly focus on the back office and have it in the front of their minds rather than it be something we mutter about at meet ups but don’t actually do anything about. Or something we add yet more features to without thinking about if we should clean it up a bit first. In short I think we need a Back Office Team assembling with an internal champion (or two) from HQ to fight for it from the inside. It is not a problem that will fix itself and it is a big enough issue to need input from the community and HQ if anything is going to get resolved with it. Trouble is how do you even start a team? And how do you pick who to put on it? It will also need a lot of managing and a lot of work, ideally very small “achievable in the lunch break” kind of work, but it is doable as long as we don’t just end up arguing about which framework to use.

Together we can look further down the trail, pick the best line, the smoothest line, the fastest line, the fun line with a nice jump on it :)

We could have let this just quietly slip under the radar and let everyone assume we were still a Gold Partner and pull a fast one but that is not really our style and if anything we think 10 years of support is worth celebrating rather than going unmentioned. Ten years is a long time in any business and a lot can change. When we first signed on we were one of only a handful of UK Gold Partners and were very happy to support the project (and the developers who work on it) to help it grow and thrive. In return we would be giving a bit back to the software that [helped us deliver award winning sites](/journal/news/creating-an-award-winning-umbraco-site "Creating an award winning Umbraco site") and let us pay our mortgages.

We like to think we've been more than just a Gold Partner, more like a "Platinum Partner" in our heads (we can dream right). We've always done more to promote the product and the community through our [packages](/packages "Packages"), [blogs](/journal/dev-talk "Dev Talk"), [speaking at conferences](/speaking "Speaking"), supporting Skrift the Umbraco Community magazine with our staff time each month, improving the training via feedback, attended round table discussions, promoting/discussing privately at meet ups galore, hosting [Offroadcode Garden](https://www.youtube.com/watch?v=7UUTAiuUXKE&feature=emb_title "Don't ask...") and submitting 100's of bug reports and feature request over the years. We've certainly not been a silent partner simply paying for a logo. Fear not those extra-curricular activities will continue no doubt.

We never really became a Gold Partner for any perks or trade offs, it was just nice to support people who had become friends with other like minded Goldies (yes we really call ourselves that...) and as a bonus it did have some positive side effects:

• It opened doors to government jobs with the NHS and the education sector that insisted that any Umbraco work had to be by a Gold Partner thus helping us stand apart from the crowd. Sadly in recent years in the UK at least cut backs due to austerity and Brexit mean that this constraint has being dropped in an effort to save money by opening the field or moving the work in house.
• Clients liked the comfort that hearing we had direct access to HQ for support but in 10 years I think we only called on it a handful of times and often resolved it ourselves one way or another. We are after all experts in Umbraco not just subscribers to a support service on our clients behalf. Besides in the early years HQ often had their hands busy so their turn around times weren't always a good fit for on the spot trouble shooting of custom implementations of Umbraco, that is after all more the kind of thing we are good at...so we did it instead.
• Overtime the perks on offer from HQ to Gold Partners increased with various discounts on training and the new products that they released. However for a company of our size (we are all trained up already) and focus (a handful of medium-large sized complex sites per year with their own hosting) we couldn't really make the most of them to warrant to continue to pay for them. This starts to add up against the commercial realities of being a member when you see other better positioned Gold Partners do much better from the shared perks on offer. We either need to change our business model to suit the opportunities or stick with what we are good at and enjoy.

The number of active Gold Partners has grown 300%+ (there is 30+ of them now in the UK and more being added) excluding the churn rate of those that jump on board and soon leave. This means more competition for work. What was once something that made us stand out is now almost a given in the market place. We will instead have to lean on our 10 years as a "former Gold Partner" and more importantly our experience building great sites in a friendly forward thinking way with this wonderful tool and the reputation that we've built up doing so.

Since we began this journey Umbraco's staff numbers have increased by 600%+. The portfolio of products on offer with Umbraco has grown with it too (4 new major versions, Headless CMS, Umbraco Cloud hosting, Deploy, etc) all of which bring in additional revenue intended to make Umbraco the company self supporting. I think that means mission accomplished from our side of the deal. The average length of time for a Goldie to stay a member is 2.5 years apparently (figure taken from the last Gold Partner summit in London last year) so you can't say we haven't done a good stint.

It's our hope that by being involved as early as we were and for the length of time we have been we have in our own small way helped make it look like a club you want to be in, one to be proud of, that was fun, supportive and kept going the original ethos of what it means to be a Gold Partner (or any partner) alive while the project has grown. Luckily there are still many good partners (old and new) who up hold and continue these values and traditions who are staying in. And that is how we shall leave it, 10 years of support for a wonderful product that we hold very dear. Time for others now to take a turn at the front and keep the product moving forward while we sit up and take a bit of a rest and focus on our client work for a bit until this Brexit mess is over with...

Hence, the Doc Type Grid Editor: Reusable Content Extension (that's a mouthful), or the Reusable Content Extension for short. When installed on your Umbraco site alongside the Doc Type Grid Editor, it extends the grid editor tool to let you import, export, and link your grid editor content to other nodes on your Umbraco site.

(An example of the steps to exporting grid editor content to its own content node.)

With this extra functionality, our clients' editors find it far easier to keep certain rich content that might be reused in multiple parts of the site sorted in their own organized container where they can edit once before importing in elsewhere, either to keep as linked and synced clones or as "content templates" to make small edits to after import.

Version 1.0 of the Reusable Content Editor was compatible with v0.4 of the Doc Type Grid Editor, but we've just released Version 2.0, which is fully compatible with the newest version of Doc Type Grid Editor and Umbraco 7.15. If you were interested in the extension in the past but were using the newer version of the grid editor, you need wait no longer!

The DTGE: Reusable Content Extension can be downloaded from the Our package repository or you can go to its code repository on Github if you're looking to get the package source code for further noodling around. Enjoy!

A Genie developer is one that will only do exactly as they are told. There is no critical thinking (or if there is its kept internal and never shared with the client) or clarification of the request or its knock on consequences. What you ask for is what you get.

Very similar to the Genie from the old myths, it goes something like this, Aladdin rubs the lamp and is granted 3 wishes:

Aladdin: “Genie make me the richest person in the world!”

*Poof! Genie turns everything into gold...everything*

Aladdin: “But..but...this isn’t want I wanted...I can’t eat gold food, my family are all statues…”

*Genie shrugs*

Genie: “But master I did as you asked. Are you not rich?”

Aladdin: "Put it back!"

*Poof! Everything returns*

Genie: "Now you have one wish left..."

We've had clients who have had work done by agencies outsourcing to Genie developers who we then take over from. Its always fun to hear their reaction when quality work gets delivered or we ask for clarification to end up at a better solution. We've worked with Genie Developers directly too.

How they end up being like that can be tricky. It seems to be a mixture of lack of experience (or skill), excessive process and cost/time pressures from their company. Alternatively it can come from aggressive "we pay you to do as we say!" stance from some customers who don't like paying for them to dig deeper in an effort to control costs at obvious expense of quality or care, never let spreadsheets solely dictate what "good" looks like.

If you don't give developers the time and space to do critical thinking they have to end up doing simply what is asked and no more. Often what is asked for is not the real problem that needs solving and additional insight arises as the problem is worked. If this pressure becomes the norm then good developers leave. Good developers like being creative and actually feeling like they are fixing real problems, not what someone thinks is the solution to a problem which isn't.

Someone made an accurate diagram describing Scrum! 🥳 pic.twitter.com/UR5q4q1ciD >
— Martin Konicek (@martinkonicek) July 6, 2019

How to fix Genie Developers?

If your a client of an agency that suffers from Genie Developers? Then that is simply the way it is, that agency is probably price lead (or profit lead) and its a net result. You could ask to get someone else more senior on the case but it will cost more and that senior person will likely be overworked or indeed might still end up being a Genie Developer. You might have to go elsewhere.

If you have Genie Developers within your own agency/company? Then you have two options. The first might seem obvious to just get rid of them and lay them off. That might be the right choice but first look at the surrounding environment, could that be the cause of their actions? Are you pushing too hard to "get work done" rather than "get good work done"? Are you chasing the wrong metrics? Are you asking for more through put rather than more quality? Do they have the training and systems in place for them to do their job well? Are they over worked? Are they working on a "difficult client" who requires some hard boundaries. Explore these angles before you simply sack them, could be they are more likely to be causes than you might care to admit.

If you are a Genie Developer? Well done for recognising it. Either find an agency that rewards that way of working (they do exist) or change how you like to work. Ask for more time on jobs, ask to speak to the client directly to get to the bottom of the real problem, start adding some value rather measuring your work day by how many issues/cards you can complete. If your boss won't allow you to do that then maybe its time to look elsewhere and expand your horizons.

When we get a programming problem, as developers we want to rush in and solve it straight away, to get to the good bits. Rush to the finish line so to speak. It can be dangerous though, all too often you don't have all the details and a simple problem on the surface can turn into a horror story pretty quickly once you start unpicking at it. Now you've rushed in to what was a simple problem it might already be too late to easily put it right.

There was a documentary I watched recently about the Navy SEAL team who went in to "take out" Bin Laden. It was interesting to watch as it had EVERYONE on it from the President down. During the strike they landed 2 teams of action men armed to the teeth and they had 30 minute to clear a compound that they expected to be a death trap and somehow get out of there. The most striking part for me though was how they went about it. I sort of thought they were so highly trained they would run in and with some sort of spidey sixth sense avoid any bullets and just blast everything to bits with speed and precision. Instead they took it really steady.

They did it using well practised purposeful drills. Walking between buildings and clearing them one room at a time. Each team member covering the other and improvising when required. There was no sprinting and jumping through windows or running around like a headless chicken, no running through doors assuming everything was clear. They instead purposefully slowed there pace and as a result did an amazing job. There were no heroes running in to clear room single handily, everyone moved as a team.

The mantra they kept repeating was simply "Slow is smooth, smooth is fast".

Your brain wants you to think that speed is what is important to get something done fast, but its not. Not tripping up can do wonders for how fast you get from point A to B, going slowly really helps you avoid anything that might trip you up. Makes sense really. So the next time you are debugging on a live site, take your time just to be sure about your next move. Get into a "known state" (know that room is clear by lobbing in a grenade...well something like that?!?!) and double check everything before jumping into anything to avoid wasting time on red herrings and false leads.

Of late in the office I've been heavily dropping this new mantra. When quoting for work, when designing a new API call, coding up a new class and especially when debugging..."Slow is smooth, smooth is fast". It’s been amazing to see how much more we have got done by not trying to do so quickly. Once you allow yourself (or as the boss I allow others) to take their time our error count reduced and number of red herrings followed during debugging plummet. We are building better software as a result, slow down and get faster, who would have thought it?

It makes sense once you try it. Kanban works the same way, limiting work input increases work through put...weird yet it works. Give it a go and see if it makes a difference to you.

You can read the first two posts here:

• Getting Umbraco V8 up and running - how to get the recent alpha release of V8 up and running locally as a developer.

• The V8 event horizon - how we need to ideally not get too distracted with V8 until its nearly ready.

There is an excellent discussion going on about some of the inner workings of V8 at the minute over on the issue tracker, you don't need to know the details btw but it raised some interesting points in the comments from HQ. There is one common theme in all the answers though, "if we had more time then we could do X but for now Y will have to do". Now I'm all for pragmatic solutions at the right time and sometimes "good enough" is just that but in this instance any of their work is going to effect 10,000's of developers, customers, users.

This got me thinking, why don't they have the time? Why are we (both HQ and the community in our lust for it) "rushing" to get this release out? It seems to me that V8 has been talked about for the last 2-3 years but its only since Code Garden in May 2018 that some actual shape of what V8 is and isn't was announced up on stage. We now know what its hoped it will be so to me the clock only really started ticking since then, in that mind set should we perceive it as V8 has only really just been started rather than starting the clock about when we first got mention of it?

This situation reminds me of when a client asks for an urgent quote (they are always urgent) and a delivery date. They then disappear for 8 weeks before coming back and giving your the green light and assume the delivery date still stands despite their delay thus compressing the development time you had to do the job! What about scheduling that work in, don't they think of these things, I mean we might be busy. Umbraco is no different, its not like they haven't been working on other things.

What could be more important than V8 I hear you say? Well turns out quite a bit:

• A new way to migrate content between instances in "the cloud", aka "Deploy". This took almost a year to write and has replaced the old Courier system on "the cloud" sites. The previous system to doing this (Courier) was a major source of issues and gobbled up support time and maintenance regularly. Rebuilding it from the ground up made for a much more stable long term solution but that took time to put together and needed at least one of the Core developers at HQ to work on it for a year.

• A new CTO at Umbraco, Jacob joined at the start of this year and has been taking his time to get to grips with the setup, community, etc. and has been making changes to make things move a little faster in a managed way. That takes time to get right. Before Jacob we had Shannon in that role which mean he couldn't code anywhere near as much as he would like (and if honest as much as we would like too) so the project was another player down for over a year.

• Headless CMS, Umbraco saw an opportunity to move into the newly emerging Headless CMS space and chose to carve out a slice. By coming up with a Headless offering they can sell more cloud accounts, attract new developers and agencies and increase the awareness of Umbraco. All important aspects to the future of Umbraco and those that use it to earn a living (that's you and me btw). This was a worth while distraction and hopefully a profitable one.

• Finally there is this little thing call V7 which has been having multiple incremental releases of polish added to it. We've almost become so used to it working and getting better each release that I think we've taken this a little bit for granted. Excellent work by all those at HQ for making such a rock solid solution and continually making it better. Its often not seen as glamorous work making something a little bit better over and over but its an amazing sign of the maturity of the product and the team behind it. Chapeau!

So, if we think about it, V8 has only really...sort of...maybe...started to take shape and be worked on with purpose a few months ago. So with that in mind when do we think it should be ready for release? Or put another way When do we think it would be ready to build a real paying customers site on?

Although they sound like the same question they are two different ones. The first is "when can I as a developer download it and start playing with it" is also know as the "when can I rebuild my own site on it to test it out". The second is "when am I happy charging money for building on it". You need it to be "good enough" that you aren't wasting time with errors that will "be fixed in the next minor release" or with new ways of working that you aren't ready for yet otherwise you become inefficient or have to look after a site that needs a lot of support; neither of which make you very happy or profitable.

Ideally we would like the gap between when its ready to play with and when its ready to sell to be as short as possible but when should it be ready? In the one hand we have HQ developers wishing they had more time and in the other we've got developers, sales people and clients wanting to get their hands on it as quickly as possible. But do they? Should they? Should we get it ASAP or should we wait and end up with a better product at the end, one that "just works" and we can get on stream with it building real client sites asap. Which would be better?

I've got my own views but I didn't know what the community thought and it seemed neither did anyone else so I thought I'd thrown some attempt at science at the problem by putting it out to a vote (well three actually).

First up is Developers, they tend to always want to play with the shiny new stuff, its them that should know the true benefits of the changes and at the end of the day they are the ones who will be building new sites on it:

Umbraco DEVELOPERS, When would you be happy with Umbraco V8 being released and safe to build on?
— Peter Duncanson (@peteduncanson) June 11, 2018

A clear signal there to "take your time and get it right".

Next up same question and answers but this time aimed at business/sales/marketing folk. They have to sell it, they know if a new version will be a deal winner or not when in a pitch.

Umbraco SALES/BUSINESS/MARKETING TYPES, When would you be happy with Umbraco V8 being released and safe to build on?
— Peter Duncanson (@peteduncanson) June 11, 2018

Another clear signal here that rushing isn't going to help anyone, trying to sell a rushed release is always going to be harder than selling a solid release.

Last question was a little different, rather than asking when you would be Happy to have it released this one when do you actually Expect it to be released and anyone could jump into this one (I said this was an attempt at science because by adding the extra line about 2020 in this poll I sort of made it a leading answer compared to the other questions, forgive me).

Umbraco EVERYONE, When do you actually EXPECT Umbraco V8 will be ready #lastOneIPromise (reminder by the way, 2020 is only 18 months away...I know right?!?!?!)
— Peter Duncanson (@peteduncanson) June 11, 2018

Again there is a favouring of taking your time on this one, although "within 12 months" has the most votes "18 months" and "when its ready" are not far behind!

I found the result quite surprising. I would have thought that everyone would want it as soon as possible because once the genie is out the bottle you want to get making some wishes right? Well turns out...no. The biggest take away was 65% of developers and 45% of marketing/business types were happy to wait until it was ready, effectively take as long as you like but get it right. But the final poll gives us a better feel maybe, when do you EXPECT it to be released, in which 36% thought within the next 12 months (so probably Code Garden 2018 next summer then). But if its not ready by then...it seems there is some allowance to hold it off and wait some more to get it right, I think it all depends on how expectations are managed.

I hope you found those stats enlightening. Personally I think HQ should have as long as they need to "get it right". V7 is an amazingly solid bit of work and I'd be happy to keep using it in the meantime for as long as need be. This is assuming it still gets some development love in the meantime too. As per my V8 Event Horizon post we will do ourselves no favours by not maintaining and strengthening V7 along side V8 development until we and it are ready to switch. We know V7 well, we know it works, we can produce stable, easy to maintain sites that scale with it right now. By realising that we might have to wait for the V8 goodness and for HQ to see that there is slack externally to "do it right" then we might all end up with a much better product at the end of it.

A caveat to this of course is this is not licence to take forever, or licence to put EVERYTHING ever wrong with Umbraco right in this version. That is not what V8 was about. They still have to ship at some point and its not a rewrite. V8 is intended to be "the tidy up version" were we strip out all the old stuff from V4 that is still floating around, swap out the odd core feature (hello NuCache) and pave the way for ASP Core (which some of you seemly can't wait for). If they need a few extra months or more to better lay the foundations for those paths then the view of those in the polls and my personal view is take it if you need it, we trust you, the product will be better and stronger as a result and in the meantime V7 continues to kicks ass.

The hot topic this year was the forth coming Version 8 (aka V8) which would be released...erm...well...sometime...soonish...maybe?

Depending on who you asked (and when you asked...*hink*) when the final version would be released the answers ranged from before the end of this year to even the end of next. I took this unknown vagueness to be a good thing, it means they aren't rushing it and want to get it right. However when you release an Alpha live on stage it does sort of start the ball rolling in peoples minds that a release is "coming" and that in itself is a dangerous expectation to start in motion if you aren't ready for it and the consequences.

I tried to describe this within the office like flying a space ship towards a black hole...hear me out.

Once you set a course and start towards it you can still get stuff done, there is a while to go until you "get there" but as you get closer the gravity of the black hole builds and pulls your ship closer and close and faster and faster towards it. The pull get so strong that at some point its next to impossible to steer away from it, it sucks you in and at some point you have to cross the Event Horizon, this is the point of no return...after this the ship, your crew and you will all become part of the black hole...

Foot note: I don't mean to say V8 is a black hole in a bad way but the appeal of it has the same gravity.

With the release of the Alpha of V8 we have set course towards this singularity. We are currently still some way away and there is plenty we could be doing while we travel there (securing cargo and checking the escape pods). At some point in the near future we are going to reach the Event Horizon of V8 and at that point there will be no turning back, there will be no more V7...we will all become V8! That all sounds a bit weird...let me explain what I mean in real terms.

Now the course has been set some things are going to start happening, maybe not today but soon and we need to be aware of them. We need to be aware to possibility delay them or at least minimise the time that they can effect us all.

From a developers points of view these will seem to be the biggest issues we will face until we cross the Event Horizon:

• Pull Requests and fixes for V7 will stall - All those lunchtimes, free evenings, weekends and "freedom fridays" will be now be spent poking around in V8 rather than solving problems or bugs in V7. Attention is going to shift. I don't promote coding in your free time all the time btw, get a hobby and unwind.

• Package development on V7 will stall - why develop packages that you know you are going to have to rebuild/rework to work within V8, why maintain two versions. Better to just focus on the shiney new V8 version right?

• V7 Packages won't get patched or updated by their owners - "We are focusing on V8 now"

• Pull Requests for V7 won't get as much attention from HQ - Again they will be mostly busy with V8..."you should be building on V8 now anyway" or "we only have so much resource we have to spend it on the future"

The above also effects clients too, sites will have to put up with bugs and issues that previously would have been fixed as everyone is busy on V8 and don't want to waste the key strokes on a "dead end code base".

There will be a "final" release for V7 at some point that will signal that we have passed the Event Horizon...The King is dead (V7)...long live the Queen (V8)!

This is all the usual stuff that happens when a new version is approaching, these are inevitable but the damage they can do to the eco-system and community shouldn't be played down. We saw exactly this situation play out with the rebuild of V4 to *the version that shall not be named*and it did a lot of damage.

We have to limit the effect of these side effects until we know we can safely commit to V8 especially when we don't know when V8 is going to be ready. Having no packages released for 12-18 months would be a terrible shame, holding off on releasing a fix for a V7 package (that users on V7 right now could be using) could cause more pain to more users that the short time it takes to release it. Stopping coding on issues within V7 means those fixes aren't getting out to the huge install base of Umbraco V7 instances up and running RIGHT NOW rather than a smaller set that will be up and running SOMETIME IN THE FUTURE.

Any fixes pushed into V7 are pulled over to V8 so we should keep those PR's coming in and fixing whats wrong until the great "final" V7 release is announced and then we know its done done and can move to V8.

Client perceptions and sales head aches

There are other sides to this impending V8 Event Horizon approach that we might not have considered. Clients are now asking for it. I had a call only yesterday wanting V8 so they are on the "latest" and they mentioned possibly delaying the build until it was available as they didn't want to waste their money on an out of date build...the genie is out of the bottle!

It makes it a hard sell to say "I don't know when it would be ready" and even harder when I say "I wouldn't advise building on it with the first release" which is good sensible consultation advice but to a lay person it sounds like its a step back not a step forward. When I talk of the rock solid status of V7 (its the best version ever!) other clients have a hard time getting their head about why there even is a V8 coming..."whats it in, what makes it so good?". Another client recently tried to get me to promise a free upgrade to V8 before they would sign off on their V7 build last year, perceptions and expectations have been set by all this talk of V8.

New developer perceptions/experience

New developers coming to the Umbraco space can also expect some confusion..."which version should I be installing?" will now become a common question. There is currently no way to flag questions on the developer forum (aka Our) with a specific version so questions and answers that only work in V7 will now be tried in V8 and visa versa.

All the blog posts will be about "Doing X in V8" so will be giving them signals that this is were it is at but the forum posts might be more like "This doesn't work in V8" which is giving them signals that it might be hard or not ready for the big time yet. If we are honest we are expecting some issues right?

We shouldn't be confusing new developers trying out Umbraco we should be embracing them and streamlining their journey to get to the same happy place the rest of (hopefully) are with it. These can be fixed before the beta release of V8 and they should be, its the same as belting up and putting on your space helmet as they do in the movies I guess?

Reality check

If you had to start a new project tomorrow which version would you use? If you had to start one it 3 months, 6 month or 12 months which version would you use? How many V7 sites are going to keep running for another 2, 3 or even 4 years? We have to shore up V7 and ensure its as solid as it can be so it can hold the line until V8 is really ready and even then we are all going to be working on a mixture of V7 and V8 sites (and yes I see you at the back...V4 and V6 too) so lets not lose focus here.

Keep working on V7, keep promoting V7 and on the side keep dipping into V8 and helping it along until the time is right...when we knowingly cross the Event Horizon and become one with V8...

I've been doing some work on trying to get AngularJS (the framework used for running the back office) upgraded in V7 and Mads has started an issue and wondered if I'd chip in and get it into V8 with him so time to download it and try to get it working. Trouble is I spent 2 nights trying to just get it to compile!

So to avoid anyone else having the same issues here is a quick crash course on what I found and did to get it compiling. Most of this is just a fleshing out of the instructions on the "quick start for v8" page but I wish I'd had this post 3 nights ago so here it is! I'll add to it if I find any more and of course update the offical docs too.

V8 is in flux so the first issue is getting the right version to down load, this one seems to be the most stable: https://github.com/umbraco/Umbraco-CMS/tree/temp8

You should then pull that via Github which is described beautiful by Seb (the master of Pull Requests) so I'll assume you got that far and have it locally.

First off, try to compile it in Visual Studio. It will take a while as it needs to pull down lots of Nuget dependancies the first time you run it.

Check your Nuget sources

Talking of Nuget, this was my first issue. I have our own internal Nuget repository set as my default one and for some reason the build was always looking their for numerous packages it needed rather than on the official Nuget site. So job number one for me was to go through each project, right click on it and select "Manage Nuget Dependancies" and ensure it was looking in the right place (check the drop down in the top right to make sure its got nuget.org selected or simliar) and then rebuilt. That seems to do "something" to put it right and reduced the error count down from 3100+ to just 13! Result.

Ensure Windows is up to date

Make sure your PC is all up to date. I'm running on Win10 and there has been a big upgrade rolled out in the last few weeks. I of course have been putting this upgrade off and clicking the "remind me later" button everytime it nagged me for a restart. Then I forgot it needed an update/restart and tried to fix my remaining issues with it in a unknown state which wasn't helping myself much. So, make sure you are all up to date.

The quick way to know if everything is ok is to click on your power button under the windows icon (bottom left of the screen for me) and see if it gives you an "Upgrade and restart" option, if so its got some work to do so best to let it do its thing.

Install the latest .net frameworks

If you aren't running on Win10 you might want to ensure you've got the latest .net framework installed. You can't "break" the install if you reinstall so its worth just downloading and trying again to be sure. At least then you will "know" that you have the right stuff installed.

Upgrade Visual Studio

The Umbraco developers are a clever bunch and are running on the latest and greatest, some of us though get a bit behind the curve. When I saw it needed Visual Studio 2017 as a minimum which I already had I moved onto just grabbing the code and trying to get started asap. I sadly missed the text that said which build version of VS2017 I needed,it HAS to be 15.7 or greater. A lesser version won't include some of the stuff the Umbraco source assumes you are going to have automatically. I was bitten with this error which eventuallyled us to a post that pointed out that different version of VS2017 include different things:

"Error CS0012 The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'."

There was a fix in there to add a reference to 'netstandard' (which older versions of VS, like mine, didn't include by default) but the real issue is I was running an old version and I should fix that.

So I needed to upgrade VS! Again my heart sank a little at this, VS is a beast to install so there goes another session of coding up in smoke while I look at progress bars! But these days it is actually quite easy to upgrade and only took me about 5 minutes, I can cope with that.

EDIT: There is an offical doc on how to update Visual Studio 2017.

Here are the steps I used:

• Check which version you are on via Help > About Visual Studio, if you are on a version that is > 15.6 then you are all good and can skip the rest
• In VS click on Tools > Extensions and Updates
• In the pop up window look to the left tree for "Updates" and click on it, you should see an update for Visual Studio if there is one available. Give that a click and then follow along

With that done I could finally compile with no errors, Hurrah! I've updated the offical quick start guide with some of the pointers from here too so others should be able to avoid the frustrations I had with getting my environment setup to play around with V8 (none of this is V8's fault of course).

Now...3 sessions on I can actually start looking at this AngularJS upgrade :)

Pete talked about his overall vision of improving the back office in a recent blog post. In pursuit of being a small part of helping that, I submitted a recent pull request as a solution for issue U4-1104 which can be summarized as "Moment.js comes in really heavy in the back office, can we make it lighter?"

The answer, as my pull request goes to show, is we can make it a lot lighter. Almost 95% lighter.

What follows is a detailed look at the problem as I saw it, and the solution I came up with.

The Problem

The Umbraco back office uses Moment, which is a great library for dates and times in JavaScript. But it loads Moment into the app in perhaps the most inefficent fashion possible. How bad is it?

1. It loads the unminified script with all locales: moment-with-locales.js, which is pretty beefy at 362 KB.

2. If that weren't enough, it loads it twice.

As a result, the file size for the first load is 362 KB x 2 = 724 KB, as you can see here:


The Original Code

The moment JS files are in the proper place in the project due to the "sources":{} object at line 45 in src/Umbraco.Web.UI.Client/bower.json:

"moment": "bower_components/moment/min/moment-with-locales.js",

The load occurs on line 157 on /src/Umbraco.Web.UI.Client/src/views/propertyeditors/fileupload/fileupload.controller.js:

angular.module("umbraco")
    .controller('Umbraco.PropertyEditors.FileUploadController', fileUploadController)
    .run(function(mediaHelper, umbRequestHelper, assetsService){
        if (mediaHelper && mediaHelper.registerFileResolver) {
            // Right here!
            assetsService.load(["lib/moment/moment-with-locales.js"]).then(
                function () {
                    // snip... don't need to see the code in here to understand what's going on.
            );
        }
    });

The code is also loaded on line 6 on /src/Umbraco.Web/UI/JavaScript/JsInitialize.js:

'lib/moment/moment-with-locales.js',

Solution #1: Load the Minified Version

Swap to the minimized Moment with Locales script.

The Changes

1. Modify src/Umbraco.Web.UI.Client/bower.json at line 45:

"moment": [
  "bower_components/moment/min/moment-with-locales.js",
  "bower_components/moment/min/moment-with-locales.min.js"
],

1. Modify line 157 of /src/Umbraco.Web.UI.Client/src/views/propertyeditors/fileupload/fileupload.controller.js:

assetsService.load(["lib/moment/moment-with-locales.min.js"]).then(

1. Modify line 6 of /src/Umbraco.Web/UI/JavaScript/JsInitialize.js:

'lib/moment/moment-with-locales.min.js',

The Result

The file load size for first load becomes 167 KB x 2 = 334 KB.

The Savings: 390 KB smaller! 53.9% less!


Solution #2: Load Moment Only Once

That's already an improvement, but we're still loading the script twice. Let's remove one of those scripts.

The Changes

1. Remove the assetsService.load(["lib/moment/moment-with-locales.min.js"].then() from line 157 on /src/Umbraco.Web.UI.Client/src/views/propertyeditors/fileupload/fileupload.controller.js, leaving only the interior code of:

    mediaHelper.registerFileResolver("Umbraco.UploadField", function(property, entity, thumbnail){    if (thumbnail) {        if (mediaHelper.detectIfImageByExtension(property.value)) {            //get default big thumbnail from image processor            var thumbnailUrl = property.value + "?rnd=" + moment(entity.updateDate).format("YYYYMMDDHHmmss") + "&width=500&animationprocessmode=first";            return thumbnailUrl;        }        else {            return null;        }    }    else {        return property.value;    }});

The Result

The file load size for first load becomes 167 KB. There's no loss of functionality from file uploads.

The Savings: 557 KB smaller! That's 76.9% less!


Solution #3: Only Load the Locale You Need

We're still loading all of the locales, when our user only needs one at any given time. Can we do something to shrink it more?

Yes, we can! Moment provides a large list of locale files, which exist in the Umbraco installation. Using LazyLoad, we can load the one locale we need, if we have a way of knowing what culture the user has and had a place to know that they're always entering the app.

The Changes

At line 18 of /src/Umbraco.Web.UI.Client/src/init.js we have a listener paying attention for the app.authenticated broadcast, and loading assets for the user and triggering tours after they've authenticated:

/** Listens for authentication and checks if our required assets are loaded, if/once they are we'll broadcast a ready event */
eventsService.on("app.authenticated", function(evt, data) {

    assetsService._loadInitAssets().then(function() {
//Register all of the tours on the servertourService.registerAllTours().then(function () {    appReady(data);
    // Auto start intro tour    tourService.getTourByAlias("umbIntroIntroduction").then(function (introTour) {    // start intro tour if it hasn't been completed or disabled    if (introTour && introTour.disabled !== true && introTour.completed !== true) {        tourService.startTour(introTour);    }    });
}, function(){    appReady(data);});

    });

});

Let's put a function in here to load the Moment locale we need. But because this is centered around the user, let's make that function in /src/Umbraco.Web.UI.Client/src/common/services/user.service.js to keep it in the right code bucket. We'll call the function loadMomentLocaleForCurrentUser(), and make it look like this:

/** Loads the Moment.js Locale for the current user. */
loadMomentLocaleForCurrentUser: function () {var deferred = $q.defer();
var supportedLocales = [];
this.getCurrentUser()    .then(function (user) {    var locale = user.locale.toLowerCase();    if (locale !== 'en-us') {        var localeUrls = ['lib/moment/' + locale + '.js'];        if (locale.indexOf('-') > -1) {        localeUrls.push('lib/moment/' + locale.split('-')[0] + '.js')        }        assetsService.load(localeUrls).then(function() {        deferred.resolve(localeUrls);        });    } else {        deferred.resolve(['']);    }    });return deferred.promise;
}

Some notes on what's going on here.

• We're getting the culture of the user from userService.getCurrentUser().

• If the culture is en-US we're not going to do anything more, as that's Moment's default locale.

• Otherwise, we want to try to load the locale file associated with the culture. We do have a problem, though, in that the user's culture doesn't always exactly match Moment's locale file naming conventions. For example, Danish in Moment is da.js, but in Umbraco's user culture it's set as da-dk. Conversely, in some cases Moment doesn't have a non-hyphenated version of some cultures, So if the culture is hyphenated, we'll attempt to load Moment locale files for the hypenated and non-hyphenated versions of the culture.

Now that we've added this, we'll modify our code in init.js as follows:

/** Listens for authentication and checks if our required assets are loaded, if/once they are we'll broadcast a ready event */
eventsService.on("app.authenticated", function(evt, data) {assetsService._loadInitAssets().then(function() {
    // THIS IS OUR CHANGE: Loads the user's locale settings for Moment.    userService.loadMomentLocaleForCurrentUser().then(function() {
        //Register all of the tours on the server        tourService.registerAllTours().then(function () {            appReady(data);                        // Auto start intro tour            tourService.getTourByAlias("umbIntroIntroduction").then(function (introTour) {                // start intro tour if it hasn't been completed or disabled                if (introTour && introTour.disabled !== true && introTour.completed !== true) {                    tourService.startTour(introTour);                }            });
        }, function(){            appReady(data);        });    });});

});

Now that we know we can load a locale file on user login, we can ditch the moment-with-locale.min.js file for the non-locale file in /src/Umbraco.Web/UI/JavaScript/JsInitialize.js by replacing:

'lib/moment/moment-with-locales.min.js',

with:

'lib/moment/moment.min.js',

We also need to modify src/Umbraco.Web.UI.Client/bower.json to load in the moment.min.js and locale files like:

"sources": {"moment": [  "bower_components/moment/min/moment.min.js",  "bower_components/moment/min/moment-with-locales.js",  "bower_components/moment/locale/*.js"],// snip for brevity
}

(I'm keeping moment-with-locales.js for purposes of loading inside karma tests.)

The Results

For US English users we're loading a mere 34.9 KB. If we were Danish, the locale file is only another 2.3 KB. That's less than 38 KB total!

The Savings: 686 KB smaller! That means we're loading 94.7% less code!

 

The Conclusion

We've removed around 686 KB of assets from the initial load of the Umbraco back office with a little cleanup and extra work for being more selective in bringing in Moment locales.

If you're interested in joining us and going from being an Umbraco developer to an Umbraco contributor, you can check out this list of issues that Pete Duncanson brought up for helping out.

Umbraco CMS currently has never been stronger. Version 7 is absolutely amazing and rock solid. These are golden days that we live in as an Umbraco developer, agency and for our editors. Bravo. Its a testament of just how far it has come on that I raise the thorny issue of rebuilding a large chunk of it, are we getting to the point where we need to think about rebuilding the back office? I know right, what am I thinking? That makes no sense, I just said it was rock solid so why rebuild it? Hear me out though.

This is a bit of a controversial topic as it means change and as humans we don't cope with change all that well. So let me quickly cross off some of the obvious queries and knee jerk reactions you might have before we get into the meat of this thought experiment to try to calm some nerves and sent the scene:

• Its a task for HQ but as a community we can start and shape the discussion, after all its us that will be using it.

• We don't have to rebuild the back office at all if we don't want to!

• Its a really big job and I don't expect anything to start on it for 18 months at least

• Due to above lead time I'm not suggesting any tech choice at all at this time, just ideas. This post is framework agnostic on purpose.

• I know you have probably invested heavily in learning Angular and all that jazz and don't want to lose that knowledge or have the heart to retool, I get that.

• The current back office has been amazing and will continue to be for some years yet

Right, that is the obvious stuff covered. You all good? Great, lets do some more digging and see why I and others are starting to murmur about a rebuild, whats wrong with the current one and what benefits we might get from it.

Very short history lesson

Honestly this is the short version but a little history is needed so we know how we got here and where we might go. The current back office is in its 5th year now, I remember watching Per Plough talking in a key note about Belle (the code name for the new look back office) at Las Vegas at the first uWestFest. In that talk he explained the choice for using Angular, the departure from .net for making custom backend widgets and property editors (woohoo! good bye user controls).

Angular was in version 1 at the time and is really one of the first frameworks for making web applications, websites that do complicated stuff, what we would call now a Single Page Application (SPA). It was a bold but right choice. It gave the back office the javascript goodness it needed to make it as smart and smooth as it turned out. One of the additional drivers was the explosion in JavaScript in general, thanks to Node.js and GitHub the amount of JavaScript goodies we might be able to leverage in a JavaScript backend was huge, reason enough to get in the game. Trouble is not much of that awesome additional JavaScript did make it into the back office.

Mostly folks rolled their own JavaScript so we didn't get much of the promised return of being able to dip into the pool of other tools already out there. The only exception that springs to mind is Marc Stöcker's Sir Trevor package that leveraged a gird like editor from ITV News. This though died a death once the Grid was released in Core. Our recent package Ernest was our attempt at seeing what you could do if we could play with some of this other JavaScript tech, you can read more about the hows and why if you like. We also had a point where a handful of developers in the community create a bunch of property editors etc. that the rest of us could use so we didn't all need to become Angular experts. Those that were gave us 90% of what we could ever want.

Umbraco as it is is stuck on Angular version 1.1.5 (or there about) with rumours of it even having some customisation in there too...but of course it has. Angular moved on of course but for some reason the Back office didn't (I suspect they changed the API at some point which broke some stuff before a big release). Then something odd happened within the Angular development team.

Other frameworks started coming out, some really big apps were made with Angular, new ideas got added to the mixing pot, lessons were learnt. To fix these issues and make changes they decided to completely rewrite it...over several years...with no backwards compatibility. It didn't go down well from those that had invested in the framework, everyone was now in effect in a technology dead end, including of course Umbraco. Angular v2 (actually v5 I believe...no not THAT v5) is out and the version Umbraco is on is now referred to as AngularJS. Confused? You should be, its a bit of a mess. There are ways to allow for upgrading to the latest Angular framework but its nothing really simple so although this might sound like an option it really just muddies the waters even more in my opinion.

What is wrong with mature tech?

So we have a framework that has done us proud for 5 years, what is wrong with that? Why would we want to change it when it sounds like its working?

There is nothing wrong with this, in fact its great that we've had so long a run out of it and its still going strong. Its allowed HQ to mostly switch the back office over from user controls and hard coded web forms of V6 fame over to API endpoints which now power the JavaScript front-end via Ajax (we still call it that right?). There are only a handful of legacy bits and bobs still floating around and the odd iframe escape hatch here and there...I'm looking at you Rollback and Audit Trail!

This means that we "mostly" have a separated API back office from the front-end back office. As a result this means that the investment in development effort to switch from Umbraco V6 to V7 would not need to be repeated should we chose to switch out the front-end of the back office in the future. Rather than a complete rewrite we only need change the front-end layer and continue to use the existing API's if that makes sense (I am of course aware its a huge task and that sentence makes it sound like its easy).

The trouble is while it might be mature its not really moved on. Its difficult to teach it new tricks. In the meantime the JavaScript world has not stood still, nor has the learning or the best practises or the options and opinions of how to do stuff. AngularJS in its railway siding has stood still. Again this might be just fine. I suspect we will hear people say "That's me out then, I'll go else where if you change" but this is the internet, things are changing all the time, you have to be constantly learning to keep up. That is not to say we should throw stuff away or to chase the shiny new things just for the sake of it but we've had 5 years of a stable framework (with another 18+ months still to come) that is like a century in internet time. We can't stand still and I feel the time is approaching were we need to think about the future.

We could just keep using it as it is. It works right? Its certainly an option and to be clear we will have to until a future replacement is ready anyway assuming we rebuild at all. But there is a danger that its not just the tech that becomes legacy but the knowledge of how to do it too. Currently getting docs on AngularJS v1.1 is not easy or obvious, there are not many Stackover flow questions flying around for the version we are on, the knowledge is hard to find/attain and is not all that transferable. Umbraco training is the only place you can get a few hours of hands on time in AngularJS. New front-end developers coming to Umbraco are going to have a hard time of it and also be amazed it doesn't do some of the cool stuff they just take for granted these day. Dare I say that it could be that AngularJS is becoming the the XSLT of previous versions? It did the job but folks found it old, quirky and odd (unlike Razor which is just quirky and odd).

Looking under the hood

I've recently been doing a lot of digging into the back office as part of a optimisation project for a client and if honest I had an itch to scratch. Its the sort of digging most won't do as really we only normally have to build property editors and dashboard but when you start digging it sort of becomes clear that a lot of the core of the back office, the really deep stuff has the feel that it is still pretty much like it was 5 years ago when the first prototype was built. Its got that "all best intentions are to come back to sort this out once we've got this prototype up and running" feel about it, you know, the ones you never actually get the chance to come back to.

This is not a direct criticism (we all have code like that), what is there works really well and enabled all this in the first place, but imagine if we could re-visit it and get it bang on rather than "it works". Then rather than the black magic feel that it has at the minute others would be able to dig into it more, pull requests would be easier, code layout would be better, services would be obvious and standardised. There is a benefit right there but you'd need a reason to go in there and do that, a rebuild (or retool) would be the perfect time. As is I suspect few dare go too deep (even in HQ) and poke it from a distance with sticks. This is of course just my opinion/judgement from looking around it, I could be wrong.

As an example we've got a site that download nearly 3.5Mb of JavaScript every single page load. This is all needed to run the back office. But its EVERYTHING that is needed to run the back office, not technically true as it downloads even more on the fly later. Angular needs all the Controllers you might need up front before it bootstraps the app so Umbraco sends everything down the wire upfront. So if your an editor you still load all the code to edit users, DocTypes, data type settings, etc. stuff they don't have the access to, so why are they having to download it? Lots of bloat. Not a problem on our developer machines but editors are rarely on cutting edge kit are they? Plus having that much JS running all day can make a browser sick. We've got clients that reboot the browser twice a day to make the back office "snappy" again.

Editors spend every day in the back office, why are we slowing them down with code they will never run? JavaScript eats CPU, parsing it and running it takes resources. This is not a minification issue its a bloat issue and its a limitation of the framework. This could be mildly/nearly fixed (and its something we are working on, don't worry there will be a pull request) but in modern frameworks you can load stuff on the fly at the point of need via something called Code Splitting and its just a given. To find out you can't in Angular is an issue, not a complete deal breaker just not ideal, others can do it why can't we? I've got about 20 other issues like that that are similar, stuff that should be easy to do but isn't as the framework has stood still. Sure we could hit what is there with hammers to put some of this stuff right but is that time well spent? Back in the days when just trying to make this SPA stuff easier was the goal AngularJS was amazing but now we've "cracked SPA's" the focus switched to making them better, faster, more flexible and responsive but you can't do it with AngularJS as is.

Transferable skills

Some of you I know use Angular on the front end of you websites and the fact you can use it both in the back office of Umbraco and on your client sites is fantastic. I'd get why you wouldn't want to change the back office tech. But again time doesn't stand still and finding staff who can pick up a site or a widget or a package is starting to become a problem, because you won't relearn a tech they have to learn an old one that is in a dead end.

By updating the tech we get to tap into the existing knowledge of new hires rather than have to train them up. Again we've had 5 years out of AngularJS in Umbraco, that is not a bad run now is it?

What about all those packages we've written, if you rebuild won't we lose those? Well yes, yes you will. But you'll have plenty of heads up that its coming and in the meantime we will have had V8 and maybe even V9 by then which will have had their own share of breaking changes. If the packages are good enough then there is time to convert them over. Luckily some of the biggest packages are already in Core (hello Nested Content) so would get converted anyway, "most" others don't go into crazy depths with Angular or if they do they tend to use stuff in the Core that can change between versions and break anyway (Angular "tweaks" are never considered a breaking change by HQ it seems).

Wait, I mentioned an iframe escape hatch for old legacy code from v6 a while back, could we not do something like that for the older AngularJS stuff? Hell no! How long do you think your code should stick around for? V8 is the "clean up" version were we get to dump a lot of really old legacy code, it would be a damn shame to then straight away start a fork of the back office and try to run two versions of it at once. This is meant to be a clean up and a rebuild not trying to run multiple out dated frameworks in one. The biggest code to be changed will be the Core code that runs the back office, that to me is where the biggest gains can be had for performance, maintainability, consistency and extensibility. Older packages will simply have to be updated or retired. If the are that good then others will upgrade them and bring them into the new style if you don't have the heart or time so fear not.

I'd draw a line under old AngularJS code if it was me but then its not me in charge is it? So yes you "could" run your property editor code in whatever new framework we use, I'm sure we could add a bunch of shims and proxies to make it work one way or another its just not pretty and I don't think its needed.

What do we actually "develop" in the back office?

When there is talk of a rebuild or "we should use framework X in the back office" discussions there are some that think that this would cause all their skills to be scrapped and a massive effort to relearn new technology (or yet another framework). Thing is, what do we actually "do" in the back office as front-end developers? With a few notable exceptions most of us build a fancy property type, which might need to make an API call to either Umbraco or a 3rd party end point, maybe a dash board, create a new section, maybe add a menu option. That is it really, that is 95% of what we might want to do.

If in whatever new back office tech we use if we can make those tasks easy to do then its not really a complete "re-learn" of technology. It could be that we even make it easier to do these things. Not having to have to create 3-5 files for a property editor for instance would be a benefit for me right away! Imagine getting rid of the complication of Dependency Injection, in modern JavaScript you just include what you need rather similar to a using statement in C# rather than needing a framework to inject it in for you from magic strings, another hurdle to learning removed for new folks and one less lot of square brackets and dollar signs for us old timers to remember about.

Again, if you often dig deeper than that then I can see why you might not want to relearn yet more tech if you've become good enough to dive that deep regularly. However, if you are going that deep then you should be able to see the cracks and the bits that are not right and were we could improve and you also know JavaScript really well and in that case you should be able to turn your hand to any JavaScript powered tech, especially if we find one that makes it easier or at least gives us to the chance to put right some of those cracks and rough bits. I get wanting to stick with tech you know, I only shut down my last Classic ASP site 5 year ago so I get it but I killed it as I was the only one that knew it and I didn't want to train anyone else up on it as it was dead knowledge.

How do we develop for the back office?

When we talk about new JavaScript tech it doesn't take long for groans about "crazy complicated tool chains" start to be heard. Modern JavaScript development from the outside seems to have a million and one tools you HAVE to use and they all seem super complicated, impenetrable and stupidly named. The reality is though that all these tools are also maturing and developing (its one of the reason there seems to be so many, lots of brains on lots of problems) and part of that is making things easier to use and ideally a faster experience for the end user. Noble aims. We add caching to make things faster in our code despite the additional complications it brings because it makes for a better end user experience. Optimisations often come with a complication trade off but thats not to say we can't try to make it easier for everyone hence the amount of tools in use these day.

Take WebPack for instance, its become the current defacto standard for "compiling" your JavaScript and to be fair its held that crown for the last 3 years. By compiling your code and assets you get a whole world of goodies available to you like usage of new language features before they come out, convert your SASS to CSS, embed your CSS in your JS and reduce a network request, use short cut syntax or domain languages, get type checking, awesome minification way beyond just removing spaces and new lines, code splitting and so much more. Then it can bundle all your code up into compact bundles of code and then do something call "tree shaking" which removes un-used code to reduce your file size. All quite magic really. Its now a sponsored open source product expertly headed up by the amazingly friendly and helpful Sean Larkin. Lots of big companies are paying for its development as their products depend on it. Sean and the team are doing lots of great work to promote it, make it easier, faster and better documented and they are doing a fine job of it too!

However the thought of having to use that tool chain probably terrifies you if your not already using it. You probably would prefer to see your JavaScript in the browser raw, vanilla js edited in a text editor of your choice. I'd agree with you if you are developing a property editor, you shouldn't need to do all that. We don't need to compile your 20 line property editor. You should be able to hack at a JavaScript file save it and it just works in the back office. Lets make that a requirement to have as minimal tool chain as possible but ideally no tool chain when developing property editors. Hardcore devs can of course opt-in to running their stuff through a tool chain for bonus points.

The core of the back office on the other hand and if you need to "go deeper" should use tech like WebPack as the gains would benefit everyone. If you want to work on core we'd have a guide on how to get setup with WebPack et al and a config file already written for you so it all just "works" without you having to do much other than have Node installed and follow a few one time command line instructions (or like we do just run a .bat file). This is about getting gains for everyone not just JS whizz kids who like playing with fancy stuff, that won't help any of us now will it?

How might we do it?

HQ would have to do this one, this is not one the community could do. But as a community we can help shape what we would want it to go like and let HQ know that its something we want doing and focusing on (assuming it is).

I really like the current look and feel, I don't think there is any reason to depart from it currently and it would only add more work to what would already be a bit job. I'd suggest that on the whole we leave it as is and just rebuild the tech under it.

I'd suggest the ideas of what it should be like are fleshed out between now and then and that the intentions to rebuild are announced with a rough version number to target for. Right now we could do a bit of optimisation work in the existing back office code to tidy it up a bit and get it fit for the next 2 years. Then it can hold the fort while the new rebuild beings and is completed along side it. This is very similar to how we would rebuild a large website, shore up the existing site to buy us time while we work on the new one along side it, once ready swap it out. Again I think starting this is about 18 months off given HQ's apparent current work load and aims but seeing the new road map at Code Garden might give us a better indication of time. If we shout about it enough they might pull it forward but I think starting it in 18 months or so is about right for a target.

Then ideally the new back office gets released as V9 or possible V10 (which I suspect won't be called that and will be Version X or something, that seems to be the in thing to do these days) and there will be much rejoicing.

The first bit though is discussing what we want. Along with the ease of development, faster performance, more modern tools/best practises mentioned above I'd also like to see more formalisation of the data and services in the back office. For instance we have a ServerVariables global object in there at the minute that is a bit of a holding pent for all sorts of data no one can seem to find a real home for. I'd rather than was cleaned up some. For the optimisation work I've been trying to find a way to get the current users locale so I can remove 300Kb of JavaScript language files for moment.js and only download the one the user needs. Trouble is I can't find a sensible place to get this from and I'm looking to add it to the ServerVariables collection like everyone else is doing. Ideally we should have a CurrentUser or LoggedInUser object that I could use to get this data from. This would power the avatar, login info and all that as well as store the locale. I'd like to see more formalisation of data like this for ease of use in the front-end of the various bits of the back office data.

There is much more to discus on this so I've created an Umbraco issue (link is at the bottom so you don't get distracted) so our discussions don't get lost on twitter. I'm also keep to chat this through with anyone at Code Garden in an Open Space or at the bar :)

We should use [insert framework here]!

No we shouldn't. Right now is not the time to pick a framework. Right now we should be discussing what we want the back office to do for us in 2 years time and then see what fits. Anything could happen in that time frame. Even me mentioning WebPack above was a bit naughty, it makes it sound like its a given but it was only for example. Just because its hot now doesn't mean it will still be at the time when we break ground on a rebuild in 18-24 months time.

The danger of picking or discussing a framework now is it can cause Confirmation Bias in others or even the Halo Effect which can cause us to miss out on a true best fit for all. By naming tech now we are in danger of framing the discussion about the tech rather than what it is we want the back office to do for us regardless of tech. Let's instead talk about the changes we would like to see, the gains we would want to have, the friction we would like to ease and the legitimate worries that we would have to tackle to ensure current users can adopt any future change, new users can pick it up quickly and give it a strong foundation to take Umbraco forward for another 5 years.

Its joked that frame works pop up all too often but in reality they are quite rare beast. Yes you get some pet projects or side projects cropping up but there are a lot less than you might think that take hold and stick around. AngularJS has done the Umbraco project amazingly well and will continue to do so for another 18-24 months with ease while hopefully we work towards a more up to date solution however now is the time to be thinking about succession. Now is the time we can talk about as a community how we might want that new front-end setup to do, look and feel like, effectively so we have a job description before we start interviewing candidates for the roll.

I'm very excited that this is a discussion we are having now, it once again shows just how far Umbraco has matured and how rock solid it is that we can plan for features 2 years down the road. Bring it on.

To comment on this post and share your ideas please head over to the Umbraco Issue Tracker, see you there.

Ernest also served as a testbed platform for Offroadcode to experiment with a project that we've been exploring for a while: using React for custom property editors or other packages inside the Umbraco back office.

Wait... What? Why?

A natural question to ask is "Why?" After all, the Umbraco back office is built in Angular, and Angular controllers are expected for something as simple as a property editor, let alone more ambitious projects. Why not just use Angular?

Using Angular is great, and it works well for a lot of teams and is the standard for working in the Umbraco back office. But for a while now we've been wondering "What if?"

Experience

The first answer is that we use React as our library of choice when designing complex interactive modules or web apps for client websites. In the last twelve months alone I've literally authored or edited hundreds of thousands of lines of code in React.

Angular is a fairly intensive and highly opinionated framework that resembles the metaphorical purse with the kitchen sink in it. It's a lot. React, by comparison, is a library that does one thing and does it well: create interactive UIs. And it does it without making any assumptions about the rest of your technology stack.

As such, we find that React is the right size for our projects, giving us the flexibility to use it at a number of scales for a number of purposes. And with this institutional experience, we can much more quickly create views and interactions in a property editor or package using React over Angular. We don't have to relearn how to do the same thing a different way, and can more quickly onboard team members into a back office project.

Ecosystem

Ernest uses Draft.js, a rich text editor framework based upon React. It's a powerful and flexible tool that allowed us to make exactly the editor experience we wanted without having to reinvent the wheel.

Although the faddishness of JavaScript libraries and frameworks over the past decade is a great source of jokes for programmers, especially in other parts of the stack, to make at one another's expense, right now React is in a dominant position over Angular in drawing the attention of developers. There's more coders making more tools, like Draft.js, for one another to use with React. And unlike Angular, React doesn't have a community split between incompatible versions to further dilute the user base (Angular 2, anybody?)

This difference in interest can be starkly illustrated by the amount of downloads each has seen in the last six months on npm, per npm trends.

By making React available to use in the back office, we've made it possible to take advantage of the contributions of these other developers, reducing the amount of work we need to bring a new project to life.

OK, So How?

Once we decided to try to bring React into the back office, we needed to determine how we were going to do it. We explored a lot of different solutions that other developers have used to bring React into Angular or vice versa in other projects, such as ngReact and ngImport.

Ultimately we decided against using them, as we were already going to be utilizing React inside Angular inside the Umbraco back office module. The less complications we introduced into the code at the interface between the two libraries, the better. As such, we ended up utilizing React and Angular without any additional connective tissue from such a solution, and focused on keeping a small footprint on the communication between the two.

Here's how we did it:

The Example Projects

The source code for Ernest can be found here on Github, for those curious to explore it. Before we made Ernest, though, I made a proof-of-concept minimal property editor to test what we were doing. Inspired by the chimeric nature of the codebase, I named the test project React Angular Chimera. The focus is on using as little code as possible to accomplish our aim, and code is heavily commented throughout. For the purposes of this article, I'll be referring to code in Chimera, and not Ernest.

Using Webpack

I knew right away that I wanted to use Webpack for this project. Introducing React into a property editor brings the potential for a sizeable codebase in itself, as well as any potential modules (such as Draft.js in Ernest). Webpack would allow us to bundle it, and with the UglifyJS Webpack Plugin we would benefit from tree-shaking to help get the bundled script even smaller. Also, with my React experience I've become rather attached to utilizing various Babel/ES6 features that aren't always available yet on the browser without compiling first.

The Angular Code

The goal for what we're doing is to keep the need to author Angular code to a minimum so we can leverage our React experience and ecosystem. If we stripped out comments, in total we're seeing less than thirty lines of Angular-related code at all. This is true not only in Chimera, but in the much more complex Ernest.

Because we're doing this all with Webpack, first we have our entry point into the JavaScript, which I've called app.js in the Chimera project:

import AngularWrapper from './controllers/AngularWrapper';

angular.module('umbraco').controller("ReactAngularChimera.AngularWrapper", AngularWrapper)

As you can see, there's not much there. We're importing the module from our Angular Wrapper (which will be detailed below) and injecting it into the Umbraco Angular module used by the back office.

Our Angular Wrapper module, which is the Angular controller called AngularWrapper.js, is by design also fairly barebones. You can see it here with comments stripped out:

import React from 'react';
import ReactDOM from 'react-dom';
import ReactLogic from '../components/ReactLogic/ReactLogic';

const AngularWrapper = function($scope, $element) {

    $scope.setVariables = function() {
        $scope.reactNode = $element[0].querySelector('.react-mount-node');
    };

    $scope.updateAngular = function(value) {
        $scope.model.value = value;
        $scope.$apply();
    }

    $scope.updateReact = function(newValue) {
        const value = newValue ? newValue : $scope.model.value;
        ReactDOM.render(, $scope.reactNode);
    }

    $scope.init = function () {
        $scope.setVariables();
        $scope.$watch('model.value', function(newValue) {
            $scope.updateReact(newValue);
        });
        $scope.updateReact();
    }
    $scope.init();
};

AngularWrapper.$inject = ['$scope', '$element'];

module.exports = AngularWrapper;

This looks a bit different from the normal controller declaration pattern because we're using Webpack and import/export declarations.

First we're declaring the controller:

const AngularWrapper = function($scope, $element) {
// snip - removed the content
};

Then we're injecting the Angular dependencies we'll need in it:

AngularWrapper.$inject = ['$scope', '$element'];

$scope is familiar to anyone who's had to make anything in Angular before. We're also using $element so we can take advantage of its functionality for finding something inside the view the controller was bound to.

Speaking of the view, let's look at that quickly before we come back to where the magic starts to happen. It's container.html, and it looks like this:

    React in Angular Chimera Example


        Angular-controlled span: {{model.value}}

We're binding our controller to it, and we'll be looking at it again in a moment.

To make our Angular controller utilize a React view, we need to do three things:

1. We need to tell ReactDOM to render our React view somewhere inside the Angular's view.

2. We need to be able to pass values from our Angular $scope into the React view as props, AKA parameters that can be passed into components and used as desired.

3. We need to watch for when changes inside our React view occur so they can be returned to our Angular $scope.

We injected $element into our Angular controller so that we can, inside the Umbraco back office, locate the specific element that we want our React code to bind to the DOM inside. In $scope.setVariables() we do that with:

$scope.reactNode = $element[0].querySelector('.react-mount-node');

With $element[0] we get the view's container element that's bound to this controller, and then with vanilla JS's querySelector() we search for a child component with the class .react-mount-node. Inside container.html we have just that:

This is where the React is going to mount and do its thing.

Now that we know where we'll be mounting the React, we need to have the properties that we'll be passing into it as props. Because we're making an Umbraco property editor, we know that in this case the value we want to keep synched is the $scope.model.value that the propery editor saves.

Inside $scope.init() we therefore set a watch on model.value, and we're going to use that to update our React:

$scope.$watch('model.value', function(newValue) {
    $scope.updateReact(newValue);
});

Now, whenever our Angular's $scope changes model.value, we can pass that into React. The function that does this, $scope.updateReact(), looks like this:

$scope.updateReact = function(newValue) {
    const value = newValue ? newValue : $scope.model.value;
    ReactDOM.render(, $scope.reactNode);
}

First, we're getting the value from the scope.

Then, using ReactDOM.render() we either mount or update our React component, passing in the value as a prop, mounting it to the node we assigned as $scope.reactNode.

At this point it's possible that you're wondering, "Wait... isn't it incredibly slow to re-mount the node using ReactDOM.render() every single time $scope.model.value updates?"

I was worried about that too, so I hunted down an answer. Thankfully, none other than Dan Abramov himself was able to supply me with the answer from an earlier tweet he'd made on that exact topic:

Misconception: calling ReactDOM.render() second time is very slow. Reality: it has the same performance as setState() on root component.

-Dan Abramov (@dan_abramov) on Twitter, 24 Jan 2016

Which is perfect, as this will make it easy for us to keep our React up to date with the changes to the $scope.

One property we're placing on the React component is onValueChange={$scope.updateAngular}, which helps us complete our list of needs in the Angular controller. Inside our React component, which we'll see shortly, whenever there is a change that we need to propogate up to the Angular, the passed in $scope.updateAngular() function is called.

The function looks like this:

$scope.updateAngular = function(value) {
    $scope.model.value = value;
    $scope.$apply();
}

And it takes the value placed into it, applies it to $scope.model.value, and insures that it's applied.

Now the loop is completed. Whenever we save our page, the property editor's value, passed up from the React component, properly saves with it.

The React Code

With our wrapper above, we've made our Angular controller as simple as possible, reserving our React to handle any complex logic or other actions in addition to rendering the view, allowing us to have one source of truth.

In our Chimera example, our React component is kept similarly small, rendering an input textbox and handling changes to its value. Our file, ReactLogic.js looks like this with the comments stripped out:

import React from 'react';

class ReactLogic extends React.Component {
    constructor(props) {
        super(props);
    }

    onValueChange = (e) => {
        this.props.onValueChange(e.target.value);
    };

    render () {
        const props = this.props;

        return (
            React-generated input:

        );
    }
};

module.exports = ReactLogic;

We're using the standard React.Component pattern for creating a React component with class ReactLogic extends React.Component {};. We have the construtor() with props being passed on it and making a call to super(props).

There's only two member functions. render() is required in a React component, and is responsible for returning the JSX that creates our view.

render () {
    const props = this.props;

    return (
        React-generated input:

    );
}

In it we're taking this.props which was passed in from our Angular wrapper, and passing its value into the value of our textbox. Whenever our Angular wrapper updates, it will trigger its ReactDOM.render() call and send it down to the component, triggering a re-render.

Additionally, we've bound this.onValueChange to the onChange event of our input. This function is responsible for notifying our Angular wrapper that there's been a change, and looks like this:

onValueChange = (e) => {
    this.props.onValueChange(e.target.value);
};

this.props.onValueChange() is the $scope.updateAngular() function passed through from our Angular Wrapper. So the value of our textbox is passed up to the Angular $scope whenever a change is made. The watcher on our scope notices, and triggers the update back down into the React component, updating its props.

Stitching It All Together

Now that we have all this code, I compile it down in my project by running npm run webpack (more instructions on setting up the Chimera repo and editing it exist in its README.MD file) which generates out bundle.js in a distribution folder. As a result, the package.manifest is fairly standard:

{
    propertyEditors: [{
        name: "React in Angular Chimera",
        alias: "ReactAngularChimera.Editor",
        icon: "icon-newspaper",
        group: "media",
        editor: {
            view: "~/app_plugins/ReactAngularChimera/views/container.html",
            valueType: "JSON"
        }
    }],
    javascript: [
        "~/app_plugins/ReactAngularChimera/js/bundle.js"
    ],
    css: [
        "~/app_plugins/ReactAngularChimera/css/styles.css"
    ]
}

What About Dependency Injections?

In our Chimera example we don't need more complex Angular native functionality like $http or Umbraco back office resources like contentResource. In cases where this were so, we have a couple different ways we could interact with those.

For core Angular modules, we could inject them using something like ngimport. We can pass Umbraco services or resources into our component via AngularWrapper as props in our ReactDOM.render() call, or we could pass in another function in our wrapper into the component and have it deal with the resources directly in the wrapper.

What About Performance?

Our Chimera example is a simple textbox, and as such there's no good reason to go through this much effort to make it with React inside Angular. But with Ernest, which is a good deal more complex and uses Draft.js, it's a fair question to ask: does doing things this way hurt our performance?

In my testing, and the testing of other projects that use React in Angular, I can say that the rendering and responsiveness does not suffer. There's also no noticeable lag to first render. I believe (but don't have benchmarks on hand as I write this post) that in fact, the rendering speed is improved with how React handles the virtual DOM versus Angular 1's method of redrawing.

The biggest outlier could be package script size. At present, after building with Webpack using treeshaking, Ernest's script runs around 500 KB. I'm sure there's additional saving on size that could be done to reduce this, and I'm convinced that a reasonably complex rich text editor alternative that's Angular-only would be comparably sized once all of its assets are accounted for.

In Conclusion

In the end, I felt that React and the tools around it have come to the point where it takes only minimal effort to include it in an Umbraco package as a replacement for Angular's view rendering. As someone who spends much more time with React due to our company's work on many complex front end applications, I believe that it's going to help reduce the development time needed to create more complex back office projects, as I have a fresh knowledge base, familiarity with its ecoystem of related products, and can escape some of Angular's opinionated behaviors that don't work for me.

If you'd like to give building a property editor or other complex project a shot, please feel free to look at the code inside React-Angular-Chimera on GitHub, which is as minimal of a use-case as I could think of, or take a deeper dive into Ernest for something more complex if you want to see examples in action.

Furthermore, if you have any questions about using React in this context in general, or Ernest in particular, please feel free to ask. I'm on Twitter as @cssquirrel, and you can always hit us up here at Offroadcode to chat or talk about any project by getting in touch.

The content that clients write for their websites is on the front line of communicating with their customers. As such, it always benefits for them to be as clear and focused in their writing as possible. Which is why, inspired by the Hemingway editor, we built a new rich text editor for Umbraco that assists an editor with identifying areas in their content copy that might need their attention and provides suggestions on how to improve it.

We call it Ernest.

Ernest has also been an opportunity for us to look into integrating our experience with React into our workflow when working on property editors or other packages in the Umbraco backoffice, which is based on Angular. Ernest makes use of the Draft.js text editor framework, which is built upon React. We'll be writing more about the experience of using React in Angular for Umbraco packages in a follow-up post.

We'd love to hear your feedback on Ernest, and if you encounter any issues please feel free to submit them!

• Download from Our Umbraco
• Ernest's source code on GitHub

Pete picking up the award - Visit Umbraco.com to read the full case study

In 2016-17, we spent a significant amount of time redesigning and rebuilding not just their website but also the underlying Umbraco CMS - dragging their back-office right up to date with Umbraco V7.

Prior to this project, one of the biggest problems they had as a company was the extremely clunky and hard to use V4 Umbraco build that powered their website and we knew from many discussions that in order to make a stronger and faster site this needed to deliver a better user experience for their visitors.

Not only that, it simply had be a lot faster and more flexible for the content team who needed to be able to create more compelling content much quicker than ever.

With a strong redesign and rebuild on the front-end and some innovative and editor friendly development in Umbraco - including the creation of a number of Umbraco packages - we've helped turn some very big client frowns upside down.

For such a traffic-heavy website an update to a newer version was vital. Our Gold Partner Offroadcode took that challenge.

During the process they developed multiple packages for this solution and open-sourced them. This is a fantastic example of true open-source spirit.

They’ve changed the editors’ minds from disliking Umbraco to loving it. It goes to show how big of a difference the right implementation makes.

No wonder this case won the Jury’s choice award at the Umbraco Awards 2017! Umbraco.com

To win such an award makes us incredibly proud as a team, to have our work and contributions to Umbraco recognised and rewarded by our peers is a true high point of our year.

Visit Umbraco.com to read the full case study.

Thank you Umbraco! 👏👏

Thanks to a recent pull request, we were able to start developing the Umbraco 2 Factor Authentication package and with the release of Umbraco 7.6 all the necessary core code is in place to make it available to the wonderful Umbraco community on Our Umbraco.

We'd love to hear your feedback and of course feel free to submit any issues. We'll be continuing development of this package and adding more features so stay tuned!

• Download from Our Umbraco

• Install information & Release notes on GitHub

• Our - the developer forums available at [our.umbraco.com](http://our.umbraco.com/ "The community hub for Umbraco")
• DocTypes - define the page and make up of the content on an Umbraco site, so you would have a Blog doctype, a Homepage doctype etc. One for each type of page.
• Nested Content - [a package](https://our.umbraco.org/projects/backoffice-extensions/nested-content/ "The Nested Content Package") that allows doctype types with doctypes! Very powerful.
• Property Editors - the widgets, textboxes and checkboxes that you can enter content into. A doctype is made up of multiple property editors.
• UaaS (aka "You ASS!") - Umbraco as a Service. Automated hosting of Umbraco in "the cloud" on Azure
• Packages - An installable plugin of goodies/functionality that some one else has written to extend the core Umbraco functionality.
• MVP - Most Valuable Person, someone selected by the community/HQ for their work done over the last 12 months
• AngularJS - The JavaScript framework that the back office of Umbraco is written in, uses version 1. Version 2 is now out so you might hear lots of talk about that; they are not compatible though so no easy upgrade, but it won't stop people from asking "When are you upgrading...?"
• Ole Erling - [the man, the legend](https://da.wikipedia.org/wiki/Ole_Erling "Ole Erling's Wikipedia Page"). The music entertainer during Bingo every year. Sadly passed away earlier this year. Gone but not forgotten.
• uHangout - [weekly online chat show](http://uhangout.co.uk/ "The uHangout Website") with Warren Buckley, give it a watch.
• Skrift - The online unofficial [Umbraco magazine](http://www.skrift.io "Skrift.io"), give it a read (or [submit an article](http://skrift.io/write "Submit an article!")!)
• Unicorns - Yep, there will be mention of these. Sort of the [Umbraco mascot](https://twitter.com/naepalm/status/740549430059933696 "The Offroadcode Unicorn Mug (being used by Janae)"). Niels is known as the [Chief Unicorn](https://twitter.com/radiancebox/status/705885292574543873 "The Chief Unicorn's purple shoes").
• XSLT - the original template language but has since been replaced by Razor (see below). Some still have misty eyes for the old days (known as the XSLT Alliance) but they are becoming a second class citizen of late.
• Razor - the new templating language in Umbraco.
• Bingo (really) - the highlight of Codegarden every year. Played after dinner on day two. Expect the unexpected!
• Retreat - Pre-Codegarden, 20+ people from the community and HQ are locked away at a secret location to discuss the next 12 months of Umbraco. The outcomes often make it into the key note.
• Pull Request (PR) - a way of pushing some code changes/corrections/improvements via GitHub to be considered for inclusion in the Umbraco code base.
• GitHub? - Where the [source code for Umbraco](https://github.com/umbraco/Umbraco-CMS "Umbraco on GitHub") lives.
• Azure - "the cloud" service offered by Microsoft.
• Courier - Black magic... syncs content between Umbraco sites. To learn more, ask Per.
• MVC - [Model View Controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller "Wikipedia can explain it to you!"), the preferred way of building websites. Google it for more info but that should do you if you know what it is.
• Surface Controller - ask [Shannon](https://twitter.com/Shazwazza "Shannon's twitter")...
• NuCache aka "Le Cache Nouveau" - The new way that Umbraco caches data (as compared to the old way)
• Nuget - a way of [managing packages](https://www.nuget.org/ "Nuget.org") within Microsoft's technologies (aka to Visual Studio solutions).
• Contour aka Umbraco Forms - [create forms](http://umbraco.com/products-and-support/forms/ "Umbraco has a full page on Forms")on your site and save the results into Umbraco
• Gold Partners - the companies that love Umbraco so much we give it money to help fund it. Feel free to [buy us a beer](http://umbraco.com/certified-partners "A list of gold partners").
• #H5YR - "High 5 You Rock!" The cheery greeting you will hear most mornings and on any tweets if an Umbracian is sending out some thanks. Made up at previous Codegardens and stuck around.
• #cg16 - The Twitter hash tag for this year
• Tak - Danish for thanks, use it.
• Skål! (Pronounced: Skull!) - Danish for "cheers" when having a drink with friends, use it.

Niels is doing a road show to show off first hand what Umbraco as a Service is all about, how much it has moved on and how to get started. I’ve been following the progress of Umbraco as a Service for several years now since I saw Paul Sterling demo the first iteration at Code Garden back in 2012 ish. It is fair to say it has come a long, long way since that first demo so much so that I tweeted this yesterday after the demo:

Ok NOW I get UaaS. Boy has that come on a looooong way. Excited to get my hands it and give it a push now. Thanks @umbraco >
— Peter Duncanson (@peteduncanson) March 15, 2016

If you are not following me by the way you should be! ;)

This got a few folks asking questions about what convinced me or gave me that “light bulb moment” where I “got it” so I thought I’d write a longer response which is the one you are reading :)

Right, I’m going to assume you’ve at least heard of Umbraco as a Service, if not head over to here and have a read first. Now with that done here is my very short summary of it as I understand it:

Every website needs a server to run on and a database to talk to, setting this up can be a sticking point for some and a drain on resources for others.

UaaS’s aim is to be a super quick and easy way to get started with Umbraco and tick the “oooh what about hosting?” query off the todo list asap.

Under the hood it uses Microsoft’s Azure hosting infrastructure and the BEST of it too, as Microsoft are a partner. Like any service you sign up, hand over your credit card details and then get stuck in. You can have a (empty) site up and running in less than 5 minutes. Then you can start doing your Umbraco magic and focus on the build.

That is it in paragraph. If you use Umbraco a lot you might not see what the fuss is about, you could probably get a site running on your own host in about the same time I imagine. But UaaS gives you more than just a quick site setup.

Other goodies worth a mention that you get included are:

• A dev and live environment so you can develop on one and have the client add content to the other.

• Decent merging tools (Imagine Courier that works) that can handle 99% of cases

• The initially terrifying thought of “Automatic upgrades” - only patch releases are automatic and these “shouldn’t” break anything. Minor and Major releases you have to manually initiate via a button click in the UaaS portal and you can roll back from them if it all goes wrong.

• The ability to download the site via Git and the Content via the back office and run it locally

• Chat window for instant help from the UaaS support crew (I’m assuming within office hours but who’s office hours? This is after all a global business)

• Support for enabling edge cases if needed (hosting 2Gb of media on a shared blob storage for instance instead of the standard method) although further fees may apply if you are using up Azure resources.

Now, I’m quite up front that I was a little dubious about UaaS and it was only really this last month that I’ve been coming around to the idea. I’m not really their target market, we tend to work on a handful of big sites each year rather than knocking out 6 small sites a month like some, so I have just been watching from the sidelines. In the last month I’ve seen two really good solid demo’s of it (at the awesome uWestFest keynote in San Diego and in Manchester yesterday) and I’ve had lots of 1-to-1 time with Niels and others at HQ to get a feel for it and run my “what about this” questions at them. I guess you might at least have had some of the same queries yourself about the whole setup so I’ll try to act as your “man on the scene” and give my take on why it is worth a look and when.

How to “Get It” about UaaS

“Getting it” with Umbraco as a Service is really easy once you understand that it is not a solution for all builds. Chance are you might come up with a build that is just not a good fit. The danger is you assume HQ are trying to build a solution for everything but they aren’t as that would be madness (we’ve burnt that card with V5 remember, they learnt from that one...big time).

So the only question you need to ask yourself to know if it is suitable for your build is:

“Am I going to be doing some crazy ass shit with this build?”

If you answer “yes” then you probably want to roll your own hosting setup, if you are smart enough to be doing “crazy ass shit” (CAS for short) then you should have no issue in rolling your own hosting, heck you probably already have some if you fall into that bracket, well done you! Have a biscuit.

If you answer “no” or “erm...not yet but maybe in the future” then you are safe to give UaaS a go. That “maybe in the future” CAS you mentioned might never come up and if it does UaaS doesn’t lock you in, you can pull the site down local (even the DB) and then host it anywhere you like with your awesome existing hosting knowledge.

UaaS is NOT a solution to every possible way of building Umbraco sites. It is not a magic bullet. Its a 80% solution in that it is built to suit 80% of the Umbraco builds out there. So don’t try to shoehorn in your build to it if it is not suitable. Stop when you feel resistance...that to me was the boundary I needed to see the use of UaaS and when I should/could use it. Until I got that I just saw it as a solution that was not going to work as I mostly do CAS.

To clarify what CAS might be is hard, as we all have different opinions of what CAS might be. You will probably know in your heart of hearts but as a guide I can say it is NOT any of theses things:

• Custom database tables - totally do able with UaaS

• Running a rather large site - UaaS sites can get pretty big and handle it no problem, how big is big is hard to say but if you are worried about the size of your site then you might be trying to do CAS so contact Umbraco first.

• Custom DLL magic - you can obviously include your own code and DLL’s, that’s not CAS that just development right?

• Calling out to API’s - sure just don’t go all CAS about it, clean up after yourself like you would any other hosting environment

• Lots of media - to a point sure, as mentioned above if you need a shared media folder/blob storage (to save you having to pull all that media down to develop locally) then that can be arranged just get in touch with Umbraco.

• Oooh it might get a lot of traffic - no problem you are using the BEST hardware Azure has, its the secret stuff that us normal folks don’t normally get apparently. As a results they can handle a lot of traffic. If you think you need multiple servers and all that stuff from the off then guess what...you are in CAS land, this is not the hosting solution you are looking for...move along.

If you have to ask “yeah but can it push to multiple instances on different domains with shared content that can be hidden depending on an LDAP authentication service talking via EDI messages…” type queries then chances are you are into CAS territory. But if not then the answer is probably “yes, it can do that”.

"Yeah but what about..."

Stuff you need to know as I understand it (this might be wrong/change) and I’ve numbered them so you can comment/refer to them if need be:

1. You control what content goes up to live and when (manually select the content and queue it up to deploy)

2. You can edit content and features in either DEV or LIVE...eeek! Don’t worry this is handled by the other stuff below

3. Content and features can be deployed to/from DEV and LIVE environments separately which I thought was a cool feature. This prevents dummy test content going up to LIVE by mistake.

4. Deploying features to LIVE from DEV is an all or nothing option, you can’t cherry pick individual doc type mods to deploy (I’ve another blog post about a tidy way around that coming soon)

5. Content from LIVE pulled to DEV will out trump any content on DEV and overwrite it.

6. Functionality and doc type changes pushed from DEV out trump any changes on LIVE. So if someone has been messing with doctypes on LIVE they will get overwritten (Morten @ HQ is the master for this stuff).

7. At anytime you can take a fresh copy of LIVE down to DEV and any functionality changes on DEV are kept, this allows you to quickly get a fresh copy of the content and media of the site for instance so your new feature is working with up to date real data which makes your testing better.

8. Under the hood a lot of the merge magic is handled by Git (a popular source control system). If you can use Git then you can develop stuff locally and check it in and it will get up to DEV. Its expected that you work on a local copy of the DB and not connect to the DEV DB. This is “easy” to do as when you pull the site from Git you can also get an up to date SQL CE database, this uses some new code magic to load up the database with the content. This might be a bottleneck if you have a tonne of content but then you are in CAS land again.

9. Doctype definitions etc. are still stored in the DB but also serialised to disc so they can be sourced controlled. Pretty cool and one of the dream items from Code First land...ahhh remember those days?

10. Members aren’t sync’ed between DEV and LIVE which makes sense but might make “real” testing harder.

11. Minor/Major upgrades are triggered by you and are done onto Dev first so you can test. Only if you then deploy from DEV to LIVE will that upgrade go live.

12. No Remote Desktop Access at all, best you can do is use Microsoft’s command line tool called Kudu, its sort of a mix between SSH and Powershell by the look, hopefully a bit easier to use than both of them :)

13. You can have custom “baseline” builds to spawn a new site from, think of these as turbo charged start kits of your own making. Probably the most talked about area at the roadshow

14. Updates to a baseline build can be pushed out to any child builds spawned from it (like upgrades you have to manually initiate this step per site for safety).

Right the other “what about this situation…” queries you might have:

• How many baselines can I have - Each baseline build counts as one of your sites so it costs another 89Euros to have it floating around (hey, relax, it is using up resources after all). So you need to allow for that. You might be able to get done what you need via a Package instead but you don’t get all the goodness of Baseline builds.

• Can we share baselines/sell them? - Maybe in the future, right now though its a no. Baselines are private.

• What if I have a merge conflict in Git? - Pull it local and resolve it like you would normally. If it is a normal build and you are not doing CAS then you should never need to do this. Umbraco does some magic to limit conflicts as best it can according to Morten @ HQ.

• How many users can I have? - As many as you like, seems you can invite folks by email but it looks like it is on a per site level. Would be nice to be able to just “invite the team” via a button/default. You can invite clients or outsourced help though per project this way.

• Can two devs work on the same page at the same time - yes, but you “might” cause a merge conflict (if you both changed a property alias name for instance).

• What if it goes down? - Hosting does go down, you and about a million other sites on Azure will be down too, what can you do?

• Is there an SLA? - Yes and its good enough and had lots of 9’s in it. Umbraco should have details

That covers the obvious questions you might have. If you have others I’d suggest you get yourself off to one of the UaaS roadshows or catch one of their webinars that they do every now and then or just get in touch with Umbraco and ask. All I ask is you share what you find :)

Take some of what I say above with a pinch of salt, this is info I’ve gained from just asking questions on the spot so it might not be 100% right or might change but it should be in the right direction at least.

Executive Summary

The short version is Umbraco want this to work, they want it to be helpful and they want you to use it if it is suitable.

The cynic in you would say “of course they do they want my money!” and you’d be 100% right, of course they do, that is how this totally free CMS that gives you a career is partly funded.Gold partners, like us here at Offroadcode, fund another chunk of it (you owe me a beer btw) and training fills the rest so get over it and take another look.

To their credit they have held it back and iterated over it, polished it and honed it to get it in the best state they can before offering it up to us. It is now a very polished product and worthy of being on the options list for your next build. Assuming of course you are not doing CAS. If in doubt ask them, they are super keen to hear your thoughts and iron out any issue BUT there is a line where it won’t be a good fit, knowing about the line for me was the Aha! moment as to why it is a great product. Constraints allow you to build awesome things, as long as your site is within UaaS’s constraints then it should fly!

Thanks for reading, tap me up on twitter if you have a query/correction.

It would have been lovely to have won the award having had a really fantastic year working on some exciting projects including a complete redesign and rebuild of the booking system for our long term client Olympic Holidays as well as completing a significant redesign and full rebuild of Selby College's website.

Our nomination for the award was to celebrate the massive improvement the new responsive website has had on Selby's engagement with students and the increase in applications and enquiries for courses which had a massive, direct increase in revenue through the website.

Working with both Selby College and Olympic Holidays has been great fun this last year and we've delivered a great deal of measurable design success along with extending what we've been able to do with Umbraco and ReactJS.

Sadly in the end, we didn't quite win in the Creative business category but we were thrilled to make it through to the final 3 in a very competitive field this year. Congratulations to fellow Huddersfield companies Split Pixel and Progress Packaging who ultimately picked up the prize, we hope you enjoyed the night as much as we did.

It's been a great year for us as a company, we have expanded to welcome Janae and Kyle and taken on some wonderful projects (always open to taking on more though!) and launched some really exciting work so here's to next year!

Not only is it amazing to be recognised but we feel it is the cherry on top of what has been a tremendous 12 months in terms of the work we have done and the increase in numbers we have just made to our lovely team.

The awards were established in 1985 and are presented to a varying mix of local businesses judged to be worthy of winning! We will be featured in Close Up business magazine next month and entered, along with the 11 other monthly winners, into the Business of the Year award where we will attend a swanky awards breakfast.

It looks like we are the first winners of the new cycle as the yearly awards have just happened, so we have almost 12 months in which to grow more and prosper before we find out if we have won the big one!

@Naepalm & @cssquirrel

Both are firm favourites in the Umbraco community and we've had the pleasure of working together in the past so when they became available we knew their knowledge and experience would be an excellent complement to the existing team.

Their combined skills include more than just kung fu flames, Janae will be helping with a wide range of front end design iteration and development, UX and prototyping as well as Umbraco development while Kyle adds a mind boggling amount of javascript experience and front end development skills (and of course more Umbraco).

As we take on more projects; working direct with clients, fellow Umbraco providers and Gold Partners we're also digging into the exciting world of ReactJS we have more ability spread out among the team and the added benefit of spanning two timezones which will be great for helping deliver our projects in an even more timely manner than ever.

They will be joining us in the UK in a couple of weeks to meet everyone face to face and catch up with how we all work before heading back to Bellingham in Washington and working as a remote team.

Now to begin a new chapter as an international company with staff literally spanning two continents!

Welcome to Offroadcode Janae & Kyle

#H5YR