This is the second article in a series of three about my experiences creating the JavaScript framework TuxedoJS. I'm using the same heading from one article to the next, so the next little bit is a summary of the series of posts and links to the other articles.

Now that my classmates and I have finished the initial release of our first framework, I thought it would be good to explain how TuxedoJS came into existence. In an effort to make it a little bit easier to handle writing about this topic I've decided that instead of writing one massive post, instead I'll break this into a series on the process that will be composed of several posts. The current plan is to write the following posts:

1. Why Make a Framework on React and Flux?
2. Identifying Pain Points in React and Flux, and Determining Initial TuxedoJS Feature List
3. Taking TuxedoJS From Feature List to Feature Complete Framework

Establishing Our Baseline Understanding

As our four person group was looking to make it easier for people to build React and Flux applications, we decided to build a simple chat application together. While doing this we would also document anything we found that was not intuitive, that we thought we could decrease the complexity of, and that we could make DRYer. After all, using a framework should make tedious or difficult things easier.

Prior to building our chat application we elected to all take the same React tutorial on Tuts+. This was an excellent decision for us, as we had people of varying skill levels with React and Flux, and this allowed us to jump start their knowledge. While taking the course everyone made notes of anything that didn't make sense or needed additional research or explanation. We came to realize that if it wasn't clear to everyone in their initial exposure, that there was potentially an opportunity there for us to make things clearer, more intuitive, or even better documented than they already were.

Making a Simple Chat App

While Dmitri and I had noticed pain points and features we thought we could improve during our previous project we wanted to take advantage of the fresh perspectives of Spencer and Pat who hadn't used React previously. In an effort to facilitate a relatively quick development cycle on the chat app, we split into two pairs, each with one experienced and one new person.

The chat application was kept relatively simple with just rooms and messages as the core models and for each them we created the views, actions, constants, and stores. Additionally we didn't want to incorporate a full-fledged back-end, as that wasn't the point of making the chat app. Instead we implemented a function to simulate the behavior of an Ajax call, which allowed us to focus on using React and Flux.

As we did more research, we refactored our chat application to use new methods and techniques, such as React's spread attributes and prop validation via propTypes.

Chat Application Observations

After we finished implementing the core aspects of the chat application we met to discuss our experiences. During this meeting we recorded our observations about the development process. These observations included:

1. Flux has a lot of associated boilerplate code that is found in actions, constants, and stores.
2. How should an applications state be managed and where should it be stored?
3. Passing properties and methods from parents to any level of child was error prone.
4. Writing forms in React could be much simpler.

Meeting With a Potential User

Shortly after this meeting, we were lucky to have another Hack Reactor graduate and React enthusiast Kia Fathi get together with us and go over our initial plans for TuxedoJS. Kia's feedback gave us the outside perspective of what another React and Flux user would want a framework to assist them with while developing. Additionally he was also able to make feature suggestions that we hadn't thought of ourselves, due to his own development experience with React.

Here are some of the things that he specifically mentioned that had an impact on how we moved forward:

1. Animations in React are not easy out of the box.
2. Input and form validation is not simple.
3. Be careful how opinionated you make your framework.

Prior to that discussion we hadn't thought of working with animations, so after Kia mentioned that they were not easy to use, we decided to look into it and it eventually became a priority for us. Also his input about not making our framework too opinionated was great feedback and led us to structure things in such a way that you can use as much or as little of TuxedoJS as you want.

Getting an Outside Perspective

As a general note, if you find yourself making anything that another user will interact with then I would highly recommend getting someone or multiple people to look over what you have early in your development cycle. An outsiders perspective can help you figure out if that feature or features you have in mind are worth the time investment or not. Another advantage is that they can show you how a user may use a feature, which might be different than you expected and this can allow you change your design early to accommodate that difference. Our project benefited massively from having people not directly involved in the project offer their thoughts, opinions, and perspectives.

Establishing Initial TuxedoJS Feature List

After these meetings we sat down and organized a list of features that we wanted to implement within TuxedoJS. Once we had that list of features we each ranked the top three things that we thought would be critical to make our framework a success. Following that ranking we discussed anything that had been voted on but that hadn't received a consensus vote. From there we organized our list of features by the priority in which they should be implemented.

Here is the initial list of features that we thought TuxedoJS needed to have for us to consider it a success:

1. A user should not have to write Flux boilerplate.
2. A user should be able to write forms with input validation.
3. A user should be able to perform client side routing.
4. A user should have a place for pre-built components and mixins.
5. A user should be able to use opinionated React components.
6. A user should be able to access the TuxedoJS documentation online.
7. A user should be able to use wrapped React animations.
8. A user should be able to convert JSX to TuxedoJS syntax instead of React.

Now that we had our initial list of features, we transitioned them into waffle.io to assist us in keeping track of the status our GitHub issues. Note that some of these features may not have made it into TuxedoJS or they are different than the original description, this is due to the fact that throughout the project we kept our feature list fluid. This allowed us to add or remove features when we noticed aspects that could be improved or simplified, as well as when we gained a greater understanding of React and Flux.

In my next post in this series I'll go into depth on how we took this initial list of features and turned it into a feature complete framework!