Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAQ: what differs kyt from Roc? #154

Closed
fatso83 opened this issue Sep 14, 2016 · 5 comments
Closed

FAQ: what differs kyt from Roc? #154

fatso83 opened this issue Sep 14, 2016 · 5 comments

Comments

@fatso83
Copy link

fatso83 commented Sep 14, 2016

Congrats on shipping this. I was just wondering what differs this project from Roc, which I found a few months ago. The article on open seems to want to solve the same set of problems as the creators of Roc sets out in this article. Maybe the latter is trying to solve a bigger problem. Not quite sure, but maybe trying to unite forces could be an idea given the similarities.

@delambo
Copy link
Member

delambo commented Sep 14, 2016

Thanks for pointing this out! Sorry, we were not aware of Roc. I think the biggest difference is that Roc has a nice website ✨ ! But there is one important difference that I gathered from skimming the site, which is that kyt aims to not depend on React. In fact, kyt is designed to give users the freedom to include whatever frameworks they need in their source directory. Angular2, Backbone, or JQuery with server rendered Mustache templates should all work well next to kyt. As an example, I created a WIP Angular2 starter-kyt. If this is also a feature of Roc, please let me know.

We'll add it to the FAQ, possibly in the form of a "Similar Projects" section. Thanks!

@fatso83
Copy link
Author

fatso83 commented Sep 14, 2016

Actually, that's one of the main features of Roc as well :-)

Not be opinionated in the sense that it can only do one thing, e.g React, Mocha, but should work with whatever is the best tool for the job through a modular and extendable architecture.
(source)

It is basically a way of sharing "library composition patterns ready for immediate consumption" (from this background article).

I guess it's just another case of multiple discovery, in the aftermath of the javascript fatigue discussions. And since the developers making Roc are backed by a big newspaper company with a lot of interactive publications I guess it's no wonder that they faced struggles that were similar to yours 😄 The more the merrier!

P.S. I am not in the dev team or associated. I just saw it presented on a Meeup a few months ago and thought this seemed very similar.

@delambo
Copy link
Member

delambo commented Sep 14, 2016

Ah, thanks for the clarification. I should have looked into it more. The site really makes it look like React is a dependency.

@dlmr
Copy link

dlmr commented Sep 14, 2016

Hello, one of the developers behind Roc here! 👋

As @fatso83 mentions seems like we have very similar goals and collaboration would most likley be beneficial for us both. It is quite obvious that our projects are born out of the same pain points, especially since we are both tackling the problem space from a publisher perspective! 😄

First of all, the site (getroc.org) does not accurately reflect the current state of Roc in a good way and we will update it in the near future. React has been one of the focus for us but Roc is at its core totally agnostic for any frameworks or libraries.

One example of this is that Roc is not coupled with Webpack for example and other alternatives can easily be added like Browserify and Rollup. The core of Roc is really more like a framework for creating solutions like kyt, create-react-app and similar. It defines a way to create something that we call extensions that can define custom commands, settings, something we call actions/hooks (similar to modifyWebpackConfig that exists in kyt) and much more. These extensions are also composable meaning that one extension can for instance add basic Webpack configuration (https://github.com/rocjs/roc-package-webpack/) and then another can add what is need for React projects (https://github.com/rocjs/roc-package-web-app-react/). This also means that the testing boilerplate is provided in something we call a plugin meaning that it is an easily replaceable part making it possible to provide several different solutions like Ava and Jest. We currently have test plugin that support Mocha and Karma https://github.com/rocjs/roc-plugin-test-mocha-karma-webpack/ that adds a test command.

This means that a Roc project does not have a direct dependency on Roc itself but rather on a package that can be a composition of several other extensions that together brings exactly what the developer need for the current project and with the option to add plugins that brings additional features in a plug-and-play manner. An example of this is that the modifications that are done to the Webpack configuration in the Angular2 starter-kyt is boilerplate in kyt where this could be a package in Roc that can be reused for several projects and updated without the user needing to do manual changes. Roc supports several way to make this dynamic behaviour easy for the developer, featuring a dynamic command line interface and documentation generation for almost all aspects of the setup to mention something.

We are about to land the next version of Roc that will bring several improvments to it along with new documentation. A good place to start can be seen here https://github.com/rocjs/roc/blob/master/docs/Introduction.md

I hope that we can help each other to make the experience when creating JavaScript projects as good as possible.

@ccpricenytimes
Copy link
Contributor

Awesome to hear more about Roc.

Going to close this in favor of #160

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants