4 ms·

Yes, except when redux came out, nobody could know since there was so many competitors. It tooks years to sort that out. Yes except we spent years having so m

Yes, except when redux came out, nobody could know since there was so many competitors. It tooks years to sort that out. Yes except we spent years having so many projects crashing under the complexity of using a store, most juniors being unable to produce decent code and managing the numerous layers of indirection. Yes except we learned later, hey, a store is not required for most projects. You totally should use react without a store for your little service. But we won't give you a best practice to do so. Yes except for a single little incremental counter in redux, tutorials invite your to create a store, an action factory, and action dispatcher, an adapter to connect them, and then use a provider to pass the store. To escape this madness, you may use, yet another abstraction du jour, or just write hundreds of lines of boiler plate. Or do it another way, hoping it's alright, and creating yet another differently styled code base. Yes except mobx or vue are way easier to use. Oh but they are yet another tool to learn and manage.

antihero 8y ago
So you suggest people don't innovate? I think what you say about redux is FUD. Sure, a bunch of libraries came out at the same time as it trying to solve the same issue. Redux happened to get the most traction and as such most people use it. It works fine. Approaches to it have changed as people have found issues with approaches - now people are fine with being chill and using internal state for some things, and the redux store where it makes sense. It isn't as bad as you make everything seem. Hooks are a novel way of sharing logic between components, and people are trying them because it seems like a cool idea - if it works it will stick.
- sametmax 8y ago
  Here it is, the angry JS dev saying I don't see things clearly and that the current situation in fine. Hello my friend. We meet again, today. We'll meet again tomorrow. Then next year. Rince and repeat, I said.
  - aurbano 8y ago
    Well, it's not an easy problem. I've been working on user interfaces for around 14 years, in several languages and platforms. React is the first time I feel like we've actually hit something good. It's still not fully there, but it's the closest it has felt to that so far. State management is messy, that's clearly an area where the problem still hasn't been solved. The main issue is that state means too much really. There's your (typically) main source of truth: the database. Then your server may maintain some state (although nowadays this is not common, thankfully). Then there's the frontend app state, which loads from the server/db, and may or may not staty up to date. On top of this you have temporary frontend state (unsaved changes), and finally pure UI state (hovering things, "show more"... ) Managing all of this is extremely difficult. Graphql with the appropriate frontend library for example is revolutionary in some ways, but a major difference in backend architecture, which isn't easy to reason about (fine grained entitlements, mutations & side effects such as notification emails, report generation.. are not easy) Anyway, my point is that I understand your frustration with how everything's outdated too quickly, and how in the past we had stable frameworks or languages. But I feel the reason is that we are actually in a transition period, and making a lot of progress really fast. Hopefully the outcome of these messy years is a Standard™ way to define a UI, it's state, and it's interactions with an API, in an e2e type-safe, testable manner. One can dream right?
    - sametmax 8y ago
      We agree on the fact it's a hard problem and i don't label react as a bad product. Plus, it's a necessary one given the way the internet is evolving.
monkeynotes 8y ago
> It tooks years to sort that out. Yep, maturing takes time - duh.
- sametmax 8y ago
  Maturing is good. Marketting beta products as solutions to the problems you have right now isn't. This problem doesn't exist in the PHP, Python or Ruby communities. We get incremental improvements, sometimes a few innovative contenders show up, we evaluate it, then a winner appear, generally under a year. With JS it's: - a new wild pokemon appears ! - quick, everybody make 200 new pokeball models and throw them at it - spend 3 years sorting said pokeballs, while the pokemon disapears
  - nicoburns 8y ago
    > quick, everybody make 200 new pokeball models and throw them at it I mean, it's not like this is forced upon you. You're free to continue to use Backbone or Knockout or Ember if you want to. Angular 1.x has been replaced with Angular 2 (and I think the Angular team was rightly criticised by how they managed this transition), but most other popular frameworks are still around. Of course, for new projects you may want to pick a newer framework if you believe it offers significant improvements over what came before. For me, React was clearly in this category. And yes, there are lot of people who chase the latest shiny thing, even if it is new and unproven. But that doesn't mean there aren't also stable, proven stacks.
    - sametmax 8y ago
      Nobody lives in a vacuum, and there are many reasons for not being able to choose the techs you will have to work with. In fact, the main reason is that there is no current other client side web language than Javascript. We don't use JS because it's great. It's a badly designed languages, and half of the stack we use are hacks to make it usable. We use it because there is nothing else.

antihero 8y ago

So you suggest people don't innovate? I think what you say about redux is FUD. Sure, a bunch of libraries came out at the same time as it trying to solve the same issue. Redux happened to get the most traction and as such most people use it. It works fine. Approaches to it have changed as people have found issues with approaches - now people are fine with being chill and using internal state for some things, and the redux store where it makes sense. It isn't as bad as you make everything seem. Hooks are a novel way of sharing logic between components, and people are trying them because it seems like a cool idea - if it works it will stick.

sametmax 8y ago
Here it is, the angry JS dev saying I don't see things clearly and that the current situation in fine. Hello my friend. We meet again, today. We'll meet again tomorrow. Then next year. Rince and repeat, I said.
- aurbano 8y ago
  Well, it's not an easy problem. I've been working on user interfaces for around 14 years, in several languages and platforms. React is the first time I feel like we've actually hit something good. It's still not fully there, but it's the closest it has felt to that so far. State management is messy, that's clearly an area where the problem still hasn't been solved. The main issue is that state means too much really. There's your (typically) main source of truth: the database. Then your server may maintain some state (although nowadays this is not common, thankfully). Then there's the frontend app state, which loads from the server/db, and may or may not staty up to date. On top of this you have temporary frontend state (unsaved changes), and finally pure UI state (hovering things, "show more"... ) Managing all of this is extremely difficult. Graphql with the appropriate frontend library for example is revolutionary in some ways, but a major difference in backend architecture, which isn't easy to reason about (fine grained entitlements, mutations & side effects such as notification emails, report generation.. are not easy) Anyway, my point is that I understand your frustration with how everything's outdated too quickly, and how in the past we had stable frameworks or languages. But I feel the reason is that we are actually in a transition period, and making a lot of progress really fast. Hopefully the outcome of these messy years is a Standard™ way to define a UI, it's state, and it's interactions with an API, in an e2e type-safe, testable manner. One can dream right?
  - sametmax 8y ago
    We agree on the fact it's a hard problem and i don't label react as a bad product. Plus, it's a necessary one given the way the internet is evolving.

monkeynotes 8y ago

> It tooks years to sort that out. Yep, maturing takes time - duh.

sametmax 8y ago
Maturing is good. Marketting beta products as solutions to the problems you have right now isn't. This problem doesn't exist in the PHP, Python or Ruby communities. We get incremental improvements, sometimes a few innovative contenders show up, we evaluate it, then a winner appear, generally under a year. With JS it's: - a new wild pokemon appears ! - quick, everybody make 200 new pokeball models and throw them at it - spend 3 years sorting said pokeballs, while the pokemon disapears
- nicoburns 8y ago
  > quick, everybody make 200 new pokeball models and throw them at it I mean, it's not like this is forced upon you. You're free to continue to use Backbone or Knockout or Ember if you want to. Angular 1.x has been replaced with Angular 2 (and I think the Angular team was rightly criticised by how they managed this transition), but most other popular frameworks are still around. Of course, for new projects you may want to pick a newer framework if you believe it offers significant improvements over what came before. For me, React was clearly in this category. And yes, there are lot of people who chase the latest shiny thing, even if it is new and unproven. But that doesn't mean there aren't also stable, proven stacks.
  - sametmax 8y ago
    Nobody lives in a vacuum, and there are many reasons for not being able to choose the techs you will have to work with. In fact, the main reason is that there is no current other client side web language than Javascript. We don't use JS because it's great. It's a badly designed languages, and half of the stack we use are hacks to make it usable. We use it because there is nothing else.