roc alternatives and similar libraries
Based on the "Boilerplate" category.
Alternatively, view roc alternatives based on common mentions on social networks and blogs.
9.9 0.0 roc VS react-boilerplate:fire: A highly scalable, offline-first foundation with the best developer experience and a focus on performance and best practices.
A Foundation for Scalable Cross-Platform Apps
8.1 0.0 roc VS generator-react-webpackYeoman generator for ReactJS and Webpack
2.5 1.6 roc VS phoenixA simple boilerplate that helps you make your react application with Server Side Rendering & Localization support.
Do you think we are missing an alternative of roc or a related project?
Maintained and used in production by teams within Schibsted.
npm install -g [email protected] to test the latest version.
- A way to eliminate boilerplate code within your projects
- Command Line Interface (CLI) for creating and managing your project
- Consistent configuration and runtime management
- Minimized complexity within projects by combining powerful modules together
- Best in class developer tools ready to be used instantly
All of this is provided by a flexible extension system, and several extensions are available today.
Examples of what can be done today
- Production ready React applications
- Generic server applications
- Generic web applications
More will be possible in the future and creating your own extension is easy.
Creating a React application with Roc
$ npm install -g [email protected] $ roc new react-app web-app-react $ cd react-app && roc dev
- Install Roc
- Create a project that uses React and Redux
- Start the project in development mode
To build and run in production just use:
$ roc build $ roc start
Where to go from here
A very common use-case is to make modifications to your
roc.config.js. To get a better understanding of all the possible options in the package use the
roc list-settings command or
--help for a specific command.
Not a boilerplate!
Roc uses templates to initialize new projects. Templates are very thin skeletons that depend on Roc extensions that manage the typical boilerplate. Meaning only your own code will leave a significant footprint in your project. This allows you to maintain a very clean separation of concerns as your projects evolve.
Official Roc extensions are semantically versioned and will include changelogs compiling change summaries, making upgrade paths much simpler across your projects.
Is this not Yeoman?
At first sight it might seem that Roc is similar to Yeoman but they do not address the same problem. Yeoman scaffolds a project for you based on a generator that might ask you some questions about how you want to setup your project. However after that has been performed there is no easy way to update the project if a new version of the generator is created. Yeoman will additionally add a lot of code into your project which is basically boilerplate code, that you will seldom touch. And if you manually fix some bug in the generated code you will have to manually do the same work in all other possible projects that are based on the same generator.
Roc will push a lot of the code that you would normally get from a generator away from your project and into versioned packages that can be updated and interacted with through a common interface. This means that you do not get code inside your projects that you will not care about most of the time like configuration files and common boilerplate, making it possible to update it. This leaves you with only the most important code inside your project. Additionally Roc is a composable system making it easy to add additional functionality with minimal effort after the initial project setup.
With that said you could definitely use Yeoman together with Roc if you so wish.
Roc tries to stay out of your way as much as possible and most extensions will not introduce any Roc-specific interfaces. Your project will still use your favourite libraries in the same way as you normally would.
Current Official Packages & Plugins
See the documentation.
Roc was born out of the need to create modern applications following the correct conventions and using best practices consistently.
We quickly realized that keeping boilerplate updated within each project over time was unmanageable. It seems natural to have this repeated complexity managed by separated semantically versioned packages.
Development of Roc was started before these posts where created but they still describe what Roc aims to solve in a good way:
Versioning and stability
Roc follows semantic versioning and is currently pre-release software that will soon be released as stable.
It is already used in production by teams within Schibsted as well as other companies and individuals.
We are open to, and grateful for, any contributions made by the community.
Thanks to Jongleberry for letting us use the
roc package name on npm.