Create a character voting app using React, Node.js, MongoDB and Socket.io

[petewailes]

Christ on a bike...

I spend a reasonable amount of time developing and maintaining a reasonable sized js based front end to an application, which uses React heavily (40k lines). Looking at this, I can't help but think that isomorphic JS apps make life far more miserable than separate back and front end applications.

To get a decent server running on a linux distro - Nginx, Mariadb, PHP/Python/etc. An apt-get and your updates are handled nicely for you. Dependency management via Gulp is better than nothing, but jeez it still sucks so bad.

Building a nice, RESTful API on a more sensible back end infrastructure is far less complex, has a vastly smaller toolchain (just a small library for routing and db connection handling would do), plus you get the joys of things like Schemas and ACID from a proper RDBMS (because seriously, Mongo? We really still think that's a good idea?).

That's before we even get on to Step 4. ES6 Crash Course. Or, here's things to know about a language that you can't use on the client browser, because it's not actually a thing there, so you can't use all that you'll learn here when you write JS.

It's insane that people think you need to do all this just to get a live updating counter. What's wrong with a tidy back end with ZeroMQ for your pubsub style socket handling to allow real-time event based change publication, and a separate front end?

It feels like you have to do a hell of a lot of work to get JS + your favourite V8-based server to do anything, and none of it easily.

[verroq]

There is just a lot of friction. Want es6, get ready to put gulp in your work flow. Want to sanely include frontend dependencies? Time to add throw in bower. Want those js/css to be injected into the page? Throw in wiredep or bite the bullet and chuck in the wirepack.conf.js. Don't want that and want to use a skeleton? Install yeoman and run the isomorphic js generatior that gives you a 1k+ line project and you haven't even made your app yet.

[testguy34]

> It's insane that people think you need to do all this just to get a live updating counter.

Dismissing this guy's tutorial because he didn't clone Facebook is kind of short sided. Everything is about trade offs. You don't need to make your React app isomorphic if you don't mind a slower initial load and lack of SEO. You don't need to use Mongo, you can pass data from your RDBMS directly to your components as props when you render server side or have them call your REST API using an isomorphic request library. You don't need to use ES6 if you use something like webpack and babel.

[k__]

I think it isn't needed for 99% of all web-apps.

But if you have heavy competition and need a snappier first load experience, it is an option you have.

[hello_there]

Can you elaborate on you stack and toolchain? I'm curious about what's simple and works well with React.

[cabirum]

Great tutorial showing how many components work together in node/mongo/react.

It also absolutely blows my mind. This just feels wrong. 17 separate packages, some providing really basic stuff like serving favicons and parsing POST requests that must be a part of bigger framework. Each package is of different quality, testing strategy, and depends on a different developer who's completely free to abandon his project tomorrow or introduce some backwards-incompatible change. This trend as a whole looks unreliable, like a wobbly house of cards near a working fan.

[Gigablah]

> Each package is of different quality, testing strategy, and depends on a different developer who's completely free to abandon his project tomorrow or introduce some backwards-incompatible change

Welcome to OSS! Really though, there's things like forking, community involvement and SemVer.

The project configuration reflects the developer's decision not to use webserver like nginx, otherwise things like serve-favicon and express.static would be unnecessary.

[TheAceOfHearts]

I challenge your assumption that gulp + browserify is more straightforward than webpack. Your setup is not representative of a real application.

I setup a project scaffold [0] with a configuration that supports development, production, and testing environments. It has a heavily commented webpack config.

No tests? No asset cache busting by updating name references? Come on, those are basic requirements for a web project.

On top of that, webpack lets your dependencies be resolved as part of your code, instead of relying on certain files being in certain folders: e.g. your css and images.

[0] http://github.com/cesarandreu/web-app

[renke1]

Thanks for your project template. It looks really polished.

What is your experience in regard to running tests with Webpack?

* Can you test individual modules that use arbitrary loaders specified in your Webpack config?

* Can you run tests from the command line?

* Can you write your tests in ES6/7 (or anything else supported by Webpack's loaders)?

I was looking into combining jest with Webpack but every solution so far would only compile your module directly with Babel and therefore skipping the power of Webpack.

[verroq]

Why is modern webdev this hard?

Even the todo-mvcs are all ~500 to 1000+ lines.

[uptown]

It's the future.

http://blog.circleci.com/its-the-future/

[wslh]

I think because we are living in the prehistoric era of modern webdev. Programming in assembler is much easier!

[ryanSrich]

JavaScript.

https://www.shopify.com/technology/15646068-rebuilding-the-s...

[woah]

What are you talking about? I've never seen a 2k lines todomvc.

[renke1]

"I have yet to find any React boilerplate project with an easy to understand webpack.config.js file."

I actually think that a simple Webpack configuration for a React project is pretty easy to understand (thanks to Babel). Here is one that I use in one of my projects [1]. Adding Less support is like one additional entry.

[1]: https://github.com/renke/perpetually/blob/master/webpack.con...

[nothrabannosir]

How long did it take you to write this?

[roneesh]

Impressive and awesome. This is perfect to catch up on using build tools. I focus on core programming concepts in my own work, and at work most of that stuff is automated to just a few commands, so I appreciate the gulp.js part of your tutorial most. Thanks for the great work.

[TheAceOfHearts]

If you want to check out an alternative for building applications, go look up Webpack.

I strongly believe you can build web applications without having to pull in Gulp or Grunt. And to back up my claim I setup a project [0] that shows how to do it using webpack + npm run-scripts.

I'd argue it solves a large set of problems while maintaining a reasonable level of complexity.

[0] https://github.com/cesarandreu/web-app

[bmelton]

I can't claim to be a Gulp expert, but it's always shocking to me how tools like Gulp and Grunt become so pervasive without strong tutorials.

I ignored Grunt for years, always implementing my own hackneyed systems in Python, until I eventually discovered this tutorial[1], which at least got me a good introductory "this is how you use this thing that everybody else already knows how to use, dummy" lesson.

[1] - http://24ways.org/2013/grunt-is-not-weird-and-hard/

[alexggordon]

I've been curious about React for awhile now, but every time I step in to play around with it, I get really turned off by the syntax.

This is a react render function mentioned in the tutorial (gist with all code here[0]):

  render() {
   let delta = this.props.delta ? (
     <strong className={this.props.delta > 0 ? 'text-success' : 'text-danger'}>
       {this.props.delta}
     </strong>
   ) : null;
 
   return (
     <div className='card'>
       {delta}
       {this.props.title}
     </div>
   );
  }

This is approximately that same function written in ERB and Rails syntax.

  <div class='card'>
    <%= content_tag_for(:strong, :class => @delta > 0 ? 'text-success' : 'text-danger' ) do %>
      <%= @this_props_title %>
    <% end %>
  </div>

On just a pure typing basis, the ERB would take half as long to type as the react version. Even writing that same function in backbone templates (which I use frequently) would take less text, and be easier to read. Maybe I haven't given react and other js frameworks enough of a chance, but to a person that hasn't learned them, that render function above is a huge deterrent.

[0] https://gist.github.com/alexggordon/820020aab934bf192b81

[lojack]

Your ERB function is actually wrong though....

      <div class='card'>
        <% if this_props_delta? %>
          <%= content_tag_for(:strong, :class => @delta > 0 ? 'text-success' : 'text-danger' ) do %>
            <%= @this_props_delta %>
          <% end %>
        <% end %>
        <%= @this_props_title %>
      </div>

I'm not a rails developer, so I'm only marginally certain of the correctness of this, and less certain if there's a more verbose way to write it. Likewise, I've only played around with React, so its possible that the React version can be made less verbose.

One could just as easily argue:

    <div className='card'>
      {() => { this.props.delta ? (
        <strong className={this.props.delta > 0 ? 'text-success' : 'text-danger'}>
            {this.props.delta}
          </strong>
      ) : null }() }
      {this.props.title}
    </div>

Is the same amount of typing. Honestly though, I feel as though this whole argument is a bit of an apples-to-oranges type of argument.

[justinsaccount]

I'm not an expert on either of those, but I don't think that your ERB version does the same thing. If delta is not set, the react version renders something like

    <div class="card">
        title
    </div>

If it is set, it renders something like

    <div class="card">
        <strong class="text-success"> delta </strong>
        title
    </div>

Your version appears to render

    <div class="card">
        <strong class="text-success">
            title
        </strong>
    </div>

[raylan_givens]

Really great tutorial, I looked at your other tutorials and you have some really great content. Thanks for sharing.

[VeejayRampay]

Standing ovation to you. That is a lot of work and a precious resource. Kudos.

[wildpeaks]

Swig seems superfluous in that stack given it already has React, one could just use React to prerender the pages.

[ssclafani]

He provides his rational towards the bottom of the post:

> But do we really need a separate template for this? Why not just render everything inside the App component? Yes, you could do it, as long as you are okay with invalid HTML markup and not being able to include inline script tags like Google Analytics directly in the App component. But having said that, invalid markup is probably not relevant to SEO anymore and there are workarounds to include inline script tags in React components. So it's up to you, but for the purposes of this tutorial we will be using a Swig template.

[wildpeaks]

Personally, the only things I had to do to prerender full pages with React were:

- prepend '<!DOCTYPE html>' to the resulting HTML

- attribute "prefix" in head tag "<title>" wasn't outputted, so until it's fixed in the library, I just use a data attribute "data-replace-prefix" and removed the extra "data-replace-" from the resulting HTML

-------

Also, he could include inline scripts (like Google Analytics) this way:

  return <script dangerouslySetInnerHTML={{__html: "THE_JS_CODE"}}></script>;

[henryw]

Looks pretty cool! I like the graphics. I think Meteor.js does this too, but with only one resume buzzword.

[joshuajenkinsyo]

It's great that you're sharing a very practical tutorial, but did it occur to you that women (and generally reasonable people) might not be particularly motivated to learn how to build a woman judging app? Seems like your example project could be less alienating.

[ngoel36]

Really awesome job

[CmonDev]

Is it really a "full-stack" "app"? Sounds more like a set of scripts:

> "...using React, Node.js, MongoDB and Socket.IO..."

[sehr]

Not a single one of those things are 'scripts' in the colloquial sense of the word