What are the pros and cons of Sitecore over other content management systems?

Sitecore is a powerful .NET framework and is almost entirely customizable down to its own user interface. It leverages much of what makes .NET great like the role-based security. It allows for a modular templated architecture based on data templates that if done correctly provides a developer with a code-less, do more approach in which content types inherit values and parameters and can be nested to fulfill complex business rules (hierarchical or otherwise) and re-used everywhere. Its API allows for almost complete control of the rendering pipeline, with database-driven content completely divorced from presentation allowing for customizable rendering rules like persona-based personalization, custom device delivery, multi-site (reusable architecture), multi-language and A/B and multivariate testing. Sitecore requires a lot of configuration however both to function as desired and in order to be easy to use. And therein lies the rub, by being so open, so configurable, many developers that cut corners also wreck the content manager’s user experience and make the whole solution difficult to manage, upgrade and deploy.

With its great flexibility for the developer then, comes with great responsibility. You can start with a great platform and get a lousy implementation. Developers who fail to treat the Sitecore platform and their website as an application and apply ALM best practices can easily create an undocumented mess of code and architecture. If programmatic rules are used rigidly without overrides, a content manager can feel hamstrung especially if tiny tweaks involve development and deployment (isn’t that the point of a CMS, to alleviate the need for development). HTML and CSS can be used in-line and hardcoded to particular front-end frameworks to a developer’s peril. However, if you build on a solid foundation Sitecore can act as the integration framework for all your web services, back-end processes, and customer analytics (via the MongoDB platform or xDB, experience database). A developer can build custom e-commerce experience, integrate with CRM, ERP, and manage content for non-sitecore sites, mobile apps and kiosks. If I were a company banking on providing a great user experience for my customers, partners and power users, I’d invest in Sitecore, but I’d also invest in a great technology provider to implement it.

The future of React Native?

The increasing demand for faster app development might be the reason why cross-platform applications are on the rise. In fact, React Native is already perceived as a viable solution to create quality software and its use expected to grow in the coming years. 

Yet, not everyone agrees that it’s the way forward for mobile app development. And rightly so – there are still some technical drawbacks that are holding React Native back, not to mention that it generally offers slower apps when comparing them with native solutions.

Despite the constant advancement of React Native, it does not provide ready-to-use modules that give access to iOS or Android APIs. This forces developers to create so-called Native Modules themselves or develop “bridges” using Java/Kotlin (Android) or Swift/Objective-C (iOS) and severely increases software development time.

Developers bring up one more problem with React Native technology — software debugging. It is much harder when using RN. It comes down to faster development but longer problem-solving which results in less accurate cost estimation (especially in case of Android).

The framework might look strong on paper, but many well-known apps (such as Airbnb or Udacity) has actually switched back to native development. Therefore, even though React Native is definitely a trending topic at the moment, only time will tell if it has the power to outshine native technologies.

What will be the dominant front-end technology in 5 years time?

In short, you might as well play roulette and bet on black, because nobody can answer this question with fact. We can only present hypotheses.

The world of web development, especially front-end development, evolves about as quickly as the physical tech industry does, and there is no way we can predict what Samsung, Apple, Nokia, and the other’s will churn out in even the next two years. Much less five.

Let’s look at a bit of JavaScript history.

Build Tools (2014 – 2018)

  • Three years ago, Grunt was the dominant build tool.
  • Two years ago, Gulp rose up and stole the throne.
  • One year ago, was Webpack’s claim to fame.
  • Somewhere in there, Browserify fought a good fight.
  • At one point, plain npm scripts became a fad.
  • When I wasn’t looking, Rollup rolled out.
  • Along the way, I built Owlister. (It is junk. Don’t look.)
  • Now, Webpack dominates, but tomorrow is unpredictable.

Transpilers (2009 – 2018)

  • Eight years ago, Coffeescript became Earth’s favorite abstraction.
  • Six years ago, Dart arrived like a drunken monkey on weed.
  • Five years ago, TypeScript was born, bringing type safety to JavaScript.
  • Three years ago, Babel arrived to let us use future JavaScript today.
  • Two years ago, Elm became a buzzword. (Nearly irrelevant, but not quite.)
  • Now, TypeScript and Babel rule. Seemingly invincible? Time will tell…

Frameworks (2010 – 2018)

  • Seven years agojQuery was the most suggested JS “framework”.
  • Six years ago, Backbone and Knockout were widely adopted.
  • Five years ago, Angular and Ember took the stage.
  • Four year ago Meteor stormed the gates and built a following.
  • Three years ago, React took its first breath. The prophecy…
  • Two years ago, Polymer and Vue made names for themselves.
  • One year ago, [Angular 2 and Vue 2] released, [bombing and succeeding].
  • Six months agopeople quit caring that “React is not a framework.” Don’t.
  • Now, Angular 4 has arrived, React dominates, and Vue is a super-power.

*These numbers are not exact, but even the absolute correct time-frames would reveal an identical pattern of “king of the hill”. Don’t grill me.

But wait, there’s more!

In the midst of the frameworks timeline, there have also been countless other contenders take a shot at stardom. Aurelia, Riot, Spine, Dojo, Deku, Inferno, Mithrill, Stapes, Svelte, etc. Any one of these lovely ladies could become the new hotness in a matter of weeks. We just can’t tell.

If I were to revisit this answer in five years, I’d most definitely be adding weird framework titles to my timelines above, as even the power-houses of today will not last forever. These tools will probably be such that I have never even heard of at this point in time.

Behold, WebAssembly.

WASM is… difficult to explain. Simply put, WASM allows developers to compile most any language into performant, browser agnostic byte code. What this means is that the front-end community has the opportunity to detonate yet again with a landslide of developers from all walks of life developing for the browser.

JavaScript has done its job well, but as the world progresses it will be replaced. That time could very well be within the next five years. The murderer could be WASM or it could be a new browser that takes a majority of the market share that allows developers to write their applications in Haskel. Improbable, yes. Impossible, no.

The Safe Bet.

As it stands, our best guess is that JavaScript will still dominate the browser in five years. That said, your best bet would be to acquire a slew of developers who are tool/framework agnostic by means of deep JavaScript understanding. Don’t allow yourself to be contracted to a specific tool. I guarantee you that Angular, React, Vue, Backbone, Aurelia… none of these guys will reign in five years.

Those who become proficient with languages and have a firm understanding of design patterns and architecture will have no problem adapting to future tools and are, in essence, future-proof.

Why do backend developers have more confidence in their profession than frontend developers?

Because 99% of the time when someone identifies as a front-end developer they are saying that they have not been a developer for very long.

Think of it this way. On the web, Ajax was “invented” in 2004 (actually Outlook was doing it in 1999 but shh…we can’t give Microsoft any credit). It did not become a central part of most web developers’ lives till 2008/2009 or so. Even then, Javascript was avoided by many until frameworks started coming out in the early 2010s.

So what were people who were already established developers pre-2010 doing? Working largely on the back-end. So now that they do a lot of front-end work too, they face the choice, do they brand themselves as a “front-end” or a “full-stack” developer? I certainly choose the latter.

Which leaves most people who embrace the “front-end” moniker as people who have been coding professionally for less than six years. So yeah…they’re less sure of themselves.

For the record, I use the “front-end” and “back-end” terms above in the manner I see them used more often, with “back-end” meaning server-based languages, databases, etc; and “front-end” meaning HTML, CSS, and Javascript. Personally, I dislike those definitions and prefer “back-end developer” to indicate how good someone is at understanding architecture, performance, databases, and security; and “front-end developer” to indicate to what degree someone thinks about human-computer interaction, responsiveness, UI optimization and reusability, browsers, responsiveness, and accessibility. When you formulate definitions this way you start seeing these as two largely orthogonal dimensions of a square, rather than anything mutually exclusive.

Disclaimer: I use 99% rhetorically. It certainly is an overwhelming majority but I haven’t done any data gathering on the subject. That being said, I certainly don’t claim that front-end development is easy. There’s a huge amount of churn. There aren’t many other areas of development where people have to actually stay on top of language specs. 

Why React Dev’s Like to Hate Vue.js

After having worked on React development on medium/large scale apps, I have to admit that VueJS is like a breath of fresh air.

In my opinion, most developers are having as I call it the “Simplicity (Un)reasoning” bias, which means: if it is simple to learn, simple to use then it is for simple projects. Crazy right?

Meanwhile, the arguments in favor of React or Angular 2+ are dubious as well.

Angular is for large teams because it enforces you to write code in a typed way because of TypeScript. Yes but React and Vue support TypeScript or Flow not to mention that Vue’s lifecycle events are more clear cut than React’s.

Vue has only one person writing code. Not anymore.

Vue is for simple projects. Maybe you should read how Adobe is using it these days.

I am not writing this specifically for Vue but believe me that this simplicity can be found in other libraries as well e.g. RiotJS, StimulusJS etc.

Unfortunately, React and Angular have excellent marketing strategies, which plays a major role since they are trying to sell longevity instead of code happiness. By code happiness I mean the factor which make your developers happy to write code they understand and are proud they wrote it. With React and Angular I am not that happy, especially with React.

With Vue the selection was being made from a pool of 10+ team leaders because it just works as it should out of the box. Their vue-cli is also in the same league angular-cli is, but the difference is were angular could not operate very efficiently without, Vue could work without it with no problem.

Finally, I have to point out that lately among the majority Front-End developers, there is this strange notion that if your code is easy to understand, not very complicated and not using the latest ESxxx you are doing something wrong. If you look at Angular you have to learn RxJS, TypeScript etc. and even if you are not satisfied with this selection few will admit it. We have to get rid of the herd mentality and marketing strategy of 2–3 large companies and exercise common sense and independent spirit.

Is Web Development Dead?

Personally, I’d give it about 5 to 7 more years, maximum 10. I’d even kill off web design alongside it. I am talking about website development, specifically where the developer is concentrating on writing code that manifests directly on a website, rendering HTML and Javascript.

Web development is a broad term though because API development that manifests as JSON data across HTTP requests could also be considered web development.

When web design was a top role for designers, about 12-15 years ago, it was because design demands were rooted in print design. This was before mobile phones were a viable browsing tool, so you could bank on having consistent screen sizes. This was also at the time when broadband for the home was common enough that the average person could view a complex website that was so abundant with a skeuomorphic design that the bandwidth requirements were high, but the quality was high as well. As a result of complex design, web development was also a dominant role, because it was a lot of work to develop alongside that complexity of the design.

But as mobile device usage has grown, and the separation of concerns from websites being king, to instead a combination of websites, apps, and other services, the website’s need for being gloriously designed decreased. Given that we continue to have an increase in device variety, this trend is not going to reverse itself. A simple, clean design is best suited to auto-adapt to the variety of screen sizes and types that will be available for decades: visually, this is all the way from a wristwatch to a billboard.

Based on that, the majority of website development has already shifted to more data-centric work, above design-centric. If I’m viewing website content on my computer, the design might matter to me. But when I switch to my phone, design (at least, heavy graphical design) is only going to get in my way. The design components that will matter on my phone are color, typography, readability, etc. There will still be a need for designers, but far less than what we needed a decade ago, and certainly less than we need now. Designers will need to branch into more cross-device creative direction than simply “website design.”

And developers are already heading that way, by avoiding design and focusing on API development, which is critical for driving website content while also driving the two other most important technologies needed right now:

  • Apps, which are currently manifesting primarily as mobile apps, but which also include voice-activated apps, and VR apps (through independent devices like what Google tried with Glass), and
  • Integration, which is the data-sharing aspect of API development that allows the data from one app to be integrated with the service of another app to provide suite-like features across disparate systems.

When a design is needed, most of the existing frameworks can already handle 95% of the design needs a company has. What we’ll be lacking though, unless the trend changes, is qualified business experts who can properly capture web application needs from business owners to develop solutions that fit company requirements. The demand will be on making custom applications at a fraction of the cost of what it used to be. The more APIs there are out there to perform the functions we need, with integration at their core, the more a website is just going to be a clean merger of technologies from a variety of sources, and design is going to remain minimal, because that same content needs to adapt to varying phone sizes, a watch, a lens over my face, an audio interface reading back to me, VR projections from a headset, and so forth.

So web design and development as we know it today, is going to be mostly gone within a decade. API development, app development (in many forms) and systems integration will be the primary focus.

What is React? The good, the bad, the ugly.

What is React?

How does React compare to Angular, Ember, Backbone, et al? How do you handle data? How do you contact the server? What the heck is JSX? What is a “component”?

Stop.

Stop it right now.

React is ONLY THE VIEW LAYER.

React is often mentioned in the same breath as other Javascript frameworks, but “React vs Angular” doesn’t make sense because they aren’t directly comparable things. Angular is a complete framework (including a view layer), React is not. This is why React is so confusing to understand, it’s emerging in an ecosystem of complete frameworks, but it’s just the view.

React gives you a template language and some function hooks to essentially render HTML. That’s all React outputs, HTML. Your bundles of HTML / Javascript, called “components”, are allowed things like storing their own internal state in memory (such as which tab is selected in a tab view), but in the end, you just barf out HTML.

You absolutely cannot build a fully functional dynamic application with React alone. We’ll learn more about why below.

The Good

After working with React for a while, I’ve seen three very important benefits surface.

1. You can always tell how your component will render by looking at one source file.

This may be the most important benefit, even though it is not different from Angular templates. Let’s use a real-world implementation example.

Say you have to update your site’s header with the user’s name upon login. If you’re not using a Javascript MVC framework, you might do this:

I can tell you from experience that this code will ruin your life and your friends’ lives. How do you debug the output? Who updated the header? Who else has access to the header HTML? Who holds the source of truth for the name being visible? This DOM manipulation is just as bad as a GOTO statement for reasoning about your program.

Here’s how you might do it in React:

We can tell instantly how this component will render. If you know the state, you know the rendered output. You don’t have to trace program flow. When working on complex applications, especially in teams, this is critically important.

2. Bundling Javascript and HTML into JSX makes components easily understandable.

The weird mix of HTML / Javascript soup above might make you cringe. We’ve been conditioned to not put raw Javascript in the DOM (like onClick handlers) since we were wee developers. You’ll have to trust me, though; working with JSX components is really nice.

Traditionally you separate views (HTML) from functionality (Javascript). This leads to monolithic Javascript files containing all functionality for one “page”, and you have to trace complex flow from JS > HTML > JS > bad-news-sad-time.

Tying functionality directly to markup and packaging it in a portable, self-contained “component” will make you happier and less filthy in general. Your Javascript has intimate knowledge of your HTML, so mashing them together makes sense.

3. You can render React on the server.

If you’re building a public facing site or app and you’re following the render-it-all-on-the-client path, you’ve already done it wrong. Client-only rendering is why Soundcloud feels so slow and why Stack Overflow (purely server-side rendering) feels so fast. You can render React on the server, and you should.

Angular and others encourage you to do disgusting things like render your page with PhantomJS and serve that to search engine crawlers based on user agent, or pay actual cash money for that as a service. Ugh.

The Bad

Don’t forget that React is only the view.

1. You DO NOT GET any of the following:

  • An event system (other than vanilla DOM events)
  • Any AJAX capabilities whatsoever
  • Any form of a data layer
  • Promises
  • Any application framework at all
  • Any idea how to implement the above

React on its own is useless for the real world. Worse yet, as we’ll see, this leads to everyone reinventing the wheel.

2. The documentation is not “accessible” nor “good.” Again, this is a blog post for stupid people. Look at the first part of the sidebar on the documentation page:

React documentation sidebar

There are three separate, competing quickstart guides. I’m overwhelmed and I’m not even drunk. The sidebar below that is straight out of my nightmares, with sections that obviously shouldn’t be there, like “More About Refs” and “PureRenderMixin”.

3. React is large for how little you get, including how little cross browser support.

 

That’s without the react-with-addons library you will need to actually develop a real app!

That’s without the ES5 Shim library you need to support IE8!

That’s without any sort of application library of any kind!

React is a comparable size with Angular, even though Angular is a complete application framework. React is frankly bloated for how little functionality you get. Hopefully, this will improve in the future.

Stop Saying Flux

Perhaps the most annoying part of React development is “Flux.” It’s far more confusing than React. The name “Flux” is a pretentious barrier to understanding.

There is no such thing as Flux. Flux is a concept, not a library. Well, there is a library, sort of:

“Flux is more of a pattern than a framework”

Ugh. The worst part is the name: React didn’t reinvent the last 40 years of UI architecture knowledge and come up with some brand new concept for data management.

The concept “Flux” is simply that your view triggers an event (say, after the user types a name in a text field), that event updates a model, then the model triggers an event, and the view responds to that model’s event by re-rendering with the latest data. That’s it.

This one-way data flow / decoupled observer pattern is designed to guarantee that your source of truth always stays in your stores / models. It’s a Good Thing™.

The bad side of Flux is that everyone is re-inventing it. Since there’s no agreed on event library, model layer, AJAX layer, or anything, there are many differentFlux” implementations, and they all compete with each other.

Should I Use React?

Short answer: yes.

Long answer: unfortunately, yes, for most things.

Here’s why you should use React:

  • Works great for teams, strongly enforcing UI and workflow patterns
  • UI code is readable and maintainable
  • Componentized UI is the future of web development, and you need to start doing it now.

Here’s why you should think twice before you switch:

  • React will slow you down tremendously at the start. Understanding how props, state, and component communication works are not straightforward, and the docs are a maze of information. This will be countered, in theory, by a grand speed up when your whole team is on board.
  • React does not support any browser below IE8, and never will
  • If your application / website doesn’t have very much dynamic page updating, you will be implementing a lot of code for a very small benefit.
  • You will reinvent a lot of wheels. React is young, and because there’s no canonical way to do events / component communication, you’ll have to build large component libraries from scratch. Does your application have dropdowns, resizable windows, or lightboxes? You’ll probably have to write those all from scratch.