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
Front-end developers are guiltier than most of cargo cult programming. And we all know that cults are risky business. Right?
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?
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.
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.
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!
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:
- Tridion’s Content API hasn’t been released yet. Ideally, hold off on this project until the latest version of Tridion comes out
- You have different architectural considerations to make for apps.
Do What’s best for the user
Ultimately, base your decision on whatever benefits the end user the best. When the end user is happy, everybody’s happy.