Contentful vs React

• Clean, modern interface (not clunky and outdated, like WordPress)
• High degree of flexibility (I can structure data any way my clients need)
• Enables headless frontend (i.e. I can build any frontend I want without having to change my CMS)

Read full review

• React is designed around the notion of generated html as opposed to templated html. This provides more flexibility in building elements on a page, and allows developers to create html that is programmatically configured based on runtime considerations.
• React uses JSX, which is HTML templating integrated into javascript code. This simplifies the generation of complex structures, especially those that vary based on runtime and interactive data.
• React is more efficient because it generates a virtual DOM rather than directly building in in the actual DOM. By building 'offline' in this manner, the DOM generation is faster. After building, it can be installed in one operation.
• React only builds those portions of the display that have changed, making display updates more efficient.

Read full review

• The new Contentful "branches" feature looked promising (it appears to mirror a git-like repository) but it requires the CLI, which isn't necessarily practical for teams that aren't current CLI users. It would be nice if the management of this feature were available via the UI (without that it causes more confusion than anything).
• The Contentful data modeling method makes for a bit of an awkward SDK developer experience in some strongly typed languages like Java. Most things that you might need can be accomplished, but it feels like the experience could be smoother.
• It would be nice if there were a way to migrate data between spaces (e.g. from your staging space to production).

Read full review

• React could get very frustrating unless you start thinking in React. React enforces a top down hierarchy of data flow and offers no way for the data to communicate backwards. This is a big shift in mindset coming from Angular 1.x. This constraint is really a big factor that determines how to organize your code and how you might want to write your own Components.
• Because of the self imposed top down hierarchy, you end up having a heavy parents with dumb children. Because parents would need to the bulk of the work, they usually manage the state, while passing callbacks to the child components. If not properly designed, this could lead to the callback hell, where you could have callbacks passing through like multiple children.
• As with any library, you will have to iterate through multiple designs to come up with a ways to avoid "heavy parent components" in React. One obvious solution is using some open source tools like Redux, but we opted for a variation of it to suit our needs.

Read full review

• Positive: faster changes and new associates can easily navigate without prior training/knowledge of CMS to make content updates
• Negative: Our website manager/provider can keep certain abilities (like changing specific images) so they can charge a fee for making the change

Read full review

• React allows a modular design, which is fabulous for A/B testing (showing a different module to each user). Some of these experiments had an improvement as big as to pay for the whole team that coded it. So far we know the ROI has been positive, but I can't provide a number.

Read full review