3 ms·

"still feel strongly that if your app is large and serious you are going to need that stuff." My approach usually is, start minimalistic and if you need additi

"still feel strongly that if your app is large and serious you are going to need that stuff." My approach usually is, start minimalistic and if you need additional stuff, you can usually add it later. That is why I like React. For example if I need router, I can choose from many implementation, but there are also cases when I don't need it all.

BigJono 10y ago
This is a very good way to go. In my experience, adding a new tool can take a day or two of refactoring in a medium sized project; but removing one can take a week. Removing a bunch because you completely over-engineered the solution and can't maintain it can often take a month, or even get dangerously close to "scrap it and rewrite" territory, which is a complete death sentence for a small company. Unless I'm working with people I know well, I'll often elect to start off a fresh project with just React and maybe Redux, and build from there. Even if I know full well that we'll need some stuff like thunk and react-router, my preference is to leave them out and let the team run into the problems they solve before we introduce them. IMO even if just one team member gains a new understanding about why their tools exist and why they're using them, it's worth a bit of refactoring.
- mnutt 10y ago
  I can see where you're coming from, but I tend to bucket apps I write into either general use case, mostly business-logic apps, or highly specific services. (say, a network proxy or compositor or something) The general use case apps all tend to share a good deal of requirements (multiple pages, authentication, forms, etc) and while it would certainly be possible to pick and choose each component, it's nice to have a shared set of functionality that is well-tested together and that stays the same between multiple projects and teams. I think adopting something like ember is pretty much the opposite of "can't maintain it" since while I understand how it works internally, I don't actually have to maintain it myself. In my experience I've seen more instances where we ended up ripping out a homegrown library to replace with a community-supported solution than the other way around.
  - BigJono 10y ago
    Oh, absolutely. I wasn't trying to comment on the difference between the monolithic and modular approaches of Ember and React respectively. I think the monolithic approach actually solves the problem I'm describing to some extent, because developers in those ecosystems are forced into using these tools and patterns, which gives people a vested interest in making sure they're actually good before going into the next release and seeing widespread adoption. redux-thunk is a great example of what I'm talking about. The design pattern prescribed by it is confusing in subtle ways. They're basically overloading the terminology of "action creators" to mean two wildly different things. The main benefit is solid (it provides a way for controllers/business logic functions to access the data store through dependency injection rather than closures, making them easier to test) but the implementation isn't well thought out, the terminology surrounding it is confusing, and it provides rookie developers more ways to shoot themselves in the foot (see getState abuse). If any of this craziness was proposed as a core part of Angular or Ember there would be enough sane devs speaking out against it and it would be changed. But since in a modular system in React you are free to choose parts as you please, everyone that knows what they're doing just elects not to use stuff like this, until it builds up enough of a cargo cult following that it becomes standard and starts infiltrating your work place, and suddenly you're outnumbered 20 to 1 by people that have just "always done it that way".
    - acemarke 10y ago
      Can you clarify what you mean by "the implementation isn't well thought out"? It's a 10-line function that basically just checks to see if the argument is a function, and if so, executes it. Thunks _are_ "action creators", in the sense that they are given `dispatch` and allowed to dispatch things. The word "thunk" is a long-standing CS term, per [0]. I addressed the `getState` question in my blog post "Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [1]. As a summary, yes, thunks (and sagas) give devs complete freedom to do what they want, and more "convention-driven" middleware can be useful, but they're also a level of abstraction that's not necessary, and sometimes you _need_ to execute arbitrary logic that doesn't fit a specific pattern like "REQUEST_START/SUCCESS/FAILED". [0] https://en.wikipedia.org/wiki/Thunk https://en.wikipedia.org/wiki/Thunk [1] http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho...

BigJono 10y ago

This is a very good way to go. In my experience, adding a new tool can take a day or two of refactoring in a medium sized project; but removing one can take a week. Removing a bunch because you completely over-engineered the solution and can't maintain it can often take a month, or even get dangerously close to "scrap it and rewrite" territory, which is a complete death sentence for a small company. Unless I'm working with people I know well, I'll often elect to start off a fresh project with just React and maybe Redux, and build from there. Even if I know full well that we'll need some stuff like thunk and react-router, my preference is to leave them out and let the team run into the problems they solve before we introduce them. IMO even if just one team member gains a new understanding about why their tools exist and why they're using them, it's worth a bit of refactoring.

mnutt 10y ago
I can see where you're coming from, but I tend to bucket apps I write into either general use case, mostly business-logic apps, or highly specific services. (say, a network proxy or compositor or something) The general use case apps all tend to share a good deal of requirements (multiple pages, authentication, forms, etc) and while it would certainly be possible to pick and choose each component, it's nice to have a shared set of functionality that is well-tested together and that stays the same between multiple projects and teams. I think adopting something like ember is pretty much the opposite of "can't maintain it" since while I understand how it works internally, I don't actually have to maintain it myself. In my experience I've seen more instances where we ended up ripping out a homegrown library to replace with a community-supported solution than the other way around.
- BigJono 10y ago
  Oh, absolutely. I wasn't trying to comment on the difference between the monolithic and modular approaches of Ember and React respectively. I think the monolithic approach actually solves the problem I'm describing to some extent, because developers in those ecosystems are forced into using these tools and patterns, which gives people a vested interest in making sure they're actually good before going into the next release and seeing widespread adoption. redux-thunk is a great example of what I'm talking about. The design pattern prescribed by it is confusing in subtle ways. They're basically overloading the terminology of "action creators" to mean two wildly different things. The main benefit is solid (it provides a way for controllers/business logic functions to access the data store through dependency injection rather than closures, making them easier to test) but the implementation isn't well thought out, the terminology surrounding it is confusing, and it provides rookie developers more ways to shoot themselves in the foot (see getState abuse). If any of this craziness was proposed as a core part of Angular or Ember there would be enough sane devs speaking out against it and it would be changed. But since in a modular system in React you are free to choose parts as you please, everyone that knows what they're doing just elects not to use stuff like this, until it builds up enough of a cargo cult following that it becomes standard and starts infiltrating your work place, and suddenly you're outnumbered 20 to 1 by people that have just "always done it that way".
  - acemarke 10y ago
    Can you clarify what you mean by "the implementation isn't well thought out"? It's a 10-line function that basically just checks to see if the argument is a function, and if so, executes it. Thunks _are_ "action creators", in the sense that they are given `dispatch` and allowed to dispatch things. The word "thunk" is a long-standing CS term, per [0]. I addressed the `getState` question in my blog post "Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [1]. As a summary, yes, thunks (and sagas) give devs complete freedom to do what they want, and more "convention-driven" middleware can be useful, but they're also a level of abstraction that's not necessary, and sometimes you _need_ to execute arbitrary logic that doesn't fit a specific pattern like "REQUEST_START/SUCCESS/FAILED". [0] https://en.wikipedia.org/wiki/Thunk https://en.wikipedia.org/wiki/Thunk [1] http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho...