I'm pretty sold on the react.js model because it makes DOM manipulation so smooth and comprehensible. But I'm wondering how it could be leveraged for a site that's largely static with big blocks of text and images that don't move. Would it just get in the way? It seems awkward to have components with KBs of text in their state.

  • 4
    You have a hammer, and are pondering whether this screw could be used as a nail. Normally, technology-related decisions ought to be made along the lines “Our requirements are X, Y, Z. Which technologies will allow us to get there at the lowest cost?”, not “I have the solution, but could you please give me a problem?”. The fact that you already have experience with React slants the decision somewhat in its favour, but what requirements would be satisfied by it? What value would it add to the customer or user? – amon Feb 14 '15 at 22:46
  • 4
    Well, that's what I'm trying to determine. Is React a hammer or a toolbox? It certainly excels at the sort of use cases that Facebook has and I haven't seen anything to indicate it would suck at other cases. It's definitely less compelling, but that doesn't mean it isn't perfectly fine. – jiggy Feb 14 '15 at 23:45
  • 1
    I actually have the same question(s). I love everything about React components but for content-driven sites with only a few lines of javascript it seems to much focussed on the HTML-JS coupling and more on states and events than clean HTML-CSS. I'd love something like React components in another templating language. – JeroenVdb Nov 18 '15 at 7:32

Know what you want to do, then choose the technology.

From that point of view, React.js seems to be overkill for a mostly static web.

From React's website:

We built React to solve one problem: building large applications with data that changes over time.

React is a hammer for a specific nail. That would indicate that it will get in the way of creating a mostly static website.


Generating static pages is an anticipated use of React, as mentioned in the documentation for React.renderToStaticMarkup

Similar to renderToString, except this doesn't create extra DOM attributes such as data-react-id, that React uses internally. This is useful if you want to use React as a simple static page generator, as stripping away the extra attributes can save lots of bytes.

Some have termed to use of react here overkill. However, when I want something dead, I have no problem with overkilling it. The fact that react can do far more than is neccessary for this use case is no argument against react.

However, problems may arise if you want to perform asynchronous code. Let's imagine the following:

function SchoolClass({classId}) {
   const students = await query("SELECT name FROM student WHERE class = ?", classId);
   return <ul>
      {_.map(students, ({name}) => <li>{name}</li>}

But this won't work, because the function returns a Promise, not a React element, and is thus not compatible with React. If you were devising a React-style static site generator framework, you would probably allow this. However, since React is focused on webapp clients, it is isn't allowed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.