4 ms·

Show HN: Essential React, a minimal skeleton for building React apps using ES6

73 points by gmaster1440 12y ago

_mayo 12y ago
What benefit does "logic driven inline styles" over using style sheets buy you? That seems unmaintainable for a large project.
- gmaster1440 12y ago
  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 12y ago
    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 12y ago
      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
maelito 12y ago
This yeoman generator is also good start : https://github.com/newtriks/generator-react-webpack https://github.com/newtriks/generator-react-webpack
- gmaster1440 12y ago
  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.
amelius 12y ago
Am I the only one who thinks it is sad that one needs a "skeleton" to write a minimal app?
- gmaster1440 12y ago
  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.
- woah 12y ago
  I don't really understand your point here. You already have the huge "skeleton" of the browser, the OS, etc etc. And if you look at many other UI development technologies such as the Microsoft or Apple stacks, you'll see that they have a similar amount of "stuff" built in, you just don't have any choice in the matter. On the web we have more of a choice of what "skeleton" to use, at the cost of... having to make a choice. If this is too onerous, you can still just write in vanilla JS.
- b2themax 12y ago
  Its not necessarially that I "need" a skeleton. If I needed to, I know I could do it all manually. I have manually configured a Node.js app before. But wouldn't it be a lot more prudent use of my time to start programming instead of doing project set-up, when I'm learning a new programming paradigm? Why do you think we fork repos?
- Casao 12y ago
  I find a blank project slightly nerve wracking, so something like this is great.
mradmin 12y ago
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 12y ago
  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 12y ago
    node-sass (which uses libsass) is now on par with the Ruby version as far as I know.
    - peterjmag 12y ago
      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-Compatibility-Plan https://github.com/sass/libsass/wiki/The-LibSass-Compatibili... 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
rgarcia 12y ago
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.
- gmaster1440 12y ago
  Amen :)
- nothrabannosir 12y ago
  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.
  - jdnier 12y ago
    "ohmygodthelistgoeson"!
  - rgarcia 12y ago
    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.
cnp 12y ago
Very curious what zsh plugin you're using to render out that `la` screenshot tree?
- gmaster1440 12y ago
  It's exa[1] :) [1] https://github.com/ogham/exa https://github.com/ogham/exa
- albemuth 12y ago
  Also digging the color scheme, any one know what it is?
  - debaserab2 12y ago
    Looks like SMYCK to me, which I love: http://color.smyck.org/ http://color.smyck.org/
nwienert 12y ago
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 12y ago
  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.
Rygu 12y ago
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.
b2themax 12y ago
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...
CognitiveLens 12y ago
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 12y ago
  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 :)
desireco42 12y ago
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 12y ago
  Glad you found it helpful!
lobster_johnson 12y ago
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

73 points by gmaster1440 12y ago

_mayo 12y ago

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

gmaster1440 12y ago
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 12y ago
  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 12y ago
    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

maelito 12y ago

This yeoman generator is also good start : https://github.com/newtriks/generator-react-webpack https://github.com/newtriks/generator-react-webpack

gmaster1440 12y ago
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.

amelius 12y ago

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

gmaster1440 12y ago
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.
woah 12y ago
I don't really understand your point here. You already have the huge "skeleton" of the browser, the OS, etc etc. And if you look at many other UI development technologies such as the Microsoft or Apple stacks, you'll see that they have a similar amount of "stuff" built in, you just don't have any choice in the matter. On the web we have more of a choice of what "skeleton" to use, at the cost of... having to make a choice. If this is too onerous, you can still just write in vanilla JS.
b2themax 12y ago
Its not necessarially that I "need" a skeleton. If I needed to, I know I could do it all manually. I have manually configured a Node.js app before. But wouldn't it be a lot more prudent use of my time to start programming instead of doing project set-up, when I'm learning a new programming paradigm? Why do you think we fork repos?
Casao 12y ago
I find a blank project slightly nerve wracking, so something like this is great.

mradmin 12y ago

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 12y ago
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 12y ago
  node-sass (which uses libsass) is now on par with the Ruby version as far as I know.
  - peterjmag 12y ago
    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-Compatibility-Plan https://github.com/sass/libsass/wiki/The-LibSass-Compatibili... 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

rgarcia 12y ago

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.

gmaster1440 12y ago
Amen :)
nothrabannosir 12y ago
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.
- jdnier 12y ago
  "ohmygodthelistgoeson"!
- rgarcia 12y ago
  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.

cnp 12y ago

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

gmaster1440 12y ago
It's exa[1] :) [1] https://github.com/ogham/exa https://github.com/ogham/exa
albemuth 12y ago
Also digging the color scheme, any one know what it is?
- debaserab2 12y ago
  Looks like SMYCK to me, which I love: http://color.smyck.org/ http://color.smyck.org/

nwienert 12y ago

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 12y ago
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.

Rygu 12y ago

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.

b2themax 12y ago

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

CognitiveLens 12y ago

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 12y ago
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 :)

desireco42 12y ago

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 12y ago
Glad you found it helpful!

lobster_johnson 12y ago

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