Should I use a JavaScript framework with a Tridion implementation?

There’s a growing trend of ditching traditional “back-end” frameworks for dynamically rendering pages. As the interest in client-side frameworks grows, so does confusion about which one to use. There’s React! But then there’s Angular…and have you heard about Vue? What about Handlebars?

But let’s back up a second. Should you even use one at all?

Tridion implementations don’t need a JS framework

Just because everyone else is doing it doesn’t mean you need to do it. Don’t give in to trends and peer pressure. Don’t use a JavaScript framework just because.

Front-end developers are guiltier than most of cargo cult programming. And we all know that cults are risky business. Right?


Reasons to use a JavaScript framework

Start by asking some questions about the nature of the content.

  • Will content be interactive?
  • Will content be event-driven?
  • Will content be stateful?
  • Will content be consumed in a native app?

Interactive Content

This could be sorting data tables, creating charts. It could be image and video carousels. If a user can tap, click, or keydown on something, that means it’s interactive.

Event-driven Content

If there are events — other than navigating to a page — that, when triggered, require content to be created, updated, or removed that means it’s event-driven. Events could happen in the browser or on the server. Content needs to change as a result of an action.

Stateful Content

Does content need to “know” about certain conditions that were not present at render time? Is there a condition that impacts the rendering of content? It can be hard to tell the difference between “event-driven” and stateful, though. So here’s a quick scenario:

A user enters credentials for a login form, and authenticates. The message the user sees as a result of the attempted authentication is event-driven content.

If the authentication is successful, then the state of the user changes to “authenticated”. This is state changed by an event.

If content on the current page, or another page, is different because the user is authenticated, that content is stateful.

Content in a Native app

This isn’t “responsive” or “mobile”. A responsive or mobile site fits under “stateful content” where a kind of state is “the device”.

I’m talking about an app that is installed on a device via an app store. Whether it’s iOS, Android, or Windows. A user goes to a place and clicks a download button, and now they can consume content without (knowingly) invoking a web browser.

Grade your answers

Four questions with yes or no as an answer. Here’s how you know if Tridion needs Angular, React, Vue, or whatever:

  • 0/4: Nope.Go traditional server-side. No one will judge you.
  • 1/4: Nope—Unless the “yes” was on the native app question. In which case, “maybe”.
  • 2/4: Maybe. Try a hybrid approach where you only use client-side where you need it.
  • 3/4: Yes. You should start looking at some frameworks that might work for your needs
  • 4/4: Danger Zone. Sounds like you’re building an app!
Shouting “Lanaaaaaa!” is not only an option on the table, but strongly encouraged.

Danger Zone?

On a 4/4, you’re not building a website. You’re building an app. Tridion is just a data provider. There’s nothing wrong with that. In fact, Tridion is perfectly capable of doing this.

But you’re in the danger zone because:

  1. Tridion’s Content API hasn’t been released yet. Ideally, hold off on this project until the latest version of Tridion comes out
  2. You have different architectural considerations to make for apps.

Do What’s best for the user

You may score 0/4 and still think that Tridion needs a JavaScript framework. You may also have 4/4 and decide it doesn’t. Server technologies, developer skillsets, and deadlines can all be factors in whether you decide to have a JavaScript framework render content that comes out of Tridion.

Ultimately, base your decision on whatever benefits the end user the best. When the end user is happy, everybody’s happy.

Tell me what you think