Publicity Roadmap

[efatsi]

Just met with @mackermedia and @btrav around the topic of publicity and marketing for Microcosm. Wanted to post notes and discuss next steps with the larger community.

Meeting Notes:

Microcosm is rad, we want to spread the good word. Before we push it out through various channels, it would be good if the documentation, reference material, guides, tutorials, etc. were in a good place we all feel comfortable with. Nate and others have done a stellar job laying a solid foundation of documentation and guides, let's get it to the next level. We can up with a high level plan:

High Level Plan:

• Collaborate on a target outline for the code.viget.com/microcosm site and github readme.
  • @leobauza has already put a lot of thought into this and made moves in other github issues.
  • @bf21789 is working on a cartoon intro to Microcosm, with designs on covering some of Microcosm highlights with a real user-friendly medium. Thinking homepage material.
  • specific tutorials would be great
  • defining audience (or audiences) and ensuring messaging is on point across the site
  • etc.
• Execute towards flushing out the site/readme towards the goals laid out in bullet point 1. RPM time can ideally be snagged when we make it to this point.
• Broadcast. Once we feel the reference materials are strong, @btrav takes lead on outreach.

Next Steps:

@greypants @nhunzaker @leobauza @mackermedia @efatsi @h0tl33t @dce @ipbrennan90 @benjtinsley @albaer @solomonhawk @ltk
If you have any thoughts around improvements that you'd like to see in the site/readme, lay em out here. We can hopefully suss out a cohesive vision to work towards. Everyone has varying degrees of experience so getting thoughts across the spectrum would be great.

[leobauza]

Some thoughts on stuff:

Collaborate on a target outline for the code.viget.com/microcosm site and github readme.
[I think] we want to move towards JSDoc for documentation, so maybe we can keep that in mind for this.

@bf21789 is working on a cartoon intro to Microcosm, with designs on covering some of Microcosm highlights with a real user-friendly medium. Thinking homepage material.

I've been trying to create diagrams of the flow of data through Microcosm, some help with that would be great. Stuff like this https://vuejs.org/images/lifecycle.png

specific tutorials would be great

I think this is the most effective thing redux did to teach people about it: https://egghead.io/lessons/javascript-redux-the-single-immutable-state-tree

The key takeaways being introducing 1 concept at a time, starting with redux without any react. We need that initial tutorial where we only talk about the core API. Also an example. I have a simple counter I will put on a PR and maybe we can tweak that since ya'll have more microcosm experience.

defining audience (or audiences) and ensuring messaging is on point across the site

One audience I wanted to focus on was bringing in contributors. Adding betters docs, contrib guidelines, and easy formatting is geared towards that. Another thing I wanted to investigate was creating an OpenCollective project. That would potentially draw contributors, spread the word, and pay for stickers or something.

[greypants]

We 100% need to focus on marketing "Why Microcosm is better than Redux". Feels like 99% of shops and product teams are using Redux. Why would a technical manager at a product company have his team swap out a core architectural portion of their app, or why would a team lead evaluating options on a new project pick Mirocosm over the industry standard?

There are plenty of reasons why! There is no reason to be diplomatic here. If we think we have something better (and I think we do), we gotta tell people straight up. Not in a cocky way, but in a straightforward, convincing, here are the facts way.

So to re-iterate, we absolutely need to include a "Microcosm vs. Redux" segment in the intro docs or the homepage. OR simultaneously launch a blog post with that title, and link to it in the docs. Or both.

The React (and beyond) community would benefit so much if they new this was as legit as it is! @nhunzaker is a wizard. Spread that magic around! 🦄

[nhunzaker]

Very cool. I have tons of thoughts, but they're taking some time to distill down. In the mean time:

@leobauza I really like the way Ember structures their tutorial:

https://guides.emberjs.com/v2.12.0/tutorial/ember-cli/

@greypants Let's chip away at talking through the key advantages. I'm also curious to get @mackermedia or @h0tl33t's take on Redux vs Microcosm having worked with both. I also want to start working through talking more specifically about the advantages. I've started that with this PR:

#314

Beyond that, I need to write a high level blog post about Microcosm. I'll make that my next priority.

[greypants]

The complaint I hear most about Redux is around how massive/crazy/out-of-control reducers can get over time. I dunno if this is Redux's fault, or just something easy for devs to fall into... but it'd be cool to talk about how well Microcosm architecturally scales and can help you avoid ending up with too much app logic jammed into one place.

But yeah, I definitely thing @mackermedia and @h0tl33t should speak to this. All my knowledge of Redux is just from hearing about other people's experiences.

[tommymarshall]

Totally agree with all of this, especially with the focus on being more pointed in doing comparisons.

I can put together some pain points I'm hitting on day 1 of working with a React/Apollo app where I want to view the state of an action, but unintentionally hitting weird race conditions (have to check loading states on componentWillReceiveProps... I'll collect my thoughts more on this as I get more into it.

Also I believe a video-taped presentation would go even further than a write up. I know you have a ton on your plate already @nhunzaker, but you're a great speaker, so if you find it so if you find it easier to talk than write I'd second that! :)

[tommymarshall]

We're using this to abstract some complexity away: https://github.com/erikras/ducks-modular-redux

[nhunzaker]

@tommymarshall Thanks for sharing! That's super interesting.

The issues are also pretty interesting:

How can I cancel an API call that is already made?
https://github.com/erikras/ducks-modular-redux/issues/55

Maybe we should hit stuff like this harder. In Microcosm, it's a little different, but you could just do:

function uploadFile (file) {
  return action => {
    let request = ajax.upload(file).then(action.resolve, action.reject)

    action.onCancel(request.abort)
  }
})

let upload = repo.push(uploadFile, new File(['meeow'], 'catz.js'))

upload.cancel()

[tommymarshall]

There's a bunch of talk around efficiencies in rendering components when global state changes; which is why Redux uses Containers. I don't understand exact why this is more efficient, but it gets brought up a bunch where I am at now. To me, Presenters make this an even better alternative with a fork of state so it doesn't concern itself with other parts of an app.

[nhunzaker]

@tommymarshall If it's like presenters, it's more efficient because you can more granularly specify what you want, like:

getModel () {
  return {
    users: (state) => state.users
  }
}

That (and the mapPropsToState version in Redux) means that a global state change would only cause a reflow on the container if the users value is different.

Forks need to be advertised more. With Microcosm, you could totally add domains/effects for a specific part of an application, even lazy load the whole section.