{"id":21651027,"url":"https://github.com/iansinnott/react-boilerplate","last_synced_at":"2026-04-08T20:45:34.284Z","repository":{"id":29180394,"uuid":"32711231","full_name":"iansinnott/react-boilerplate","owner":"iansinnott","description":"React + Webpack + Hot Reloading :tada:","archived":false,"fork":false,"pushed_at":"2015-12-23T07:11:42.000Z","size":755,"stargazers_count":2,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-07-07T07:50:12.448Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/iansinnott.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-03-23T04:36:07.000Z","updated_at":"2016-04-22T19:49:22.000Z","dependencies_parsed_at":"2022-08-03T01:15:16.433Z","dependency_job_id":null,"html_url":"https://github.com/iansinnott/react-boilerplate","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/iansinnott/react-boilerplate","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/iansinnott%2Freact-boilerplate","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/iansinnott%2Freact-boilerplate/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/iansinnott%2Freact-boilerplate/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/iansinnott%2Freact-boilerplate/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/iansinnott","download_url":"https://codeload.github.com/iansinnott/react-boilerplate/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/iansinnott%2Freact-boilerplate/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31573788,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-08T14:31:17.711Z","status":"ssl_error","status_checked_at":"2026-04-08T14:31:17.202Z","response_time":54,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-25T07:46:27.614Z","updated_at":"2026-04-08T20:45:34.259Z","avatar_url":"https://github.com/iansinnott.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# React + Webpack + Hot Reloading\n\nA boilerplate for building web applications with Node.js\n\nPartially inspired by [React Transform Boilerplate](https://github.com/gaearon/react-transform-boilerplate)\n\n**Quick Start:**\n\n* `git clone https://github.com/iansinnott/react-boilerplate \u0026\u0026 cd react-boilerplate`\n* `npm install \u0026\u0026 npm start` to run a dev server\n* Write an awesome app with Node and React...\n* `npm build` to minify and package everything\n\nNow you're all set to deploy to your favorite hosting solution :beers:\n\n## The Stack\n\n**Client Side:**\n\n* [React][]\n* [Webpack][]\n* [Babel][]\n* [Stylus][]\n\n**Server Side:**\n\n* [Babel][] (via [Babel require hook](https://babeljs.io/docs/usage/require/))\n* [Express][]\n* [Waterline][]\n\n## Rationale and Philosophy\n\nThis project is a dynamic view of my thoughts on developing applications for the web, developer experience (DX), tooling and deployment strategies.\n\nThe three driving philosophies I try to embrace in this project are:\n\n* Don't do anything the computer can do for you\n* DX is positively correlated with UX, maintainability and stability\n* Speed is a catalyst of creation\n\nCreating a new application can be broken down broadly into three steps: setup, development and deployment. Setup only needs to happen once during the life-span of a project, but it can take a long time. Again, we want to optimize for developer experience and speed so a long setup time is a dealbreaker. Luckily setting up a project is something a computer can do so we are going to let it do that for us.\n\nThe stack used here when scaffolding out a new project is opinionated and constantly evolving, so it may not be right for you. But at the very least it will provide you with one possible option for creating advanced web applications efficiently and with minimal overhead.\n\n### A note on speed\n\nWhat I mean by speed is being able to set up fast and iterate fast. Speed is not only key because it let's us build more with less time. It's also key because it decreases the _perceived_ cost of creation. If setting up a new project takes hours, we are much less likely to even start that new project. This in my mind is a failing of modern tooling. Setting up a new project should take minutes if not seconds. Once the perceived cost of starting a new project is measured in seconds then any idea no matter how trivial warrants an exploratory build.\n\nSpeed of iteration is key because project needs change and the project itself needs to be able to change along with those needs. This means that refactoring should be easy and feedback immediate. As with setting up a project, there's a perceived cost associated with making changes to a project. If that perceived cost is too high, changes won't get made and the project will stagnate or accumulate technical debt. This leads to product failure, instability and a codebase that's no longer fun to work with. **Development should be fun, if it's not then you're doing it wrong.**\n\n## What's included\n\n### Front-end\n\nThis is meant to be a base level boilerplate for front-end development. It does not include any libraries for routing or state management. It's meant to make it very quick to start a React project with any React-oriented technology. For example, adding [React Router][] and [Flux][] to this project would be as simple as `npm install --save react-router flux`.\n\n### Back-end use\n\nThis repo also comes with a fully-functional back-end implemented in Node with Express and Waterline. You're welcome to not use the server side at all as it may well be more than you need for a project, but it's there if you want it. To see how it's implemented have a look at [api.js][api] where you'll find a fully functional REST API for `Thing` models.\n\n[api]: https://github.com/iansinnott/react-boilerplate/blob/master/server/api.js\n\n### Recommend additions\n\nOn most projects I end up pulling in both [React Router][] and one of either [Nuclear JS][] or [Redux][] as the Flux implementation.\n\n## Usage\n\n**Warning:** This section is actively changing and will look very different once this repository has been converted into an NPM module.\n\n```bash\n$ git clone https://github.com/iansinnott/react-boilerplate \u003cnew-project\u003e\n$ cd \u003cnew-project\u003e\n$ rm -rf .git\n$ npm install\n$ npm start\n```\n\nBe sure to replace `\u003cnew-project\u003e` with the name of the project you want to create.\n\nThat's it. Now you're ready to start building.\n\n## Waterline Mini-docs\n\nTo quickly and easily get up and running with Waterline here is some useful info:\n\n* Types\n  * `string`\n  * `text`\n  * `integer`\n  * `float`\n  * `date`\n  * `time`\n  * `datetime`\n  * `boolean`\n  * `binary`\n  * `array`\n  * `json`\n* [Validations][]\n* For quick docs see [readme][]\n\n[Validations]: https://github.com/balderdashy/anchor/blob/master/lib/match/rules.js\n[readme]: https://github.com/balderdashy/waterline\n\n## Reasons to use React + Webpack\n\n#### Rapid Development\n\nReact is declarative, which makes it a pleasure to use for anyone who is used to the manual way of triggering DOM updates. Using React with Webpack allows you to take rapid development to the next step by supporting live code injection for _all_ filetypes, not just CSS.\n\nFor example, as you change your JSX you can see it live-update in the browser the second  you save it. There will be no page reload, the HTML will simply update.\n\nThis of course goes for CSS or any of it's preprocessors. You can even apply this to files like markdown and see your site update as you edit the text. For example, every time I save this file I see the live preview in the browser update automatically without reloading the page. Magic!\n\n## Dependencies\n\nIn `package.json` only server dependencies will be found under `dependencies`. All client-side dependencies will be found under `devDependencies`.\n\nThe reasoning here is that in prod we will have a compiled and minified JS file\nalong with a similar CSS file. Since these are precompiled we don't actually\nneed any of the dev deps in that environment.\n\nHowever it should be noted that 'devDependencies' is misleading, since those\ndeps are actually _build_ dependencies. I may rethink this strategy later, but\nfor now only server side deps make the cut for `dependencies`.\n\n## Yet to come\n\n- [x] ~~Production tooling~~\n- [x] Multiple database support\n- [ ] Run production DB in dev\n- [ ] Testing boilerplate\n- [ ] Type Safety\n- [ ] Git hooks for eslint + type safety\n- [ ] General deployment improvements\n- [ ] Use chunk hashes in filenames and add long-term caching headers\n\n## TODO\n\n### Type Safety\n\n\u003e Don't let a human do anything a computer can do for you.\n\nStrong typing is great, but mandatory type annotations are not. If the computer can analyze your code and warn you of type digressions at build time then why not use such a feature? Even better, warn me at _save_ time. Type safety through type _inference_ is a top priority of this project. \n\nThe goals I believe any JS type system should aspire to are as follows:\n\n* **Inferred.** If I can infer the type signature of a function just by reading its source then the computer should be able to do the same and warn my of type digressions without me explicitly annotating code.\n* **Fully optional.** JS is decidedly _not_ strongly typed and there may well be cases where the use of typing is undesirable or incompatible with some existing JS code. Even the inference feature should be optional. Moreover, we should be able to quickly add type annotations after the fact so that we don't worry about types during rapid prototyping but can quickly add them when we're ready to ship production code.\n\nThe author of Clojure's [core.typed][] optional typing library provides an [excellent and concise overview of the rational behind optional typing][rational].\n\n[rational]: https://github.com/clojure/core.typed/wiki\n\nThere are currently a several contenders for making this a reality:\n\n**[Flow][]**\n\nFlow is great for type-safety in JavaScript and writing self-documenting code. It integrates tightly with React and respects `propTypes`. The main downside of using it now is that `let` and `const` are not supported. That's a dealbreaker, but apparently [they are working on it](https://github.com/facebook/flow/issues/560). Keep an eye on that issue to see when full support drops.\n\n**[TypeScript][]**\n\nIt seems TS already support ES6 and typing is fully optional. I'm not yet sure of the advantages / disadvantages of TS vs Flow. Need to do more research. At first glance flow wins largely because it was such nice interplay with React and was built by the same people. Also TS is a Microsoft thing, which is an immediate turn off. But let's not let that bias us too much.\n\n**[Closure Compiler][]**\n\nAside from industrial strength optimization and minification the Google Closure Compiler also does type checking and warns about common JS pitfalls. This would likely be a build-time, production-level optimization and would not exclude the use of Flow or TS.\n\n[Closure Compiler]: https://developers.google.com/closure/compiler/\n\n**[ClojureScript][]**\n\nWriting apps in ClojureScript is the ultimate goal as it currently presents the strongest front for writing stable, maintainable and readable code while not sacrificing DX. Many of the great ideas that have come into the JS ecosystem recently are all very standard and known in the Clojure world. CS can hit many compile targets including mobile. Clojure and CS treat immutability as Node.js treats asynchronisity: It's the desirable default. The CS community embraces immediacy and feedback with hot-loading and being able to immediately evaluate code.\n\nClojure itself is dynamically typed but it provides the optional [core.typed][] library for bringing the strengths of static typing to Clojure and thereby CS as well.\n\n### Create NPM Module\n\nAlthough I created this project long before seeing a [similar project by Henrik Joreteg][hjs], I really like a lot of what he's doing over there. One of the main features that I'd like to incorporate is the use of a boilerplate as an installable Node module.\n\nClone a git repo and completely removing the repo part once it's downloaded is simple but it's also not using git the way it was meant to be used. Furthermore it removes the possibility of updating the underlying project base in a way. Therefore I intend to borrow from [hjs-webpack][hjs] and implement this project as module. Those changes are coming.\n\n### Deployment Improvements\n\nThis is fairly vague because there is not currently one surefire way to deploy every type of application you might want. Maybe you want to run on AWS. Maybe it's a static site and you're happy hosting on Surge.sh. The problem is there isn't just one way, so it's hard to define a `deploy` command that's both effective and flexible.\n\nThe solution I'm leaning towards is to create a Dockerfile that can be used to build an app that can run anywhere Docker is running.\n\n## Troubleshooting\n\n#### Live reload (aka Hot Module Replacement) doesn't work.\n\nOne of the gotchas of the hot react loader seems to be that it will not hot work with files in the root of the client directory. If you edit `client/index.js` or `client/Router.js` it will not do a live reload, you will have to to it manually.\n\n#### Babel + Transforms\n\nTurns out that using transforrms for HMR is great until you start using `babel-core/register`. This is because the same HMR code gets inejected into server code and breaks everything. To avoid this we make use of `BABEL_ENV` to trick babel into running in production mode even when NODE_ENV is still set to dev\n\n[React]: http://facebook.github.io/react/\n[Webpack]: http://webpack.github.io/\n[Babel]: https://babeljs.io/\n[Stylus]: https://learnboost.github.io/stylus/\n[Express]: http://expressjs.com/\n[Waterline]: https://github.com/balderdashy/waterline\n[Flux]: https://facebook.github.io/flux/docs/overview.html\n[React Router]: https://github.com/rackt/react-router\n[hjs]: https://github.com/henrikjoreteg/hjs-webpack\n[ClojureScript]: https://github.com/clojure/clojurescript\n[core.typed]: https://github.com/clojure/core.typed\n[TypeScript]: https://github.com/Microsoft/TypeScript \n[Flow]: http://flowtype.org/\n[Nuclear JS]: https://github.com/optimizely/nuclear-js\n[Redux]: https://github.com/rackt/redux\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fiansinnott%2Freact-boilerplate","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fiansinnott%2Freact-boilerplate","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fiansinnott%2Freact-boilerplate/lists"}