5 ms·

Absolutely, React is in the wrong here and its methodology is a clear and direct violation of the "separation of concerns" principle. First, they came for the

Absolutely, React is in the wrong here and its methodology is a clear and direct violation of the "separation of concerns" principle. First, they came for the HTML markup and said "come on guys, JSX is just some XML on steroids. You should not worry at all" and we didn't speak up. Then they came for CSS and said "come on guys, they're just small components and the same as placing the CSS declarations via the style attribute anyway blah blah blah" and we didn't speak up. So you don't really know what's gonna be their next victim. There's a lot of revisionism and reinterpretation of best practices going on in the industry and hipsters and fanbois seem to go chasing the latest shiny and trendy object out there. Nothing we can do to help save these people! But seriously guys, have you seen any React dev code with all those CSS declarations and HTML markup over each other? I pity the ones who will be assigned maintain this spaghetti code.

nwienert 12y ago
I've actually never found myself more productive than with React, by a long shot. The reasons why mixing them together makes sense are above us in the thread, but I'd highly recommend vjeux's presentation on CSS in JS: https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js I have apps in production with it you can look at the code to as well: https://github.com/reapp/hacker-news-app https://github.com/reapp/hacker-news-app
- timepiece 12y ago
  vjeux's presentation only applies to a very specific use case at his org namely FB. I should not imitate him just because of the fact that it fitted or served FB right. We should think on our own and figure what works for us and not blindly follow FB's or any other org's lead. Re productivity, if it works for you, good for you but please don't attempt to reinterpret/bend the rules that are well established in the industry just to avoid criticism. For me, it's just an act of intellectual dishonesty. React does violate the principle of separation of concerns and "we're working on a component not a document level" is not fooling anyone. We should alert and educate people on this issue and then they can decide for themselves if they would go ahead nevertheless or stick to their guns. That's all!
  - uptownJimmy 12y ago
    I don't give a hoot about "separation of concerns" unless it makes really, really good sense, which it often does not.
    - timepiece 12y ago
      Fair enough but please don't go around telling that mixing content/presentation/logic in a single entity is a valid case of "separation of concerns" but on a micro and not macro level. That's just not right!
      - uptownJimmy 12y ago
        There's a lot of things that may or may not be "right", and I'm not trying to do them, either...
  - nightski 12y ago
    I am curious, what concerns are not being separated? You have presentation markup with presentation logic. Actually it seems to me the concerns are being brought closer together. Or are you making artificial boundaries between declarative and imperative code?
    - timepiece 12y ago
      I'm OK with presentational markup co-existing with logic but to be honest I prefer it the template way not the other way around where the markup is the guest at the JS file. But throwing CSS declarations to the mix is just too much for me. Now I'll have to maintain markup/presentation/logic in the same place, that's a nightmare and ticking bomb IMHO.
      - mejari 12y ago
        >Now I'll have to maintain markup/presentation/logic in the same place Only if you're doing it wrong. Presentation logic and markup will be in the same place sure, that's a good thing, but any application logic not dealing directly with displaying dom elements shouldn't be in and among your presentation code. Your concerns are separated and your presentation code is in the same place, like you would logically think they should be.

nwienert 12y ago

I've actually never found myself more productive than with React, by a long shot. The reasons why mixing them together makes sense are above us in the thread, but I'd highly recommend vjeux's presentation on CSS in JS: https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js I have apps in production with it you can look at the code to as well: https://github.com/reapp/hacker-news-app https://github.com/reapp/hacker-news-app

timepiece 12y ago
vjeux's presentation only applies to a very specific use case at his org namely FB. I should not imitate him just because of the fact that it fitted or served FB right. We should think on our own and figure what works for us and not blindly follow FB's or any other org's lead. Re productivity, if it works for you, good for you but please don't attempt to reinterpret/bend the rules that are well established in the industry just to avoid criticism. For me, it's just an act of intellectual dishonesty. React does violate the principle of separation of concerns and "we're working on a component not a document level" is not fooling anyone. We should alert and educate people on this issue and then they can decide for themselves if they would go ahead nevertheless or stick to their guns. That's all!
- uptownJimmy 12y ago
  I don't give a hoot about "separation of concerns" unless it makes really, really good sense, which it often does not.
  - timepiece 12y ago
    Fair enough but please don't go around telling that mixing content/presentation/logic in a single entity is a valid case of "separation of concerns" but on a micro and not macro level. That's just not right!
    - uptownJimmy 12y ago
      There's a lot of things that may or may not be "right", and I'm not trying to do them, either...
- nightski 12y ago
  I am curious, what concerns are not being separated? You have presentation markup with presentation logic. Actually it seems to me the concerns are being brought closer together. Or are you making artificial boundaries between declarative and imperative code?
  - timepiece 12y ago
    I'm OK with presentational markup co-existing with logic but to be honest I prefer it the template way not the other way around where the markup is the guest at the JS file. But throwing CSS declarations to the mix is just too much for me. Now I'll have to maintain markup/presentation/logic in the same place, that's a nightmare and ticking bomb IMHO.
    - mejari 12y ago
      >Now I'll have to maintain markup/presentation/logic in the same place Only if you're doing it wrong. Presentation logic and markup will be in the same place sure, that's a good thing, but any application logic not dealing directly with displaying dom elements shouldn't be in and among your presentation code. Your concerns are separated and your presentation code is in the same place, like you would logically think they should be.