

Show HN: Essential React, a minimal skeleton for building React apps using ES6 - gmaster1440
https://github.com/pheuter/essential-react

======
rgarcia
_As few tools as possible (no task runners, etc...)_

: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.

~~~
nothrabannosir
I had to learn how to use gulp and npm and browserify and and and
ohmygodthelistgoeson, and I tell you I feel exactly the opposite.

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.

~~~
rgarcia
_I had to learn how to use gulp and npm and browserify and and and
ohmygodthelistgoeson,..._

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.

------
Rygu
Last week I pushed my own isomorphic React starterkit to GitHub, where it was
trending:

\- [https://github.com/RickWong/react-isomorphic-
starterkit](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.

------
nwienert
If you're looking for a nice default React stack, I'd recommend the
[http://reapp.io](http://reapp.io) CLI (npm install -g reapp). I'm biased
because I made it, but it comes from many months and attempts at building apps
with React.

It also gives you inline styles, webpack, etc.

~~~
gmaster1440
Looks pretty cool :) A bit different from the minimal direction I focus on
with my skeleton, but seems like a nice tool to accomplish a lot nonetheless.

------
CognitiveLens
Looks good, and I like that you're aiming to make it lightweight. However, I'd
take another "do we need this" pass to eliminate dependency bulk.

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!

~~~
gmaster1440
Thanks for the great feedback! You make really good points, and I will surely
take additional passes to optimize. It's just the beginning, looking forward
to further tuning it :)

------
mradmin
Here's an even more minimal seed project i've been working on (with sass):
[https://github.com/badsyntax/react-seed](https://github.com/badsyntax/react-
seed)

~~~
gmaster1440
Looks nice! I believe the Webpack sass-loader depends on node-sass instead of
the ruby version. Have you found any issues because of that? I remember taking
a look at node-sass a couple years ago, and it wasn't up to par with Ruby Sass
in terms of functionality and caveats.

I've been meaning to look into Flux as well, seems like an interesting design
pattern for large applications.

~~~
xtian
node-sass (which uses libsass) is now on par with the Ruby version as far as I
know.

~~~
peterjmag
It's not quite there yet, but they've made a lot of progress in the last few
months:

[https://github.com/sass/libsass/wiki/The-LibSass-
Compatibili...](https://github.com/sass/libsass/wiki/The-LibSass-
Compatibility-Plan)

[https://github.com/sass/libsass/milestones/3.2](https://github.com/sass/libsass/milestones/3.2)

[http://sass-compatibility.github.io/](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](https://github.com/ddelbondio/ruby-sass-loader)

------
_mayo
What benefit does "logic driven inline styles" over using style sheets buy
you? That seems unmaintainable for a large project.

~~~
gmaster1440
Good question. Intuitively, having inline styles over style sheets goes
against common patterns involving maintainability of large code bases,
ditching mixins, variables, and other helpful functions that preprocessors
like Sass provide you with.

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:

\- [https://speakerdeck.com/vjeux/react-css-in-
js](https://speakerdeck.com/vjeux/react-css-in-js)

\-
[https://github.com/FormidableLabs/radium](https://github.com/FormidableLabs/radium)

~~~
edvinbesic
I know this project uses browserify but by switching to webpack you could
achieve the same thing without inline styles by exporting a style bundle. Take
a look at the sass-loader[1] package which will let you configure webpack so
that you can simply do a require('./style.scss'); and have the style included
into either the main or a separate bundle.

[1] [https://github.com/jtangelder/sass-
loader](https://github.com/jtangelder/sass-loader)

~~~
gmaster1440
Sweet! I keep hearing good things about Webpack, including good integration
with React Hot Loader[1]. Will create a ticket in repo to assess switching
over to Webpack :)

[1] [https://github.com/gaearon/react-hot-
loader](https://github.com/gaearon/react-hot-loader)

------
lobster_johnson
Curious how you run apps when developing. Do you run "npm run-script watchify"
and "npm run-script server" in two separate terminals? I always found watchify
to be an odd way to go about building assets.

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.

[1] [https://github.com/bjoerge/staticr](https://github.com/bjoerge/staticr)

------
desireco42
My first reaction was that I don't need this, but upon looking through it, it
saves a lot of time. However simple individual steps are, having them already
done helps a lot. Thanks.

~~~
gmaster1440
Glad you found it helpful!

------
amelius
Am I the only one who thinks it is sad that one needs a "skeleton" to write a
minimal app?

~~~
gmaster1440
I don't see "needing" it as much as it being a guide to help people who are
interested in investigating a new library or framework to become familiar with
some of the more popular conventions and techniques.

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.

------
cnp
Very curious what zsh plugin you're using to render out that `la` screenshot
tree?

~~~
albemuth
Also digging the color scheme, any one know what it is?

~~~
debaserab2
Looks like SMYCK to me, which I love:
[http://color.smyck.org/](http://color.smyck.org/)

------
maelito
This yeoman generator is also good start :
[https://github.com/newtriks/generator-react-
webpack](https://github.com/newtriks/generator-react-webpack)

~~~
gmaster1440
Looks good. One of the principles of my skeleton is to keep tooling down to a
minimum. I am taking a look at Webpack and Hot Loader currently, but without
the overhead of Yeoman, Grunt, Karma, etc...

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.

------
b2themax
I'm glad this thread found its way here today. I was just Google-ing for
something like this, just a few days ago. Thanks HN community :) Time for me
to choose who to fork...

