5 ms·

Well, that's nice. I guess the React community is aiming to try every permutation within potential state management solution space, I mean something have to wor

Well, that's nice. I guess the React community is aiming to try every permutation within potential state management solution space, I mean something have to work after all.

sametmax 8y ago
I remember when you had to choose between flux, redux, alt, reflux, flummox, fluxible, fluxxor, marty.js, fynx, MacFly, DeLorean.js, fluxify, fluxury, exim, fluxtore, Redx, fluxx... (no I'm not making those names up: https://github.com/kriasoft/react-starter-kit/issues/22 https://github.com/kriasoft/react-starter-kit/issues/22) Every single time somethings come up, in the JS word, they try to repeat one of the mistakes from the past and completly ignore everyone else solutions and experience. It's like a compulsion. In a year or two, your dependancies will be a representative sample of all permutations of those solutions, and will have to be maintained in that state forever, incompatible, or abandonned. You'll open some of them, trying to fix it, but you'll notice they all use different coding style, best practices, libs, and tooling. The dev that fought you in comments saying it would be fine is nowhere to be found now. Most JS devs don't care. They don't maintain their stuff. Appart from the stuff that get famous because made by great coders (no matter the language), most projects die silently. There is a terrible graveyard hidden behind the corporate wall. Java, C++, Python and even Ruby projects are standing well and alive, next to the countless bodies of the last generation of JS frankeinstein monsters that were hype-sold to upper management to create something that could have been done in PHP 3. Then a new stuff will arrive in the JS space, with again the potential of creating more confusion, more technical debt. You will raise your voice, and the JS community will scream back at you that you don't know what's good, you want to live with cavemen, and everything is great. They will get angry, and never see any problem. Then rince and repeat.
- nicoburns 8y ago
  That, or you can continue to use redux, which has existed since 2015, is mature, and still by far the most widely used state management system for react.
  - sametmax 8y ago
    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
- bsbechtel 8y ago
  You’re comparing entire languages to libraries made for a specific task within one language.
  - sametmax 8y ago
    No, I compare language ecosystems, and cultures.
- mosselman 8y ago
  "Every single time somethings come up, in the JS word, they try to repeat one of the mistakes from the past and completely ignore everyone else solutions and experience." I agree with the sentiment so just out of curiosity: what are these existing solutions that people should look at and take lessons from?
  - sametmax 8y ago
    A few on the top of my head: - Clear best pratices provided with tools. Do you know how to code a react project ? The person next to you has a different answer. - Reference implementations. We heard about the Flux pattern and the idea of stores for a long time before understanding concretly what it meant. And then pouf, 200 store and routing implementations differing in opinion, and no voice or advice about what to use and how. - Integrations layers. Everything is a lib gets old really fast. And "look how redux is simple" as well. Assembly is simple but I don't code my website with it. - Deprecation policies and clear migration path. Webpack was weird, quirky and badly documented. But the worst thing was that once you figured out something that works, a new version broke compat. - Avoid dependancy creep. When a dependancy has more package metadata than code, there is a problem. - Don't encourage a cowboy culture. It's great anybody can start coding in JS in an afternoon. It's not great that after a month the same person market his lib like it's the best thing ever and production ready. - Documentation that makes sense. People explaining a new tool by showing you something webpack based or in in jsfiddle is not doing his job properly. - Api best practices and design patterns have existed for a long time. Use them. KISS. DRY. Don't break user land. Principle of least surprise. - Don't rename things that have had conventional names for decades. "Flux is a not MVC" is a lie. It's mono-directional, it encourages single instance immutable model. But it's still MVC. Most people looked for very complicated answer to what is flux because of that. And who name a lifecycle method "componentWillUpdate()" ? "onUpdate()" and "onPostUpdate()" are the legacy jargon. And then "UNSAFE_componentWillUpdate()" ? Really ? Like really ? Never heard of warnings ? Using the JS className instead of the HTML class in JSX is also still amazing me, not in a good way. - Don't give the same name to 2 different products. Looking at you angular. Also SemVer is not a bad word, I and don't want your weird release name. That double the suff I potentially could google for. - Conventions are nice. They should not replace configuration, but they complement it very well. - There is such a thing as a "typical use case" for many tools. You should design for that, and if it's not possible for you, build a layer of top for that. Building facebook is not "a typical use case". Passing data from a children to a parent after a click and a preventDefault is. Why is the later so damn verbose ? Why did have I to google it ? - Scaling down is as important as scaling up. Make simple things easy and complicated things possible, not the contrary. - New is not always better, sorry barney stinson. Satisfying users with working software is. If you make or use something new, you should evaluate the cost for you and others before going "oh shiny !". There are many others, but I don't feel happy writting this, so I'm going to stop.
slifin 8y ago
They haven't copied om next (fulcro makes it easier) https://www.youtube.com/watch?v=ByNs9TG30E8 https://www.youtube.com/watch?v=ByNs9TG30E8 #graphs-not-trees
yen223 8y ago
That's true. It's certainly better to explore than to pretend that the first solution you come up with is somehow the best.
antihero 8y ago
I mean frankly going back to other forms of development (e.g. native apps) which seem to still be at the "jQuery" level of state management and UI mutating, I am glad there has been innovation in the JS space.

Well, that's nice. I guess the React community is aiming to try every permutation within potential state management solution space, I mean something have to work after all.

sametmax 8y ago

I remember when you had to choose between flux, redux, alt, reflux, flummox, fluxible, fluxxor, marty.js, fynx, MacFly, DeLorean.js, fluxify, fluxury, exim, fluxtore, Redx, fluxx... (no I'm not making those names up: https://github.com/kriasoft/react-starter-kit/issues/22 https://github.com/kriasoft/react-starter-kit/issues/22) Every single time somethings come up, in the JS word, they try to repeat one of the mistakes from the past and completly ignore everyone else solutions and experience. It's like a compulsion. In a year or two, your dependancies will be a representative sample of all permutations of those solutions, and will have to be maintained in that state forever, incompatible, or abandonned. You'll open some of them, trying to fix it, but you'll notice they all use different coding style, best practices, libs, and tooling. The dev that fought you in comments saying it would be fine is nowhere to be found now. Most JS devs don't care. They don't maintain their stuff. Appart from the stuff that get famous because made by great coders (no matter the language), most projects die silently. There is a terrible graveyard hidden behind the corporate wall. Java, C++, Python and even Ruby projects are standing well and alive, next to the countless bodies of the last generation of JS frankeinstein monsters that were hype-sold to upper management to create something that could have been done in PHP 3. Then a new stuff will arrive in the JS space, with again the potential of creating more confusion, more technical debt. You will raise your voice, and the JS community will scream back at you that you don't know what's good, you want to live with cavemen, and everything is great. They will get angry, and never see any problem. Then rince and repeat.

nicoburns 8y ago
That, or you can continue to use redux, which has existed since 2015, is mature, and still by far the most widely used state management system for react.
- sametmax 8y ago
  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
bsbechtel 8y ago
You’re comparing entire languages to libraries made for a specific task within one language.
- sametmax 8y ago
  No, I compare language ecosystems, and cultures.
mosselman 8y ago
"Every single time somethings come up, in the JS word, they try to repeat one of the mistakes from the past and completely ignore everyone else solutions and experience." I agree with the sentiment so just out of curiosity: what are these existing solutions that people should look at and take lessons from?
- sametmax 8y ago
  A few on the top of my head: - Clear best pratices provided with tools. Do you know how to code a react project ? The person next to you has a different answer. - Reference implementations. We heard about the Flux pattern and the idea of stores for a long time before understanding concretly what it meant. And then pouf, 200 store and routing implementations differing in opinion, and no voice or advice about what to use and how. - Integrations layers. Everything is a lib gets old really fast. And "look how redux is simple" as well. Assembly is simple but I don't code my website with it. - Deprecation policies and clear migration path. Webpack was weird, quirky and badly documented. But the worst thing was that once you figured out something that works, a new version broke compat. - Avoid dependancy creep. When a dependancy has more package metadata than code, there is a problem. - Don't encourage a cowboy culture. It's great anybody can start coding in JS in an afternoon. It's not great that after a month the same person market his lib like it's the best thing ever and production ready. - Documentation that makes sense. People explaining a new tool by showing you something webpack based or in in jsfiddle is not doing his job properly. - Api best practices and design patterns have existed for a long time. Use them. KISS. DRY. Don't break user land. Principle of least surprise. - Don't rename things that have had conventional names for decades. "Flux is a not MVC" is a lie. It's mono-directional, it encourages single instance immutable model. But it's still MVC. Most people looked for very complicated answer to what is flux because of that. And who name a lifecycle method "componentWillUpdate()" ? "onUpdate()" and "onPostUpdate()" are the legacy jargon. And then "UNSAFE_componentWillUpdate()" ? Really ? Like really ? Never heard of warnings ? Using the JS className instead of the HTML class in JSX is also still amazing me, not in a good way. - Don't give the same name to 2 different products. Looking at you angular. Also SemVer is not a bad word, I and don't want your weird release name. That double the suff I potentially could google for. - Conventions are nice. They should not replace configuration, but they complement it very well. - There is such a thing as a "typical use case" for many tools. You should design for that, and if it's not possible for you, build a layer of top for that. Building facebook is not "a typical use case". Passing data from a children to a parent after a click and a preventDefault is. Why is the later so damn verbose ? Why did have I to google it ? - Scaling down is as important as scaling up. Make simple things easy and complicated things possible, not the contrary. - New is not always better, sorry barney stinson. Satisfying users with working software is. If you make or use something new, you should evaluate the cost for you and others before going "oh shiny !". There are many others, but I don't feel happy writting this, so I'm going to stop.

slifin 8y ago

They haven't copied om next (fulcro makes it easier) https://www.youtube.com/watch?v=ByNs9TG30E8 https://www.youtube.com/watch?v=ByNs9TG30E8 #graphs-not-trees

yen223 8y ago

That's true. It's certainly better to explore than to pretend that the first solution you come up with is somehow the best.

antihero 8y ago

I mean frankly going back to other forms of development (e.g. native apps) which seem to still be at the "jQuery" level of state management and UI mutating, I am glad there has been innovation in the JS space.