Create a character voting app using React, Node.js, MongoDB and Socket.io (opens in new tab)

It's basically a single webpack config (that's heavily commented, btw!) and a set of npm run-scripts. You don't need gulp to build an application! And I would not call bower a sane way to include frontend dependencies... Not by a long shot.

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

1. seamless ES6 transpilation at runtime (no build steps needed)

2. load libraries in any package format as ES6 modules (Globals, CommonJS, AMD, ES6) from any source (local repo, Github, NPM)

3. no need for injection (you can import css and html programmatically using extensions)

It does introduce some friction of its own due to it being a relatively new project, but not enough to offset all the benefits it brings, in my experience.

Server is Nginx. Evaluating HHVM for migration is an ongoing concern, but there's some edge cases we run in to where it does wonky things. That said, within the next ~12 months, I expect we'll be on it.

MariaDB, with query results cached on Memcache. The data we deal with is massively relational, with some very large tables and result outputs, so there's no way around using a tidy RDBMS for us, and consistency is a big thing.

PHP, with a few tiny, high speed libraries for DB connection management and routing. As far as possible everything uses PHP functions that map directly on to underlying language equiv, and we make a lot of use of streaming and generators, which makes memory overhead nicely manageable. When HHVM becomes a thing for us, we'll then start pulling some of this over to Hack.

That's all set up as a bunch of RESTful APIs, which are reasonably HATEOAS in their outputs. Output format is either JSON or HTML, depending on request params.

Front end is a bunch of React bits. We're slowly converting into React, so initially we used HistoryJS to manage URL history, along with React to render stuff. Qwest for XHR handling, and a few little libraries and helper functions (of note: moment.js and numeral.js).

Everything then gets executed on the client. Current roadmap is to build something akin to React router for managing loading of assets and better history management, and to pull the entire front end into a single application. At the moment, it's better thought of as a bunch of distinct SPAs, operating over a common middleware.

Architecturally, the back end services are written MVA, with data going through our own DAL, with RBAC sitting in front of everything. Caching is handled in the DAL, so everything acts as a black box - models don't know where the data came from, adapters don't know where the model got it's data etc...

The front end is written loosely around a Flux style architecture. Data is held in a single area, as are all methods that interface with state. Those parts sit at the top, and pass data as props down to UI components, written to be dumb as to where there data comes from.

IO is mostly via single HTTP requests, but with the option to hook onto ZMQ for real time interaction.

Hope that helps! I'm currently writing some lower level thoughts on React on our blog (https://builtvisible.com/blog/) with some more advanced stuff coming shortly.

Apologies for the various TLAs. If you need anything explaining further, shout.

If you want to be able to do everything, you'll have to configure more stuff. Honestly, I don't think it's worth the extra effort to try and configure things to work with every possible workflow. Just setup what you need, and then add stuff in as you find yourself wanting / needing it.

My advice is to avoid jest. It's too slow and clunky. If you want to stub modules, there's rewire-webpack. If you're using babel and ES6 modules you'll probably want to check out babel-plugin-rewire. I think there's a few other alternatives, but I haven't had the need for any of these so far.

On to your questions...

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

Yes. The solution I have is to maintain a single webpack config maker function that has a bunch of conditionals inside, and then I just use that function from all my configs. When you set options.TEST to true, it'll set the entry point to an empty object.

That means that my tests will be configured as close as possible to my production and development. The same loader config will be used for all the environments.

> Can you run tests from the command line?

Sure. In the web-app repo, it uses karma with phantomjs.

If you want to test your code using node... It's a bit more annoying, but also doable. I've previously set it up like this: create a test.js [0] file, set it as the entry-point in the webpack config, and use webpack context to include all the tests you wanna run, and finally point mocha to the output file. If you wanna use it in "live" mode, you can run webpack and mocha both with the watch flag.

If you just wanna run a single test... You can specify a single test as your entry-point, and then point mocha to it. Again, if you want "live" mode, you can set the watch flag on both mocha and webpack.

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

Yes. They use the same loaders as the rest of your codebase.

[0] https://www.dropbox.com/s/35ebqijrp9nqyj3/Screenshot%202015-...

I've removed node_modules and bower_components from the items in: https://github.com/tastejs/todomvc/examples

I've also deleted "polymer" and "emberjs_require" since they didn't have any files in them and messes up the `wc -l`

    $ for x in *; do echo $x; wc -l `find $x/ -name '*js*' -type f | egrep -v 'test|lib|public|vendor|.bundle.js|.cache.js'`; echo; done

Obviously one can improve the filtering to get more accurate results but you get the point. To make a TODO mvc you need at least 5+ different files and totalling a lot of lines. The fact that jQuery solution (which is very nice code, not the typical spaghetti) beats the majority of them in line count is pretty ironic.

Yeah they did kind of just sneak up about a year ago it seems. I remember getting into the field two years ago I didn't hear about them. I suspect the tipping point was the full migration to front-end frameworks instead of just plain JS/jQuery.

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