Skip to main content

Vue.js and server-side rendering

I’m thinking about how I want to build webapps for the next six months, and I’ve gathered some requirements:
  • Nothing too esoteric. Handing off to junior engineers is a priority.
  • Server-side first. JavaScript as a progressive enhancement.
  • Structured with React or some other component-based framework, not nested templates.
  • Mobile friendly, even mobile-first.
Ruby on Rails certainly satisfies the first two requirements, but not the third. I’m feeling very drawn to a server-side rendered JavaScript framework because it can give a smooth transition from server-rendered content to a more interactive site.

Though I’d default to React because it’s my first JS framework love, I’ve heard enough people mention Vue.js that I needed to get up to speed on it.

Vue.js bills itself as a reactive component framework, similar to React, but with a smaller footprint, greater performance, and more in-house ecosystem pieces (vue-router, vuex). A more proscriptive ecosystem has its advantages when sharing code in a team.

From my understanding, Vue makes its reactivity work by patching all of your component’s data objects with JavaScript getter/setter functions. When you render your component, Vue keeps track of what properties were accessed as part of the rendering. When it sees changes to those properties, it triggers re-renders of the dependent components.

Compared to React’s “render the world” strategy, this may result in targeted, more efficient re-rendering. React relies on custom shouldComponentUpdate implementations or tying into an external update mechanism like Redux or Relay in order to side-step re-rendering component subtrees. Whether this is a noticeable advantage in practice (both desktop and mobile) I can’t say, but probably not until your page gets pretty complex.

Vue also has a nifty vue-loader for Webpack that allows for “.vue” files, which combine template, script, and CSS style blocks into one file. I’m a huge fan of single-file components. React + JSX gets the first two, and there are several external tools for bringing in CSS, but having a blessed solution for all three has its advantages. JSX conditionals are also still awkward, and I think that many frontend engineers are still more comfortable thinking about a separate template for components. (I came to React with CoffeeScript, which made createElement-based render methods readable and even preferable to JSX, so I’m no stranger to thinking of render as just another function.)

Nevertheless, I have a few hesitations around Vue.

Conceptually, Vue actually seems more heavyweight than React. Vue components have subsections for data, computed values, input props, registrations for child components, and other methods. This is more to keep track of than React’s “props are input, state is internal, render returns a DOM description, everything else is up to you.” I worry that with Vue you always need to keep its reactive monkey-patching of data objects in your mind or you’ll slip up and write some subtle bugs.

A clear example of this was in the docs for vue-router. Under the “Reacting to Params Changes” section, there’s a caution that if the route changes but still matches the same component, it will be re-used without calls to lifecycle events. The doc recommends: “To react to params changes in the same component, you can simply watch the $route object.”

Having to explicitly “watch” for values to change seems to negate a lot of the promise of a reactive framework. Something about this seems more awkward and bug-prone than React’s catch-all componentWillReceiveProps lifecycle handler. I worry that by promising so much magic in the majority cases, Vue makes it harder to recognize and know how to deal with the edge cases.

Since it is defining custom setters for all of your component’s internal data (what Vue calls “data” React would call “state”), Vue allows direct mutation of where React would require a setState call. It may be just a stylistic difference, but part of me always balks at both mutability and having arbitrary code run when the = operator is used. In this way, React is just more to my taste.

I have found Vue’s “Hacker News” server-side rendering example very valuable, though, in particular how it works with a separately-compiled app bundle. It uses Webpack middleware to great effect to support both server- and client-side reloading when app code changes. I’m adapting it to my SSR explorations in React.

I’m aware that I’m very comfortable in React and I’ve only spent a dozen or so hours playing with Vue, but my gut feeling is that by trying to be extra-clever for the 95% of common reactive cases, Vue will make finding bugs in the other 5% of cases much harder. By being more straightforward, React trades some amount of efficiency for predictability and consistency. In the end, I think that’s a worthwhile tradeoff.


Popular posts from this blog

Dispatching multiple Redux actions

I was working in my Redux app today and was facing the question of how best to submit a “create” API call to the backend and then transition to a “confirm” page. I wired up my router to be sensitive to the Redux store, so a reducer could trigger the page change. I’m using redux-pack to handle async events, which I find quite pleasant so far (though I haven’t gotten deep into testing it, which is a bit awkward because it requires faking out some internals). One solution is to have the component that is handling the “submit” button dispatch the API call action and then use the Promise that redux-thunk provides as a return value to chain the router action. But, the Promise will always resolve when the action completes, even if the API call was not successful, leading to some awkwardness in detecting if the create actually happened without error before doing the redirect. I also have a fantasy of generically dispatching actions via POSTs on the backend (“isomorphic Redux,” if you w

Separation of Concerns Leading to Implicit Dependencies

I’ve been building a toy app to feel out server-side React, Redux, GraphQL, &c . to explore ways to build my next webapp(s). One thing this has introduced me to is react-router . react-router has good support for SSR because it lets you statically determine the set of Component classes that match a route so that you can load their data before rendering them. Its route descriptions allow nesting, which translates interestingly to your rendered UI. Here’s my routes.js file: <Route path="/" > <IndexRedirect to="/rails/rails" /> <Route path=":ownerName/:repoName" component={App}> <IndexRoute component={IssueListPage} /> <Route path=":number" component={IssuePage} /> </Route> </Route> This is used to make pages that look something like these: (When in doubt, make a GitHub viewer.) The App component renders the header with the repo name, and react-router passes it a child component,

Convention vs. Abstraction to Prevent Bugs

When I was working on Blogger, I caught the dependency injection bug and led a conversion of the frontend code to a new, DI-heavy pattern. This greatly helped our testability, as it let us move away from the service locator   anti-pattern we had been relying on. I got a bit carried away, though. One piece that I generalized out was the concept of a link to another part of the UI. All these links had to have a blogID query parameter to work, but exposing that to the page controller was a mixture of concerns, right? We could instead inject type-checked BlogUri representations of these URLs into the page controllers, and they could render them without ever having to know the right blogID to use. This code enforced that you could never write bugs about linking to the wrong page, or using the wrong blogID parameter. Useful, right? Nope. Those are two bugs that people basically will never write. If you’re on a settings page, linking to a template page, there’s no circumstance wh