by

Which JavaScript framework is right for Tridion?

You’ve read my previous post on JavaScript frameworks, and you’ve established that you should definitely use one with your Tridion implementation. Ok. Fine. But which one? There’s so many!

I’ve shared my thoughts on some JavaScript frameworks in chats, emails, and discussions. So below is a quick summary of what I’ve been saying over the entire year, as it comes to JavaScript frameworks and Tridion.

React

Especially where native apps are concerned, React (and its sibling, React-native) are a good choice . React is event-driven and state-driven by default. Originally React was supposed to be the “V” of MVC, but it’s since grown into being a full framework. React has a great, well-supported ecosystem (It’s backed by Facebook, after all).

React makes use of the “Virtual DOM” or shadow DOM, which make it super performant. What it does is “pre-render” the markup, before it’s actually set in the DOM. Then when something changes, it does a “diff” to see what changed, and it only updates the DOM with the changes the DOM actually needs.

Gotchas

  • Doesn’t have Routers and Controllers built in. But that’s what the ecosystem is for.
  • State flows down, not up. But that’s what state managers like redux are for. You can work without a state manager,
    but only in small apps.
  • Templating surprises. React uses JSX. JSX says You have to use classname instead of class, and you can only have one root element, which can bloat markup. But you can use React without jsx. Also, JSX is barely a syntax; you mostly don’t notice it.

I’ve learned

React is all about state. There is no “react as you go”; you have to plan ahead of time what state is, what affects it, and where.

The fact that React calls these views “components” is really handy. It’s an easy way to align a React component with a Tridion component.

But React doesn’t lend itself to “hybrid” mode, where part of the page is static, and part is React. Reactifying part of a page could be problematic just because of how it wants you to mount elements. But, React’s idea of components and inheriting state and props works well with Experience Manager’s concepts of regions and component presentations.

React is good if a front-end guy is doing all the work.

Angular

Angular is the first big client-side framework. Angular loves it some 2-way data binding, which is how it’s a great choice for charts and tables. Any time a user has to interact with and manipulate data, Angular makes sense. The data-binding makes it easy to build forms and calculators.

Angular uses scope on “components” that enable those two elements to talk to each other; that’s how the data-binding is working. Angular 2+ is built on Typescript, which makes it a great choice for developers coming from statically typed languages. Angular has controllers and routers built in.

Gotchas

  • Requires Typescript. I don’t like Typescript. For me, coming from a JavaScript background, TS feels entirely unnecessary.
  • Robust templating syntax. Templating is done with directives and attributes on elements.
  • Directive syntax is uncomfortable. Compared to Angular 1.0, or templating systems like Mustache or Handlebars, Angular’s syntax is different and requires learning.
  • Dependency Injection. Not inherently a bad thing, but Angular wants DI way more than React.
  • File size. Angular just comes with more by default, so that means you’re sending more to the end user

I’ve learned

It screams, “I hate the browser, JavaScript, doing anything fast, and I love skipping version numbers“. By some strange coincidence, back-end developers and Microsoft fans really like it.

I wasn’t happy with Angular 2.0. I’m no more pleased with subsequent versions.

Angular’s templating parts do align with the kind of templating you’d do in traditional content management. It seems to be somewhat easy to angularify a part of a page since angular allows you to create “directives” which are “custom html elements” that you can drop on a page. If you’ve templated in DWT or Razor, it can be easy to see how the same templating ideas apply in Angular.

Angular is a comfortable choice for Tridion developers who are used to working in the back-end.

Vue

Vue goes back to being what React used to be; just the view. Also like React, Vue has lifecycle hooks that are really useful when you have to be event and state driven. Vue also uses a virtual DOM that behaves similarly to React.

But Vue also offers a legitimate templating syntax. Part of that templating syntax includes an ability to use 2-way data binding.

Gotchas

  • Like React, it doesn’t have any controllers or routers built in. But that’s what the ecosystem is for.
  • Robust Templating Syntax. Templating is done with directives and attributes on elements. But if you’ve used other JS templating frameworks, it’ll be familiar.
  • Data must be a function. You can attach data to a component, but Vue insists that it be a function that returns an object. That’s annoying.
  • Data is always watched. Vue adds its own observers to your data, which means you can’t go adding new data after a component’s been mounted. You need the data to already be there. i.e. don’t replace an array, add to it or remove from it. But if you’re coming from React, or already using a state manager you’ll be comfortable with this

What I’ve learned

Vue is a really good blend. It offers sensible templaty things out of the box which easily align with content management-style templating.

Vue’s decision to watch all of your data makes it somewhat of a pain to figure out how to properly and safely change data as a result of events. But that’s just a learning curve thing. The fact that it’s watching that data for changes is also really handy, because that’s what’s triggering DOM updates. Vue would probably work great with Experience Manager.

Vue is probably the best for a “hybrid page” because it’s easy to attach Vuey parts to an element. You can also limit the scope of a view so that it only works in other views. You can use it without a state manager, but the fact that it sets watchers on all your data up-front means you’ll likely go nuts trying to not use one.

Front-end and Back-end people could work on Vue together and probably not hate each other when the project is over.

Other Frameworks

Angular, React, and Vue are the ones I have the most experience in. There’s others that might be worth knowing when trying to take Tridion content into the client-side experience.

Preact

Preact is the lightweight version of React. It’s got a lot of the same features and behaviors. React is just smaller, and fixes a few “stupidities”. It gives you the ability to write class instead of className in your templates and it batches DOM updates, which makes it faster.

Gotchas

I haven’t personally worked with Preact so I can’t tell you where I’ve been burned. It fixes the templating things I don’t like, but otherwise carries over the same ones you’d see for React.

Handlebars

Handlebars is just templating. That’s it. No fancy View stuff. No data. No states. No props. Just a quick and easy way to update parts of HTML. Handlebars is based on to mustache, which advertises itself as “logic-less templates”, and it’s pretty much right.

There’s a syntax for Handlebars, but it’s pretty straightforward.

Gotchas

  • You have to do everything else. Seriously, all you’re getting is a syntax for templating. Models. Observing data. Routing. Controllers. You still have to do all that.

What I’ve learned

Handlebars is fine for quick prototypes, or maybe small amounts of isolated templating. In an interactive page where a few changes affect only a few content points, Handlebars could make a lot of sense. If the HTML doesn’t change, but the text inside of it will, Handlebars would be a good choice.

I wouldn’t build an entire MVC app with Handlebars, though.

Jade / Pug

Originally called Jade, but renamed due to trademark infringement, this is a templating language and HTML build system.

Pug seems to want to be a server-side templating system that you can use as a framework so long as you’re running node.js

Gotchas

What I’ve learned

Pug is useful if you needed to do a prototype of something in under 15 minutes. That’s why codepen.io offers Pug as an option. But it should never be used for anything other than that. The truth is, Pug is a disease whose only treatment is full lobotomization.

Unlike Markdown, which aims to make it easier to work in a small section of HTML by using a syntax that’s memorable and unobtrusive, Pug takes a shit on all the easy parts of HTML, scoops it into a bag, and sets it on fire in your workflow— which fails every time you blended whitespaces.

Pug doesn’t even fit well into MVC.

Pug is pants-on-head dumb.

TL;DR

React is probably the best choice if you need a true app that needs to be native. Vue is fantastic because it has the best parts of React and Angular. Angular isn’t my first or second choice, but it still has some solid use-cases.

If someone suggests using Pug/Jade, you should run very, very far away.

Tell me what you think