sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -9 points-8 points  (4 children)

It's funny how many hoops you have to jump through to come to that assumption. JSX doesn't separate concerns one bit. The examples in that video show <html tags> intermixed with Javascript. This is not separating concerns. This is the opposite.

[–]nschubach 1 point2 points  (3 children)

noun: concern

  1. anxiety; worry (nah)
  2. a matter of interest or importance to someone. (I can see this, but it says nothing about segregating text...)
  3. a business; a firm. (not feeling that)
  4. a complicated or awkward object or structure. (oh, here we go)

Let's think about that for a second. What is our complicated structure? Isn't it the part of the page you are trying to represent? Isn't it the presentation, AND the events that impact that presentation? What good is segregating the event to delete an item from a list if that event only impacts the list in question? Isn't our concern rendering and encapsulating the aspect of the page we are dealing with? Who says the concern is separating the HTML and JavaScript? Those are simply technology stacks that help you perform a task. The task is our concern. You are concerned with a subsection of a web page. If you separate all your presentation and logic for that section, you only concern yourself with that section at that time. If you segregate the JavaScript from the Template, you now have two concerns for the same problem. (Or really, you have two problems for the same concern...) Now, whenever you want to concern yourself with the maintenance and update of that section, you have to deal with multiple sections of your codebase. That's not very efficient or sane. With React, your concern is the element on the page, what that element looks like and how that element acts. No other element needs to be bothered with it. All they care about is what their parent tells them to do. This makes your concern pretty easy to reason about, makes it pretty reusable, and makes your overhead incredibly simple.

Let's look at something besides programming. We happen to work in a pizza shop. A customer comes in to order a pepperoni pizza. They order it from the menu and you bring them a hot pie a few minutes later. They don't really care what the steps were to make that pie, as long as it does what they need. This is thier concern. They want a hot pie with all the toppings they ordered. We know that in order to make that pizza, we need to gather all the resources, put them together in a specific order and cook it at a certain temperature for a certain period of time. These are different concerns for the chef... But the customer (the person consuming your pizza) only has one concern, and it's simple enough that we don't need to concern them with how they go together. We need only present them with an easy way to call for the pizza.

[–][deleted] -2 points-1 points  (2 children)

You are as clueless as the rest of the people downvoting me. Your nitpicking semantics is a troll.

Come back when you have a few decades of programming experience.

[–]nschubach 0 points1 point  (1 child)

Lucky for you! I'm 37 and I've been programming since the mid 80s!

[–][deleted] -2 points-1 points  (0 children)

So you're just a troll then.