Stuart Sierra - Components Just Enough Structure

Can't agree with your implication that 'real JS stuff' won't get done and 'JS people' won't get on board due to its 'focus on OOP'. I've yet to see a large JS app written in a 'functional style'. Most large client-side apps I've come across are written in Backbone, Angular, Ember etc. which are all frameworks/libraries that embrace OOP. You shouldn't mistake JavaScript's 'prototypal' nature for it being a non-OOP language. JavaScript and OOP are a very good fit. > The people who will appreciate the trappings of OOP are more than likely the typical classically trained programmers, who will write 300 lines of Spider on the frontend of their Python hobby project, and not touch it again. If you're really dismissing __all of OOP__ to that extent I feel like you are seriously misunderstanding OOP and I highly recommend you read/watch at least: - POODR by Sandi Metz [1] - Explores OOP, SOLID principles, testing, more. The best book on OOP I've ever read. Ignore the fact the code examples are in Ruby (by that I mean, they're easy to understand). - Refactoring by Martin Fowler [2] - The definitive refactoring book... which goes hand in hand with OOP. - Boundaries (Talk) by Gary Bernhardt [4]. He talks about the 'functional core, imperative shell' pattern of software architecture that acknowledges the fact that some form of OOP/procedural/imperative programming is unavoidable. It's a great talk. Outright dismissal of OOP really has no place in modern programming. Even if you get into f

> but once you need to go for something bigger, with big teams, the thing start to melt down. The people in the Clojure community have already started exploring this issue. Component [1] [2], Jig [3], and others are trying to add just enough OOP back for the reasons you mentioned. [1] [LINK] [2] [VIDEO] [3] [LINK]

There are a huge number of people who don't enjoy programming in lisps and don't buy the tradeoff that homoiconicity is somehow worth sacrificing all syntax for. You can take 'good parts' from functional programming without going 'all in'. Many of us don't agree that the 'all in' is actually better. (See Gary Bernhardt's 'Boundaries' talk [0] for an amazing explanation of what I mean by taking the good parts of FP). React isn't really about functional programming, it's very object-oriented. And where the parent comment refers to 'composition', they mean composition of components/view code, not pure functions as you may have interpreted it as. Personally my dive into the Clojure community has been very frustrating, I find very few answers on how to actually compose large apps, and the answers I do find basically point back to OOP (but implemented in a syntax-less, ad-hoc manner [1]). If I've got this wrong, please tell me, I'm dying for better answers. [0] [LINK] [1] Stuart Sierra - Components Just Enough Structure - [VIDEO]

This talk might be of interest Stuart Sierra - Components Just Enough Structure [VIDEO] - it is a tiny clojure framework but the ideas should be thought provoking, although granted with OO aligned type system not completely adaptable. In this example Customer could possibly just be a data-bucket/map/hashtable/Dictionary, Im not entirely sure how I'd handle reporting though as the example has put me back in OO mode, but a customer report (which knows how to organize data about a customer) shouldnt be part of customer entity (used loosely) in my opinion.