Stoids

Well said. I enjoy being in the first camp on personal projects--it's a very fun mental exercise. It's made me a better programmer in my day-to-day, and I like the mind-expanding moments you have when a wordy math concept (monads, kleisli, applicatives, etc..) finally makes sense to you.

That being said I try to firmly plant myself in the second camp at work. As you describe, it's more about the overarching lessons we take away from functional programming. Shared mutable state is scary, referential transparency and purity are easier to reason about, push IO/mutation/scary "complex" things to the edges of your program, etc.

Bottom-up design is a good description. I try to shoot for a functional core with a flexible shell. It lends itself well to the testing story, where the core is covered by unit tests (trivial when coding with pure functions) and integration tests give me confidence in correct behavior at the edges.

To add to that, most new React/Redux projects are settling on the same technology decisions as the Angular team. TypeScript/Flow, RxJS for async/effect handling (or Sagas). React vs Angular is pretty negligible at this point. They are both component focused frameworks and that's the important paradigm and shared quality amongst all these frameworks.

Anyone who understands the architecture of one should be able to learn the other relatively quickly. I haven't personally used Angular 2/4, but it looks like a really solid and opinionated solution. Some people don't want to spend 3 days researching thunks vs sagas vs observables, so I'm glad something like Angular exists.

Sqlx and go-kit are two libraries that helped while learning Go. Sqlx helped me understand the value of Go's implicit interfaces/package level structure, while go-kit helped me better understand good project structure.

https://github.com/jmoiron/sqlx https://github.com/go-kit/kit

Seeing how functions are objects in JavaScript and all...

That's one of my favorite repos to point colleagues to who feel overwhelmed by modern front-end development. Doesn't get bogged down in tooling or implementation details and explains at a high level the problems all these libraries are trying to solve.

It's a good foundation to crudely explain the pieces. React-Redux connected components are responsible for domino 1, Redux reducers domino 2, effects libraries like sagas/thunks/observables domino 3, selectors/getters for domino 4, React and the VDOM abstracting most of the concerns domino 5 and 6 away from you.

Obviously not perfect, but feels like it helps with choice angst a bit.

Indeed, it's almost as if web application expectations and requirements have gotten significantly more complex in 10 years time.

Microservices don't reduce technical complexity. If anything they add to it. 10 years ago I didn't have to worry about container orchestration and all that comes with that. New problems present new solutions.

I definitely recognize that the transpilation era of JavaScript feels incredibly bloated. It is exacerbated by the overlap with a lot of the tooling. It's exponentially worse when you try to understand solutions to problems you don't have yet.