7 ms·

I was hoping this would be a guide on managing architectures, common use case traps for handling things like scalability and state. Instead this is just a long-

I was hoping this would be a guide on managing architectures, common use case traps for handling things like scalability and state. Instead this is just a long-winded way of recommending an opinionated front-end tech stack with resources to learn those stacks. Was not exactly what I was hoping for.

paradite 9y ago
This guide is more for beginners who just joined or want to join big tech companies. But I can see that your suggestions would make a great "power up as beginners" guide.
- foota 9y ago
  I think parent is asking for a guide for structuring large front end projects for intermediate-experienced front end developers.
  - paradite 9y ago
    Oh, I see. That would also be great.
BigJono 9y ago
Yep, this is just rehashing the same stuff you can find on any one of 1000 other blog posts, articles or pieces of documentation. The current literature on front-end development in React is woefully short on real world case studies. It seems like everyone is building 30k loc throwaways with a 40 library boilerplate and slathering the internet with masturbatory praise for all the tooling and architectural patterns involved. If you try and Google for any actual details about said libraries, it's buried under mounds of beginner tutorials and faux praise. For example, we just made the decision to use ImmutableJS in a project. Everyone else on the team seems to be happy enough just reading a few blog posts about how great it is and then throwing it into the mix. I have a bunch of questions though, where are all the benchmarks? The docs, and everyone else, claims massive speedups from using immutable data structures, but it's never accompanied by any actual metrics, at least as far as my Google-fu gets me. All of our data lists are paginated server side, we're not doing any mass inserts on large data structures anywhere, and I've never noticed a performance problem on anything else I've written with similar requirements, so I find the claim that ImmutableJS is somehow going to speed up our app to be dubious at best. Moreover, every article under the sun craps on about how great it is to "enforce immutability", but nobody seems to be able to tell me when they last encountered a bug due to an inadvertant mutable update, how much time it cost them, or why they're hiring people who make such elementary mistakes in the first place; or if they do, it's some airy parable with no code example of the bug or the ImmutableJS code that could have fixed it.
- z3t4 9y ago
  You don't need a library. Just have a policy that everything should be immutable by default and only turn into mutable objects when optimizing, for example for-loops. The benefit with immutability is not performance (it's actually slower) but manageability and debug-ability. It's easier to reason about code when the variables doesn't change, and you'll get all the variable-states when debugging. Example: var foo = 1; var bar = foo + 1;
  - didgeoridoo 9y ago
    The "Performance" section of Facebook's own React docs has this line at the end: "Immutable data structures provide you with a cheap way to track changes on objects, which is all we need to implement shouldComponentUpdate. This can often provide you with a nice performance boost." What I don't really get is, if you've implemented PureComponent and shouldComponentUpdate wherever possible, how can adding Immutable possibly improve performance? I.e. if your components are ASSUMING their inputs are immutable, how does throwing errors on mutation attempts actually speed things up?
    - Silhouette 9y ago
      What I don't really get is, if you've implemented PureComponent and shouldComponentUpdate wherever possible, how can adding Immutable possibly improve performance? The argument is that if you prevent mutation then you can rely on only a shallow comparison of the object references as a reliable test for whether any of the data has changed. Your shouldComponentUpdate implementation becomes a one-line equality test for each prop that might change, or the equivalent. This may be significantly faster (and potentially easier to maintain) than any more detailed comparison of props to decide whether anything significant has changed in shouldComponentUpdate. Of course, this doesn't address the performance implications of maintaining your state in some sort of immutable data structures rather than just mutating it. Nor does it address the performance implications of using a library like React that declaratively renders your content and does the whole vDOM diff algorithm thing instead of just poking the DOM in exactly the required places. Both of those strategies can be orders of magnitude slower than the alternatives, and both of them can cause architectural and maintenance headaches of their own, and so the questions in those cases are whether the performance is still good enough and whether the benefits in other respects outweigh those costs.
merrvk 9y ago
Yeah thats what i was hoping for as well, if anyone has seen a piece like that i'd love to see it.
celim307 9y ago
Anyone know of a good article/series dealing with this? Tooling is fine and well, but I just got bumped to a lead role, with no one more experienced than me around, and could desperately use some more guidance.
awkwarddaturtle 9y ago
At least it wasn't another rant about how RDBMs suck and how great NoSQL or mongodb is or why can't I just store data in a json file. Baby steps. I try to see the silver lining in every cloud.

paradite 9y ago

This guide is more for beginners who just joined or want to join big tech companies. But I can see that your suggestions would make a great "power up as beginners" guide.

foota 9y ago
I think parent is asking for a guide for structuring large front end projects for intermediate-experienced front end developers.
- paradite 9y ago
  Oh, I see. That would also be great.

BigJono 9y ago

Yep, this is just rehashing the same stuff you can find on any one of 1000 other blog posts, articles or pieces of documentation. The current literature on front-end development in React is woefully short on real world case studies. It seems like everyone is building 30k loc throwaways with a 40 library boilerplate and slathering the internet with masturbatory praise for all the tooling and architectural patterns involved. If you try and Google for any actual details about said libraries, it's buried under mounds of beginner tutorials and faux praise. For example, we just made the decision to use ImmutableJS in a project. Everyone else on the team seems to be happy enough just reading a few blog posts about how great it is and then throwing it into the mix. I have a bunch of questions though, where are all the benchmarks? The docs, and everyone else, claims massive speedups from using immutable data structures, but it's never accompanied by any actual metrics, at least as far as my Google-fu gets me. All of our data lists are paginated server side, we're not doing any mass inserts on large data structures anywhere, and I've never noticed a performance problem on anything else I've written with similar requirements, so I find the claim that ImmutableJS is somehow going to speed up our app to be dubious at best. Moreover, every article under the sun craps on about how great it is to "enforce immutability", but nobody seems to be able to tell me when they last encountered a bug due to an inadvertant mutable update, how much time it cost them, or why they're hiring people who make such elementary mistakes in the first place; or if they do, it's some airy parable with no code example of the bug or the ImmutableJS code that could have fixed it.

z3t4 9y ago
You don't need a library. Just have a policy that everything should be immutable by default and only turn into mutable objects when optimizing, for example for-loops. The benefit with immutability is not performance (it's actually slower) but manageability and debug-ability. It's easier to reason about code when the variables doesn't change, and you'll get all the variable-states when debugging. Example: var foo = 1; var bar = foo + 1;
- didgeoridoo 9y ago
  The "Performance" section of Facebook's own React docs has this line at the end: "Immutable data structures provide you with a cheap way to track changes on objects, which is all we need to implement shouldComponentUpdate. This can often provide you with a nice performance boost." What I don't really get is, if you've implemented PureComponent and shouldComponentUpdate wherever possible, how can adding Immutable possibly improve performance? I.e. if your components are ASSUMING their inputs are immutable, how does throwing errors on mutation attempts actually speed things up?
  - Silhouette 9y ago
    What I don't really get is, if you've implemented PureComponent and shouldComponentUpdate wherever possible, how can adding Immutable possibly improve performance? The argument is that if you prevent mutation then you can rely on only a shallow comparison of the object references as a reliable test for whether any of the data has changed. Your shouldComponentUpdate implementation becomes a one-line equality test for each prop that might change, or the equivalent. This may be significantly faster (and potentially easier to maintain) than any more detailed comparison of props to decide whether anything significant has changed in shouldComponentUpdate. Of course, this doesn't address the performance implications of maintaining your state in some sort of immutable data structures rather than just mutating it. Nor does it address the performance implications of using a library like React that declaratively renders your content and does the whole vDOM diff algorithm thing instead of just poking the DOM in exactly the required places. Both of those strategies can be orders of magnitude slower than the alternatives, and both of them can cause architectural and maintenance headaches of their own, and so the questions in those cases are whether the performance is still good enough and whether the benefits in other respects outweigh those costs.

merrvk 9y ago

Yeah thats what i was hoping for as well, if anyone has seen a piece like that i'd love to see it.

celim307 9y ago

Anyone know of a good article/series dealing with this? Tooling is fine and well, but I just got bumped to a lead role, with no one more experienced than me around, and could desperately use some more guidance.

awkwarddaturtle 9y ago

At least it wasn't another rant about how RDBMs suck and how great NoSQL or mongodb is or why can't I just store data in a json file. Baby steps. I try to see the silver lining in every cloud.