-
Notifications
You must be signed in to change notification settings - Fork 97
Roadmap #4
Comments
@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. |
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. |
@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. |
Regarding rendering... I'd lean toward React and Flux. |
@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. |
@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). |
@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... |
@ericelliott I'm opening a new issue for this conversation about rendering (#13). |
@ericelliott thanks for spread your knowledge.:) |
"Full-featured build system" - Grunt, Gulp, or stick to NPM scripts? What do you think of Gulp? I could help with that. |
h02e56: RE 2 @ivanoats npm is a placeholder until we have a consensus for Cloverfield. PLEASE DO implement a gulp build in the todotasks repository. See the discussion in the Cloverfield repo. |
I'd love to help on this project, and am looking forward to your courses. As an aside, how do you feel about babeljs? |
Babel and similar projects that let us use future language features are awesome. Bonus if it exports node-compatible modules so you can |
By the way, did you see the announcement? The first course has landed! We're letting students in and adding content. We're off and running. =) |
@ericelliott I'd be happy to help but to clarify your request to implement gulp - isn't it already here? https://github.com/ericelliott/todotasks/tree/master/implementations/gulp |
Oops! I completely forgot. Do you want to look it over and raise any issues or suggestions in that repo? For now we're sticking with npm here unless / until we come to some consensus in Cloverfield. If you have anything to add to the Cloverfield taskrunner discussions, please add them. One thing I like about a gulp implementation is that we have a better potential to make all the tasks completely cross-platform. I know we have some windows compatibility issues it might help resolve. Then again, Broccoli might do the same thing for us, and it may have some advantages over Gulp... but the Broccoli vs Gulp vs Do you want to create a gulp implementation branch here that reproduces all the functionality in a way that is more Windows friendly? I might be willing to merge it if it clearly works better than our current implementation. |
@ericelliott |
@h02e56 We don't put them into root I personally prefer that you make it easy to If your modules are not mixed with vendor modules and something goes wrong with a dependency update, you can safely That said, you should still commit often. ;) |
Also, putting them in Just a few keystrokes per |
👍 |
are we using a flux pattern with react.js? |
Until there is a Relay, Flux is the way to go if you as me. Important question is if this particular boilerplate targets higher scope then just low-level-no-shared-state reusable React component or wants to handle more complex components? @ericelliott what's your idea on this? |
@ericelliott @nkbt have you guys checked out https://github.com/optimizely/nuclear-js ? its a Flux architecture built with ImmutableJS data structures. |
Sure thing. Check Redux by Dan Abramov, please
|
@vasco3 Express has officially supported gzip middleware: var compress = require('compression');
app.use(compress()); I think if we're going to include compression, that's how it should be done. It's easy to see @nkbt's perspective, too, but I don't see the harm in adding two lines to the sourcecode. I do see the harm in ignoring gzip altogether. If we don't at least mention it, people will forget about it. And that would not be good. =) |
I don't feel strongly about it, so I'd accept a PR that adds those two lines, or I'd accept a PR that adds a mention in the README and links to detailed instructions for both nginx and haproxy. |
will the compression middleware be compressing on every request? On Tue, Aug 4, 2015 at 4:08 PM Eric Elliott notifications@github.com
|
It makes more sense to me to do this at the nginx level. It's probably faster at it, too. |
@therealklanni do you mean using nginx as a proxy for Node express server? |
What about cache busting? |
@vasco3 yes. Proxy for node server. |
Yep. Everywhere I've pushed Node into production, we've had nginx & or haproxy, or both set up to reverse-proxy to our Node instances -- even for my smallest personal website deployment, I used nginx as a reverse proxy layer so I could route to different services easily. |
Is it possible to have multiple versions of the boilerplate? From most simple to advanced. |
It's not only possible, it's likely. =) |
What are we considering for CSS? |
What about code coverage with codeCov.io ? 😃 |
@vasco3 I prefer |
@nkbt does Coveralls use xml like CircleCI or json? I had that discrepancy with CircleCI + CodeCov eg. https://github.com/vasco3/Oracul/blob/master/circle.yml#L18-L19 |
Thanks, @vasco3!
https://github.com/nkbt/react-component-template/blob/master/circle.yml I use |
@nkbt how do you like isparta over babel-istanbul? |
Used isparta before babel-istanbul was there, works well, so I feel no need to swap it to something else for now. |
Hey guys, do you plan to include Redux in the project? If that so, I can help you including redux-devtools and the config for react hot reloading and reducers hot reloading. |
react-kickstart uses hot-module-replacement (babel-plugin-react-transform + react-transform-hmr) |
Yes, I plan to use Redux + HMR. |
HMR is added by #67 |
I think for react HMR you need this babel plugin: react-transform-hmr, with this config: .babelrc. |
@gacosta89 that is how it is done in #67 =) |
:( sorry. |
@gacosta89 no worries 👌 |
What about writing a test for the reducers that have been added recently? Would be a great feature to show the users a good example on how the reducer can be tested (simple functions). Might have some time for it this week. |
Sure. Please use tape and keep them simple. |
Hey guys! what do you thing of i18next for translations? I used it along with react-i18next in production. It has a very nice defaults and overrides system for keys. |
We used it in our prod app and moved to node-gettext for several reasons
|
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:
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:
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.
The text was updated successfully, but these errors were encountered: