Roadmap

[ericelliott]

Universal React Boilerplate

This is a universal JavaScript application boilerplate using Express & React.

Learn JavaScript with Eric Elliott

The Universal React Boilerplate was written for the "Learn JavaScript with Eric Elliott" courses. A series of courses to teach people how to build great JavaScript apps for production. Don't just learn JavaScript. Learn how to build amazing things.

Universal JavaScript

Universal (aka "isomorphic") means that it's designed to run a lot of the same code on both the client and the server. Typically that includes a lot of rendering and domain logic.

There are many advantages to building apps this way, but the primary advantages are:

• Cross-functional teams. Since everything is written in JavaScript, it's easier to build teams who know how to work on both the client and server sides of the app.
• Write once, run everywhere. With the exception of a few library substitutions and browser polyfills, the code is shared, which means you have to write about half the code you'd write working on a non-universal app.
• More productive developers. Since the app is more consistent across the stack, there's no context switching when you need to maintain application behavior on both sides of the stack. Write the behavior once, and you're done. Context switching slows developers down significantly.

Roadmap

I'm planning to put a lot of love into this and make it an essential resource for anybody interested in building production Node and Universal JavaScript applications. It's already very useful as-is, but we've been rewriting a lot of these things over and over again for every app, or searching through the haystack that is npm and spending too much time on tech selection instead of knowing what the best, most well-tested solutions are and running with them.

This boilerplate will eventually demonstrate a very simple production ready application, including:

• Unit tests with tape & faucet
• State management and time-travel debugging with Redux
• Route and render with react-router + redux-router
• Client bundling with Webpack.
• Client unit tests also need to be validated cross-browser. smokestack with Sauce Labs
• Functional testing with selenium-sauce on Sauce Labs
• Logging with bunyan-request-logger
• Configuration management with qconf
• Error handling with express-error-handler
• User sign-in flows with Passport
• OTP auth with Authy (passwords are obsolete)
• Auth tokens with json web tokens
• User authorization for feature access
• i18n
• Data input validation
• Robust feature toggling with multivariate testing support
• HTML5 form validation (h5v2?)
• CORS
• XSS prevention with Lusca
• Security audit built-into automatic build validation

In other words, everything you'd want to reuse in most production-ready applications -- all done for you using years worth of tried and true best practices.

Help wanted

Let me know in the comments if you'd like to help with any of these items.

Courses

Students will get a series of short videos, lots of interactive lessons explaining concepts in-depth, the ability to help and learn from each other, and a lot more.

[zebulonj]

@ericelliott I'd like to help. I'm currently in the midst of a similar exercise as I work to break a legacy monolith down into micro-services... and as my first attempt at an isomorphic application I'm making up a lot as I go (so I don't pretend to have a lot of clear answers to offer). At the moment, the bit I'm most interested in is the isomorphic templates and rendering.

[ericelliott]

I have purposely not baked in a template system, but I'm considering changing that, using Minimongo, Track, and Blaze to do rendering on both the server and the client. It's a bit of a moving target, though, because the Meteor project doesn't seem to have any interest in maintaining an npm version of those libs.

Alternatively, we could show an example using React and Flux. Maybe those example implementations could be in a different repo which we link to from this one?

I'd love to hear your thoughts.

[capaj]

@ericelliott do you really think browserify is the way to go get trully isomorphic JS? To me it seems JSPM is more up to the task, because it allows for any kind of modules, not just CommonJS. Much more easy to develop with, because there is no need for build steps.

[zebulonj]

Regarding rendering... I'd lean toward React and Flux.

[alexbasalyga]

@capaj I don't think the goal here is to use a technology that supports every kind of module, but simply to use the best technology available (in terms of simplicity of use and how well its maintained) to allow the use of npm as both the server and client package manager. JSPM very well may be the best tool for the job if the job is packaging CommonJS and AMD modules beside each other for the browser, but I think the job at hand is smaller in scope.

[ericelliott]

@capaj We're interested in sharing the same code with the same source files authored in a single module format. JSPM may be a great solution for using ES6 modules in the browser, but I think it's a better fit to use Node style modules for code that is targeted at both Node and the browser, today. (That may change in the future, but it hasn't changed yet).

[ericelliott]

@zebulonj That combo definitely has the mindshare right now. 👍

Should we be looking at trying to use JSX? Mixing markup into my JavaScript rubs me the wrong way.

I thought it was a great idea when PHP hit the scene. We all know how that played out... It was a bad idea then, and I'm not sure that anything has changed.

Also, if you're mixing markup into the JS, it seems like that puts an artificial limit targeting the output only to the DOM. IMO, one of the most attractive things about react is that it can target more than just the DOM...

[zebulonj]

@ericelliott I'm opening a new issue for this conversation about rendering (#13).

[h02e56]

@ericelliott thanks for spread your knowledge.:)
I've learned just seeing initial code. I would like to help someway.
About project, i am more "frontend" but i like going deeper on server side. I have played a little with express, although nowadays i like use tiny modules instead.
About put the scripts on place i use to put them on the same node_modules folder, and now i feel weird having 2 node_modules folder. for sure is is just a matter of habit.:)
I could give a hand with i18n , or routing with page or client bundling(think is solved)