4 ms·

> This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on

> This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function. I see this so much as an argument against React/JSX. I can not never figure out how putting the display logic in the display template is some how going away from separation of concerns. As for JXF being hard to learn, that is just silly. Sure there are a few quirks but nothing in comparison to a learning a new templating tag language.

nailer 9y ago
Without arguing one way or the other: - Traditional SoC: template, styling, and logic for my app are separated - React/ractive/vue/preact SoC: parts of my app - login boxes, payment areas, order displays - are separated. They may further be separated by template, styling, and logic or not. You're slicing something vertically vs horizontally. In practice I prefer one of these but saying which one wouldn't help illustrate the concept.
- mohaine 9y ago
  > Traditional SoC: template, styling, and logic for my app are separated No, they are not. There is no real difference (other then syntax) between { rows.map(r=>(<Row data={r} />)) } and <div ng-repeat="r in rows"><Row data={{n}}/></div> These are both logic that have to be run to display your page. The only real difference is that with JSX, it is easy and powerful enough to use that you could stick some non-display logic in there. Easy and powerful should not be an argument against it.
ashark 9y ago
We went from anything like JSX getting you laughed out of the room (LOL 'onclick' properties, hello, 1998 called! Also code doesn't belong in markup, so markup certainly doesn't belong in code, are you insane? Templates! Separate style!) and sensible, healthy skepticism of workflows like "compiling" not-html to still-not-HTML to eventually generate HTML at runtime, to all of that being just fine and anyone not immediately on board with it being called a moron seemingly overnight, I guess because Facebook says it's fine? Some people have a little whiplash from all that, and I think it's understandable.
- christophilus 9y ago
  It's because it flew in the face of commonly accepted best practices. It felt like a return to PHP/ASP days of old. But in reality, once you use it, you realize it's not that. It's a good abstraction. It puts concerns in the right place. Now, when I have to write something in any .erb file, it's like pulling teeth. JSX + React is a very good view-layer and component abstraction.
  - ashark 9y ago
    I'm not even saying it's a bad idea, just that I think it's entirely understandable that people are a little confused and upset that a decade plus of best practices suddenly did a 180 and they're being looked down on for even taking a second to go, "wait, what?"
    - chrisco255 9y ago
      I guess these arguments feel a bit dated at this point. React has been out for four years now.
    - orclev 9y ago
      Part of what's missing is that separation of concerns doesn't mean not mixing code and markup, it means not mixing your business logic with your rendering logic. One way of enforcing that is to put your rendering logic into a straightjacket and restrict it to very very simple primitives, nothing more complex than a simple for loop over some indexed value or a very primitive form of if/else statement, which is basically what most of the templating systems do. That forces you to keep your business logic out of the view logic because the view rendering system simply isn't powerful enough to express most of your business logic. It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.

nailer 9y ago

Without arguing one way or the other: - Traditional SoC: template, styling, and logic for my app are separated - React/ractive/vue/preact SoC: parts of my app - login boxes, payment areas, order displays - are separated. They may further be separated by template, styling, and logic or not. You're slicing something vertically vs horizontally. In practice I prefer one of these but saying which one wouldn't help illustrate the concept.

mohaine 9y ago
> Traditional SoC: template, styling, and logic for my app are separated No, they are not. There is no real difference (other then syntax) between { rows.map(r=>(<Row data={r} />)) } and <div ng-repeat="r in rows"><Row data={{n}}/></div> These are both logic that have to be run to display your page. The only real difference is that with JSX, it is easy and powerful enough to use that you could stick some non-display logic in there. Easy and powerful should not be an argument against it.

ashark 9y ago

We went from anything like JSX getting you laughed out of the room (LOL 'onclick' properties, hello, 1998 called! Also code doesn't belong in markup, so markup certainly doesn't belong in code, are you insane? Templates! Separate style!) and sensible, healthy skepticism of workflows like "compiling" not-html to still-not-HTML to eventually generate HTML at runtime, to all of that being just fine and anyone not immediately on board with it being called a moron seemingly overnight, I guess because Facebook says it's fine? Some people have a little whiplash from all that, and I think it's understandable.

christophilus 9y ago
It's because it flew in the face of commonly accepted best practices. It felt like a return to PHP/ASP days of old. But in reality, once you use it, you realize it's not that. It's a good abstraction. It puts concerns in the right place. Now, when I have to write something in any .erb file, it's like pulling teeth. JSX + React is a very good view-layer and component abstraction.
- ashark 9y ago
  I'm not even saying it's a bad idea, just that I think it's entirely understandable that people are a little confused and upset that a decade plus of best practices suddenly did a 180 and they're being looked down on for even taking a second to go, "wait, what?"
  - chrisco255 9y ago
    I guess these arguments feel a bit dated at this point. React has been out for four years now.
  - orclev 9y ago
    Part of what's missing is that separation of concerns doesn't mean not mixing code and markup, it means not mixing your business logic with your rendering logic. One way of enforcing that is to put your rendering logic into a straightjacket and restrict it to very very simple primitives, nothing more complex than a simple for loop over some indexed value or a very primitive form of if/else statement, which is basically what most of the templating systems do. That forces you to keep your business logic out of the view logic because the view rendering system simply isn't powerful enough to express most of your business logic. It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.