Dave Ceddia

First, congrats on launching the book. That's a huge achievement and you should be proud! It's also great that you've kept on it for 2 years, and published a lot of posts.

So the question is why hasn't it "worked" yet. There are TONS of new developers entering the field. The audience definitely exists, and they do hang out online.

I took Amy & Alex's 30x500 class a few years ago and it was a big factor in getting my blog + business (https://daveceddia.com) off the ground, so my ears perked up when you mentioned Amy!

I think you've got it right that she advocates for creating a tiny infoproduct first, but the emphasis is on tiny, less on education. Other tiny things are icon packs, or templates, or themes, etc. Small, quick-to-create, one-time-purchase products. Goal is to learn the entire build + market + launch cycle with low risk (vs building software for 6+ months that nobody wants). Once you get your footing with all of it, you can move up bigger/riskier products, if you want.

They also advocate that the content you create should deliver some kind of fix for a problem the reader has. Give the reader a win. Also, ideally, quickly helps the reader decide "this is for me". The easiest way to do that is to make it clear you understand their struggle.

I think this is where some of your posts could use tweaking. The "Write good commit messages" article, for instance, starts with "Take the time to write good commit messages." It's advice, yes, but is it for me…

In contrast,

https://www.simplethread.com/cant-replace-redux-with-hooks/
https://daveceddia.com/context-api-vs-redux/
https://medium.com/javascript-scene/do-react-hooks-replace-redux-210bab340672

TL;DR Context can replace some but not all of Redux. Redux can figure out which components to rerender based on what's being computed. Context doesn't, so it's basically the same as refreshing your entire component tree every time something changes. You could build it yourself, but at that point, you're just reinventing Redux.

I also like the Redux Toolkit (https://redux-toolkit.js.org/) which is an opinionated way to write Redux that cuts down the boilerplate a lot. createSlice is easily one of the best features, you can encapsulate Redux logic for each different type of content, like authentication, users, posts, etc.

To properly embrace immutable.js and not have performance issues, you need to fully embrace it and it's API and use it as the basis for all of the models in your app. We did a half-baked approach which uses immutables in the data store (so we can leverage quick prop checks) but also convert those into normal JS objects in the business domain. This makes our use of it noticeably slow.

Immer [0] is a much better alternative IMO.. you get all the benefits of immutability without having to use a radically different API than normal. And the performance is roughly the same as immutable. And using it with Redux is natural [1], removing the need to do a bunch of nested object copies

[0] https://github.com/immerjs/immer

[1] https://daveceddia.com/react-redux-immutability-guide/#easy-state-updates-with-immer

Immutability is a common part of functional programming approaches. In Javascript, it's especially common in the React+Redux community. Redux expects you will update data immutably, and React works best when you do immutable updates as well.

Here's some good overviews of why and how to do immutable updates in JS:

https://redux.js.org/faq/immutable-data

https://redux.js.org/recipes/structuring-reducers/immutable-update-patterns

https://daveceddia.com/react-redux-immutability-guide/