On ylems mission

ylem-mission.md

High Level Goals

1. To generate high quality qualified sales leads.
2. To be effective developers because we know and can fix big chunks of the stack.
3. To give our developers a fun outlet for creativity.

Focus on "simpler and more scalable state management"

I think it's in Bitovi's best interests to start out pursuing the following mission and identity:

• What Ylem should be the best at?

  Simple and Scalable State management

  • easier to understand
  • Object Oriented but still reactive

• How can we make it the best or why is it the best?

  It will be the best because it will be BOTH easy to get started, making simple components for small apps and demos, but also offer a robust end-to-end solution for making "large" scalable apps.

• Who are we building it for?

  React developers

  • Developers who are already experienced with React and are looking for a third party state management solution to help keep the app organized and maintainable
  • Bitovi developers who are on projects that must or want to use React

• Who are we targeting with marketing?

  React developers with influence

  • Decision makers with tech knowledge (Senior Devs, Tech leads, ...etc)
  • React "thought leaders"

What this means

It basically means that we should assume a level of competency with React in the users we target.
We should seek to solve the problems we experience with our clients rather than teaching new developers "how to JavaScript" with our library. We should assume our users want adherence to React standards and Guidlines, and create APIs that align with that assumption.

Rationale

1. A real value

• React isn't the problem. It's the most popular front-end library out there right now, we don't need to fix React, we need to focus on working with React to provide the stuff that react doesn't: organizing the data into domain concepts, managing business logic, fetching data and reacting to live updates
• By focusing on the problems "more advanced" developers are having, we have a better shot of winning one or more of the "thought leaders" in the React community. One endorsement of the Ylem project to their thousands of followers will reap more reward than focusing on individually winning over all the beginner developers
• By targeting Senior Devs and Tech leads who may, for example, be asked to evaluate our stack before they hire us, or maybe asked to investigate alternatives as they hit scale problems with other solutions we stand a better chance of achieving the number #1 goal

2. An easier, more fruitful demographic target

• New devs will be very susceptible to the "it's made by Facebook/Google/Netflix" factor, they will most likely shy away from a library they've never heard of
• new devs won't promote the lib as much because they generally fear being shot down and told they are wrong and "you should just use redux/mobx/angular/" anyway
• A developer who has taken some lumps, sees the pain points of developing apps with other libraries and is looking for alternatives hold a better chance of actually trying out and promoting an underdog like ylem

3. We don't have to sacrifice ease of use

• We may not be marketing to the new devs, but we can still make compelling tutorials and demos that introduce the concepts that developers can get their minds around before progressing on to the bigger stuff, we may in fact win over "newer" developers and meetup attendees anyway because they, for example, find the concept of a Product class that produces Product instances easier than learning about Reducers, Epics, or Unstated Containers.

4. Benefit beyond popularity

• If we have a solution that is useful to us, Bitovi, and the apps we build for our clients, then even if it doesn't become popular we still get a lot of value out of it

Personal note

Personally, I think this aligns with our company values more anyway.

We don't just want to give someone a library to use, we want to teach people that there is a better way to build apps.

We often deal with large overly-engineered apps that are hard to follow and maintain. We make them better by leading by example, coding and showing our clients that "large" apps need to be organized to scale. They need to be easy to test and they need to be easy to conceptualize.

Our library should reflect that.

I don't want to make a library that helps a new dev learn JavaScript, I want to help teams make ambitious apps, and that requires a little more than and easy start.