Comparing Episerver and Sitecore

Background

What are the strengths and weaknesses of the systems. What do you need to be aware of as a developer? Which one gives most bang for the buck and which one is more flexible? I'm certified developer in both CMSs and I've built large enterprise solutions in both. These are my humble opinions.

Framework and architecture

Both are based on .NET framework and have support for both webforms and MVC etc and have an SQL database in the background as the main storage of data. Sitecore also has a separate database for personalization in a MongoDB. Extending the CMS is possible for both CMSs where Sitecore mostly use a configured pipeline to make the core functionality pluggable and Episerver uses IoC and standard inheritance etc to support the same. No big differences here and both do a great job.

Performance, scalability and security

Both products are strong in performance that cache most calls towards the database, read only instances of content etc for performance. Both are easy to load balance and run in the cloud so scalability is not a problem for either platform. Security is pretty similar but here Sitecore allows roles to inherit access rights from other roles which is good to be aware of. If that is good or not is a matter of taste. All these non-functional requirements are no problem to fulfill with both platforms and with similar effort from a developer. I'm still waiting for a good flexible SSO solution out-of-the-box from either. 

Data modeling - Sitecore is more complex

Sitecore deals with "items" as a central concept which roughly corresponds to IContent in Episerver. Normally one item/content can be displayed as a web page in the end but it can also be used as a more generic data source if you wish. Items can in Sitecore contain any number of "fields" which is basically a property in the Episerver universe. Templates (read content types in Epi) in Sitecore can "inherit" from multiple other templates. Ok, multiple inheritance. Ouch? Sitecore has a slightly different solution to blocks. Each item that is shown on the web has a layout that contains a bunch of components (basically a user control or a view) that can have another item as data source. Did I loose you somewhere there? It's slightly more generic but also more complex. I do favor the simplicity of Episerver here for both editor and developer. Sitecores way might work well in the future with some clever defaults. Right now it feels like a bridge too far...

Content structure - pretty similar

Both structure their data in a similar tree structure. The main difference is that Episerver store blocks in a separate structure while Sitecore uses the tree structure for all their "items". Media libraries work in a similar fashion and can store files, images etc. They both have ways to reuse content by cloning in Sitecore / use fetch-data-from in Episerver. Blocks make it easy to reuse functionality and content in Episerver and components with a matching data source item fill the same role in Sitecore. Sitecore has a system for inheriting standard values from the template. 

Working as an editor - much better in Episerver

From an editor perspective I would say that Episerver is still far easier to work with. I've held editor trainings in both CMSs plenty of times. Sitecore has two different editors where the Page Editor (in recent versions renamed to experience editor) is similar to Episerver's default dope editor. Looks great on demo but unfortunately Sitecores dope editor is still rather buggy and I continuously need to reload the Page Editor UI to get it to work (rather like it used to with old Episerver 7). It's pretty difficult for a developer to get it working well for an editor so often you are forced to use the other editor that is called "Content editor". This editor is very stable but is mostly intended for developers to setup the website and is pretty complicated. Think "thousands and thousands of buttons". Sitecore is more complex under the hood and it's difficult to isolate editors from that. A few less flashy features like the time machine (that is mostly useful in demos) and some added focus on stability and stream lining work for editors on the page editor would be very welcome improvements in Sitecore. 

Sitecore has a nice feature I like with item bucketing that lets you throw 1000s of items as children on the same node. Doing that in Episerver is really a bad idea since it will make the tree structure in edit mode really ugly. This is useful for large quantities of news items for instance. I also love the word "bucketability".

Make sure you get budget/time/requirements for creating a nice editor experience in Sitecore projects. This is less of a problem with Episerver sites since if you follow the path of least resistance / use the Alloy template project best practices etc, you will get that almost for free. Since developers create their test content in the same interface as the editors use (edit mode) they will usually clean it up decently themselves even without any requirements. Sitecore developers primary tool for creating content is either Sitecore Rocks plugin in Visual Studio or the Content Editor which means its easier to forget the editor experience since the editors should use the Page Editor. Sorry. Experience editor... 

Publishing workflow - Episerver works better

Another got-ya is that Sitecore typically has at least two databases for content. You can think of Sitecores web database as a separate content tree with only the published items (no versions) and then a "master" database that has a tree structure that contains everything that is used when editing. This is a nice idea for performance but also an endless source of frustration. It's easy to forget that what is changed in the master tree structure hasn't really been published (to the web database) yet. And since the actual content types themselves (called "templates" in Sitecore) are items themselves they also need to be published or you will get obscure errors. (This is the part where an Episerver developer starts to use swear words when developing a Sitecore site.) So a fun problem can be that you have created your new template, created the content on the actual item that uses the template, publish the content item but forget to publish the updated template. Not fun at all...and no helpful warnings.
More than once I've had to republish the entire site to get it working again in Sitecore. Or my favorite bug, if you serialize content to export it you can run into a very nasty bug that means you will actually import parts of on item leading to very very obscure errors.

Developer experience - Episerver is more efficient and fun

Sitecore is more complex and might be slightly more powerful if you compare functionality in a list next to each other with Episerver. Unfortunately just because you can build support for something doesn't mean it's a good idea...and that's often the problem with Sitecore. You can have roles that can inherit access rights from other roles. Ok? Is that good or will it actually result in more problems than it's worth? I'm leaning towards the second.
Items in Sitecore is connected to presentation in a very loose fashion where you first choose the presenting component (like a user control) and then the actual item to use as data source. Again slightly more "powerful" and usually resulting in more headaches than it's worth.
You can set the layout (what blocks should be shown on a page) of a template in so many steps and configuration of standard values it's super flexible...and pretty much guaranteed to go wrong. Read this link of how it works and try explain it to your editor
https://doc.Sitecore.net/sitecore_experience_platform/developing/developing_with_sitecore/versioned_layouts/versioned_layouts

Compilation time. Try compiling the Alloy template site, do a change and see how many seconds it takes. A few seconds that's it. In Sitecore that process took for me 2 mins and 31 seconds for a round trip. I don't know about you guys but I do a fair amount of recompilations of a site during a day. If I have to wait for more that 30 ish seconds I will loose track of what I'm doing and go grab a cup of coffee or something. This is not a small thing to a developer.

Moving between environments

This is really easy in Episerver since your content model gets updated from code. Not as easy for Sitecore where your updated templates need to be exported / imported and the published to be possible to use. Not so fun. Sitecore has 3 databases to move (at least) if you want to migrate content that way (+ 1 Mongo db for personalization data.).

Multiple languages and sites

Languages and globalization as well as support for multiple sites work in a similar way. No big differences there. Both have great support.

Standard values and configuration

Sitecore has thousands of rows in main web.config (3969 in my current project to be exact vs 405 in my Episerver project). And it's own system for patching it together with even more configuration at application startup. Add the normal .NET transforms on top of that. Sounds scary? It is. What web.config settings are you actually using? Not an easy question to answer in Sitecore especially if the application won't even start. They would do well to break out that configuration and use default settings instead and only handle changes to the default one. This can be problematic when upgrading a Sitecore solution. 

Sitecore also has a thing called standard values that is used as a magic bullet for almost everything. It's basically an inheritance system for content. If you don't specify content it will use the content specified in standard values item. This sounds fun but is a little like a sawed off shotgun without a safety catch. You will likely blow you're leg off with it. You might think that this is the same as setting the default values for a content type in Episerver but it does so much more unfortunately. Since an item in Sitecore also contains the layout of the item (read: what blocks should be in the content area), they use standard values, that are inherited in multiple steps, to set this layout up. This means that you on the template specify the default layout of the item as standard value and these are then inherited by the instance of the new item (which might override it). Used correctly it's powerful. But there will also be quite a few one-legged developers around...it's difficult to understand, use and easy to get wrong.

Coding new templates / content types

This is what you do most as a developer in the CMS. Templates in Sitecore is still based on magic strings and created in admin mode (or by a visual studio plugin called Rocks which is a must have. So basically they use the same way as Episerver in version 6. There is a third party solution called glass mapper that helps part of the way but coding new templates is still much more fun in Episerver with a strongly typed model. Strongly typed also means you can work with interfaces and similar vs content as a developer and use a lot more of standard OOP principles and design patterns. This usually results in more structured code and less maintenance costs in the long run.

Integrations vs external systems

No big differences here. You will use .NET standard APIs 99% of the time. Episerver has custom content providers that can be used and Sitecore has similar solution. Both will rarely be used though.

Developer skills levels

You get more benefits of senior developers in Sitecore projects. You really need some top notch people to set it up well to get the benefits of its complexity / flexibility. I feel comfortable of leaving a junior developer with an Episerver project for a week or two unattended and they will usually produce something that works.  I would never ever do that with a Sitecore project. An almost senior developer will risk trying to enjoy too much of the flexibility of Sitecore resulting in a too generic solution which few will ever understand or be able to use from an editor point of view (similar to design patterns in .NET where they will likely try a design pattern or two whether they need it or not). If you have a really talented and experienced team and a very large project, they are equally good platforms I would say. Unfortunately that's rarely the case in reality, especially in maintenance phase. Pick your developers carefully in a Sitecore project. 

Profiles and personalization - Sitecore has more advanced options here

Sitecore personalization is more complex. Will it help or hurt in a general project? I think I still enjoy Sitecores possibilities of personalization more over Episerver still. Episervers visitor groups are great and works well for almost every possible scenario. It will be interesting to see what Peerius can bring to the table. Sitecore loves to demo this part of the system of course and they should. Very few customers will actually go into such deep waters of personalization that Sitecore actually begins to shine however. For most customers it will be a theoretical advantage of the platform rather than one they will use.

Summary

Both are great flexible CMSs. I find it hard to believe that you will run into a wall with either CMS where you can't build what you need. Sitecore is slightly more powerful on the paper but in reality not as smooth to work with as both developer and editor. It's better if you need really REALLY advanced personalization in my opinion. Episerver to me is more cost efficient (and fun) to develop for and has a better community which means better support which equals more functionality for the same budget. You get more bang for the buck with Episerver overall and editors love it. Search and building custom forms (Xforms) was long a thorn in the side for Episerver but with new forms addon from Episerver and Episerver Find those limitations are ancient history. Episerver has done the smoothification journey since Episerver 7.5 to 9 and has dared to not focus on new flashy features but instead made it overall easier to be editor / developer. I salute you for that decision. Episerver is still underrated in the global market.