5 ms·

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 F

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.
    - timepiece 12y ago
      What about bringing CSS declarations to the mix? I have watched React Native talks in which they were advocating for this and bluntly calling it proper "separation of concerns". But when you say that presentational markup and logic should be grouped together, doesn't this mean that we have to divide our js files even further to separate business logic from presentation or view logic?
mejari 12y ago
>We should think on our own and figure what works for us and not blindly follow But doesn't your last comment rail against all these "fanbois" not blindly following "best practices" and actually attempting to find out what works best? In fact, your next sentence in this comment: >please don't attempt to reinterpret/bend the rules that are well established in the industry You seem to be contradicting yourself.
- timepiece 12y ago
  https://news.ycombinator.com/item?id=9258259 https://news.ycombinator.com/item?id=9258259

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.
  - timepiece 12y ago
    What about bringing CSS declarations to the mix? I have watched React Native talks in which they were advocating for this and bluntly calling it proper "separation of concerns". But when you say that presentational markup and logic should be grouped together, doesn't this mean that we have to divide our js files even further to separate business logic from presentation or view logic?

mejari 12y ago

>We should think on our own and figure what works for us and not blindly follow But doesn't your last comment rail against all these "fanbois" not blindly following "best practices" and actually attempting to find out what works best? In fact, your next sentence in this comment: >please don't attempt to reinterpret/bend the rules that are well established in the industry You seem to be contradicting yourself.

timepiece 12y ago
https://news.ycombinator.com/item?id=9258259 https://news.ycombinator.com/item?id=9258259