2 ms·

I've been doing heavy javascript interfacing since the end of the 2000' (it was still a rare skill back then, and made me good freelance money), and I totally u

I've been doing heavy javascript interfacing since the end of the 2000' (it was still a rare skill back then, and made me good freelance money), and I totally understand how you feel. I experienced the same thing when learning angular, flux and redux. It all screamed "overengineering" to me. But then I realized why it was that way, and why it had to be : you now have teams of like 50 js developers working on the same codebase. They have to have very strict and complex architecture, because their frontend codebase is just as big, if not more, than their backend codebase. Those tools still lack alternatives for small to middle sized teams and products, IMO. React by itself is super cool to be quickly productive in that scope, but state management systems are not. For that reason, I made my own flux library, meant to keep things conceptually simple. The flux pattern by itself (data always propagating in a single direction) is not complicated, its implementations are. I would recommend that small teams working on small products take time to get the flux idea, then make their own implementation, it's worth it. EDIT : to be more specific, here is a simple thing to do to make your own implementation: 1. build something (let's call it a store) with a `subscribe(func)` method allowing to be notified when data changed 2. add a public api to that store (`like store.addArticle(article_data)`) 3. in the `componentDidMount()` method of your root component, subscribe to store with a function that calls `setState()` on your component, then pass data as props to child components 4. when triggering an action, like clicking a button, call a method from the public api of your store 5. you now have a state manager ensuring data always flows in the same direction, and you can make your store implementation as simple or as complex as you want

Silhouette 9y ago
The example you edited in makes your point very well. Essentially, you're describing a simple MVC design, with a couple of React-specific details for rendering your view. In desktop world, we were using this sort of software architecture decades ago. It's only a combination of modular design, separating state from presentation, and an observer, and these are all well-established principles that have stood the test of time. Countless developers have written something like this at the start of countless new projects, and they probably did it in five minutes without a second thought. The difference In modern JS world is that some people talk as if you need 197 dependencies, a whole build process and a team of 5 just to maintain it. You really don't, and the frameworks and build systems that push in that direction make my head hurt.
seanwilson 9y ago
How could the 27 file commit example comment not be a clear case of overengineering though? I frequently add similar functionality to Vue and Angular 1 projects in a way close to how you describe and it's simple. Even if the change involved adding a modal library (you should not be wasting time implementing that yourself) to your project first, it shouldn't be more than about 10 lines. Personally, I'd find it very hard to be motivated to work on a project like that. It sucks all the fun out of coding when things that should be simple aren't simple, it's draining for the whole team and it creates a lot of friction in adding new features.
- oelmekki 9y ago
  Yep, I feel the same way, but then again I usually work with small startups. I had an experience with a bigger team, recently (about 20 devs) and went all the way "what you do is too complicated". I was quickly humbled when I realized that my "simple" designs were quickly growing out of control and breaking a lot after a few months so many devs were adding code in it, most of them knowing only a very small part of the app. I guess I could say no product should need 20 devs, but it feels like denial. So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :)
  - nojvek 9y ago
    Jesus. Angular is over engineered and not a great tool for your first task. Use something tiny like preact and you'll probably enjoy the simplicity of it with hyperscript so it's all in js.
  - seanwilson 9y ago
    > So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :) Hmm, if each component is properly isolated though and you're not all working on the same area I still don't see why a simple modal could take so many code changes. Can you give an example? I've worked on Java codebases before where there's hundreds of abstract interfaces, factories, design patterns galore etc. where you can't work out where the actual work is done because every file is just delegating to another file which I hate with a passion. JavaScript gets a lot of stick around here but I find it fun and productive to work with to be honest, as long as the same silly level of abstraction is avoided.

Silhouette 9y ago

The example you edited in makes your point very well. Essentially, you're describing a simple MVC design, with a couple of React-specific details for rendering your view. In desktop world, we were using this sort of software architecture decades ago. It's only a combination of modular design, separating state from presentation, and an observer, and these are all well-established principles that have stood the test of time. Countless developers have written something like this at the start of countless new projects, and they probably did it in five minutes without a second thought. The difference In modern JS world is that some people talk as if you need 197 dependencies, a whole build process and a team of 5 just to maintain it. You really don't, and the frameworks and build systems that push in that direction make my head hurt.

seanwilson 9y ago

How could the 27 file commit example comment not be a clear case of overengineering though? I frequently add similar functionality to Vue and Angular 1 projects in a way close to how you describe and it's simple. Even if the change involved adding a modal library (you should not be wasting time implementing that yourself) to your project first, it shouldn't be more than about 10 lines. Personally, I'd find it very hard to be motivated to work on a project like that. It sucks all the fun out of coding when things that should be simple aren't simple, it's draining for the whole team and it creates a lot of friction in adding new features.

oelmekki 9y ago
Yep, I feel the same way, but then again I usually work with small startups. I had an experience with a bigger team, recently (about 20 devs) and went all the way "what you do is too complicated". I was quickly humbled when I realized that my "simple" designs were quickly growing out of control and breaking a lot after a few months so many devs were adding code in it, most of them knowing only a very small part of the app. I guess I could say no product should need 20 devs, but it feels like denial. So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :)
- nojvek 9y ago
  Jesus. Angular is over engineered and not a great tool for your first task. Use something tiny like preact and you'll probably enjoy the simplicity of it with hyperscript so it's all in js.
- seanwilson 9y ago
  > So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :) Hmm, if each component is properly isolated though and you're not all working on the same area I still don't see why a simple modal could take so many code changes. Can you give an example? I've worked on Java codebases before where there's hundreds of abstract interfaces, factories, design patterns galore etc. where you can't work out where the actual work is done because every file is just delegating to another file which I hate with a passion. JavaScript gets a lot of stick around here but I find it fun and productive to work with to be honest, as long as the same silly level of abstraction is avoided.