Show HN: Essential React, a minimal skeleton for building React apps using ES6
github.com
github.com
:thumbsup: to this sentiment. Whenever I see a "skeleton" starter project that includes tooling that could easily be added at a later date, I usually close the tab.
I think people forget that skeleton projects need to serve an educational purpose to newcomers. Each additional framework/tool that you throw into the mix compromises the skeleton's ability to do that.
Trying to bolt tooling onto an existing project is daunting, especially when you're not sure how it works yet. When I started with a fresh skeleton project, two source files, the whole shebang set-up, it was super easy. Just add my extra source files in the dir, and it's picked up.
I love it when a skeleton project includes the entire toolset. I can easily remove stuff I don't need, even when I don't know how it works. But adding JS tooling myself? What a disaster.
Now, I look at my first project, the one I had to add gulp and everything to myself, and it's a complete mess. A lot of time and effort would have been saved if I had just started with a good directory structure right away.
My point is that you shouldn't have to learn a long list of tools in order to learn the underlying framework the project is trying to introduce.
I can easily remove stuff I don't need, even when I don't know how it works. But adding JS tooling myself? What a disaster.
Really? I've walked in on quite a few existing gulp/grunt/insert-latest-hotness setups and found them incredibly hard to follow (let alone unwind) without a solid understanding of these tools.
- https://github.com/RickWong/react-isomorphic-starterkit
The starterkit's focused on the build tools and overall ease-of-use. You can get started in less than 5 minutes. The included example showcases how the server & client work together elegantly to produce the page. The goal of the starterkit is to enhance productivity so there's one single cli command to watch and rebuild both the server with auto-reloads, and client with hot (instant) code updates. Everything happens automatically on-save.
Check it out, it just works. I'm looking for feedback.
It also gives you inline styles, webpack, etc.
For example, I'd avoid having a (somewhat) verbose plugin dependency to shim `console.log` - it's very easy to avoid hitting that incompatibility in most development. Similar argument against including es5-shim - it's super easy to add that if/when you need it, but it's orthogonal to building a react application.
Also, I'd be wary of incorporating Radium - it will narrow the audience because it brings another set of dev requirements., and it's really not Essential to building a react app, it's just a nice-to-have if it fits your dev style.
Will definitely be interested in trying this out next time I'm playing with React, though - thanks for sharing it!
I've been meaning to look into Flux as well, seems like an interesting design pattern for large applications.
https://github.com/sass/libsass/wiki/The-LibSass-Compatibili...
https://github.com/sass/libsass/milestones/3.2
http://sass-compatibility.github.io/
It's at the point where I can use node-sass and Ruby Sass interchangeably for our (very large) Sass code base at my company, but we also don't rely very heavily on the newest features. Worth a try, anyway.
If node-sass doesn't work for you though, there's also a webpack loader for Ruby Sass: https://github.com/ddelbondio/ruby-sass-loader
The idea is that you gain extra maintainability points by co-locating your styling with your logic and DOM, a pervasive design patter in React in general. If I want to style a particular view, I no longer have to concern myself with which stylesheets contain styling for that view. I can simply go to the React Component where that view is owned, and see the styling for it right there.
See also:
In my company we use Staticr [1], a way to express generated asset bundles (Browserify, SASS or anything else) using JS.
You basically declare the endpoints; e.g.:
var endpoints = {
"/js/app.js": function() {
return browserify("app.js", {...})
.transform(babelify())
.bundle();
},
"/css/app.css": // ... similar with node-sass
};
In server.js or whatever, you simply include a check for the environment and mount the endpoints like so: if (process.env.NODE_ENV === 'development') {
var serve = require('staticr/serve');
app.use(serve(endpoints));
}
Now whenever someone requests /js/app.js, it will be automatically built on the fly using Browserify. To speed things up (a lot!) we have a small module that keeps Browserify's cache in memory, which I can show you if you're interested.Then, in production, you simply include the following as part of your deployment script:
staticr endpoints.js public/
It will take each endpoint, generate the output, and write the file to public/. This assumes you have a docroot, or your Node.js app has a static middleware, at public/.Of course, Webpack gives you a more extensive toolset, but Staticr is a lot simpler.
I'm curious, do you need es5-shim when you have Babel (ie., "babel/polyfill") which uses core.js, which I believe installs most of what is needed? Actually Babel only requires "core.js/shim"; for ES5 you might need to require "core-js/es5". But it would probably be better to use one polyfill library instead of several.
Also, don't see why it hurts to start large projects with a skeleton, and having that skeleton removed eventually once the ground work has been laid out. Any constraints, albeit redundant at times, can help with initial stages.
If this is too onerous, you can still just write in vanilla JS.
That is not to say that these tools don't have value, and if a developer wishes to include them, it should be a fairly straightforward addition.