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!

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?

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.

>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.

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?

I don't give a hoot about "separation of concerns" unless it makes really, really good sense, which it often does not.

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!

There's a lot of things that may or may not be "right", and I'm not trying to do them, either...

>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.