4

I am not sure if I should use SXA in my project. Currently we want to use only the XP but in the future we would like to use XC too.

  • I think I need to create many components by my self because of the design wishes from the GUI team

  • When we later use the XC we only would use the item listings and not the checkout or user registering or the shopping cart.

So, currently I think it's not worth the price and the additional starting time for my Sitecore website when I create a tenant and I am using not enough components out of the box.

Is it hard to create new SXA components?

Our current decision:

  • We have decided not to use SXA in our sitecore project
  • Because it's very expensive
  • It's hard to customize/extend existing SXA component with additional markup
  • We want clear and simple components designed directly from us for us
  • We have a lot unique controls
  • We are new to sitecore and it's hard to learn how to use sitecore with helix pattern right. And with an other technology stack in sitecore itself (SXA) it seems hard to do it the right way because of the lack of documentation for SXA and Helix.
2
  • 3
    I think this may generate opinionated answers. But in my experience I would not recommend any client to do a project without using SXA. It has been the single biggest jump to productivity and consistency in Sitecore ever... Sure there are nuances that can cause issues and its a mental shift in how you build, but once you have done a couple, you wont want to go back to standard Sitecore. I certainly don't
    – Richard Seal
    Aug 28, 2018 at 12:41
  • I would definitely give it a shot with SXA. It just rocks! Great set of components to begin with (and you create all over again to every customer and every project) and you can only focus on components that bring "business" value Aug 28, 2018 at 14:10

3 Answers 3

6

Faster time to market is not a preference, its a necessity now a days.

SXA is not just about its toolbox and pre-built components. Its about the entire SXA Website Development Process which help you to expedite the website development process.

In a non-SXA project you always have dependencies on the previous phase. Most importantly the Content Entry, this can never take place until all the phases e.g. User Experience, Visual Design, Front-End, Back-End are complete. Well there is a delta for the Backend development which can be overlapped with Content Entry but that is negligible. The Content Entry phase gets more bigger when you have Multi-site and Multilingual project to go live with.

enter image description here

Whereas if you are using SXA the Content Entry can start right from the Visual Design phase, when you are done with Wireframing. By Saying that when you will finish the Backend development, you will be having handsome amount of actual Content in place which also helps in more realistic testing compared with testing using Lorem Ipsum content (Which we normally do).

enter image description here

Additionally it also reduces your actual development time by using more than 100+ pre-built components. And most importantly if your designing/content/digital marketing team is skilled enough to work on Sitecore SXA, the time to market can be reduced tremendously. Plus everyone in your team like front end developers, content team and backend developers work consolidated on Sitecore utilizing the powers of SXA hence what all you can expect is a great outcome.

As David said, its not worth re-iterating all the features which SXA provides as you can find them on countless blogs and videos. Hence rather talking about Why Opt-In for SXA, let me list out few points on When and Why Opt-Out for SXA?

  1. Most importantly if your client with Non-Subscription Model is not budgeted to spend cost on SXA Licensing. BUT in your research phase if you find that using SXA can save more money and time on your project, you can try to convincing the client to use SXA.
  2. If you are not starting from the scratch, you are bound to follow the current theme being used by the existing solution (which is not a grid system) and you are not budgeted for the efforts to make the SXA site fit-in your existing solution.
  3. Your front end and content team is not skilled enough to use Sitecore SXA and if you think user trainings for this project is not feasible due to time crunch.
  4. If there are possibilities that the Content finalization in your project will be delayed and can't be available in early phases of project.
  5. As you said if the design requirements of the components are more complex than the OOTB components and number is such custom components is higher. And if you think developing these custom components will be more easier than massaging the OOTB SXA components.

But believe me if you are good with these points you MUST use SXA. I mean its worth trying an Helix compliant platform bundled with good amount of pre-built components available by just drag-drop.

5

Of course, it is worth it! I will not write down all the features again as it was mentioned thousands of times on different blog posts. It's not just about the components which are shipped with SXA. There are much more features which will speed up your site development process drastically. Just a few articles from first Google results:

Regarding the components - believe me, you will not need to create a lot of custom ones. I think, that having 5 custom renderings that is already a huge number when you have SXA installed. Rendering Variants give you such a big flexibility that there is no need for creating custom renderings.

4

I'm still new to using SXA so take my opinion with a grain of salt. I will provide some examples to explain my position.

TLDR What I can say is that there are enough benefits to using SXA that I would recommend it but I can't say it's all green grass and rose petals. There's quite a learning curve as it relies a lot on SPE to create many things which aren't obvious to find if you need to serialize it all with TDS. It also introduces a number of new concepts and moves many things to the content section of the tree which makes it confusing what to serialize and what not to.

On the up side, it fixes a lot of odd behavior that comes with a stock installation of Sitecore such as managing multisite systems, duplicating content trees properly, providing easy access to placeholder settings, easier domain configuration and having a page local or site global datasource folder. It even has a concept of reusable page chunks (header, footer, nav) which I did't realize how much I needed until I had it. All of these things make it worth the using over building it yourself.

Stock Components I think the biggest mental paradigm shift for me is with what components you're provided and how they are rendered. One such example is that components are no longer just a rendering item pointing to a razor file or controller method. They are now modules with a scaffolding infrastructure. On the one hand it's a lot of extra. On the other hand much of it is managed by SPE commands and is easy to add groups of components to one or many of your sites consistently.

All the components require you to create a new controller even though they all basically do the same thing. You can hotwire it so they all use the same controller and you should. It's the exception not the rule that you'll need to customize for every component.

The other side of the coin is that the components that come OOTB aren't worth keeping. You really should build your own. For example, search uses 'scope' items which use a lucene type language which is hard to write and are not as flexible as ContentSearch predicates and can really put you in a fix if you already committed to using it but can't fix the type of problems you may come across.

Navigation items do not store settings in datasources. They use rendering parameters. This means if you want to have a sidebar nav across 100 pages and reuse the same settings you'll be doing it by hand. Rebuild them to use datasources.

Rendering Variants Another new concept is rendering variants. It allows you to manage your markup as content items. Building component markup through the content tree forces an initial static render with javascript later reconfiguring the attributes and visibility because there's no logic built-in. This forces you to make jumpy pages. It's also not immediately clear how painful long term updates will be to these since any change will need to be packaged up and carried throughout environments back and forth instead of through builds. There's also a newish feature to help with logic called Scriban but it's coding through multi-line text field. This is much worse than it sounds. There's little documentation and there's no code reuse across components. I don't recommend it. Render components with cshtml files. It's far more flexible and easier to deploy. Rendering variants are good in theory but bad in practice.

Themes One of the most troublesome parts of it is how our front end developers lives changed with it. With SXA the styles and scripts are stored in the media library and synced up through a gulp task. This works ok on a local environment. As soon as you need to deploy it to a complex web of systems through permission environments it falls apart. No one I work with wants to deploy theme files through packages. It's tedious error prone and time consuming. You can optionally just create items called 'HTML Includes' in the media library to point to the static files. I'd do that and just deploy the js/css with the build like normal.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.