Newsletters like JavaScript Weekly has helped me tremendously over the years. If something big happens in the JS community you will be up to speed. Lately, JavaScript Weekly seems to feature more stories about frameworks like React and Angular. I wouldn't mind these kinds of features in moderation, but it seems to be favored. Too favored in my opinion. It creates a culture where "everything" has to be done in JSX and React. It reminds me of how jQuery reigned the front end development scene back in the day (and in some environments, still do!). JavaScript is a rising language and I think it's important to promote the new features in the ECMAScript standards rather than frameworks.

I just read a story on how CSSX is the next new thing in JS development. I wasn't a big fan of the JSX syntax and I can't imagine being intrigued by this stylesheet slugde. Mixing markup and code is just downright confusing to me. Let me list some reasons why I think that the JSX movement is bad for you.

Mix of rendering logic and business logic

An intricate part of JS development is the rendering logic. Separating templates and functionality is, to me, a good method to write clean code. Each has its own responsibility. One contains the business logic; testable and independent of the rendering all together. One has the rendering logic; that just requires a given state to render. I believe this is a good way to achieve single responsibility in JS.

When you shove both into one file, you get a weird mix. Although I'm sure there are good ways to write React code, I believe React makes it easy to write messy code. The formats blend together in an unnatural way. The JSX syntax allows for more complex templates. Many sees this as an advantage and I can see the points. In my opinion, templates should be as simple as possible and complexity belongs to a more testable layer. Adding too much complexity in the templates reduces re-usability and makes it harder to test.

Creating a "virtual DOM" that looks very much like the normal DOM, except it isn't. The concept of having classes as tags is not very intuitive. The format of the markup doesn't necessarily bother me a lot. It prevents a seamless swap of frameworks, but that's hard to achieve in any abstraction. This is also a design in frameworks like Angular and Vue.js.

//Tags as classes. Taken from https://facebook.github.io/react/docs/jsx-in-depth.html
var MyFormComponent = React.createClass({ ... });  
var Form = MyFormComponent;

var App = (  
  <Form>
    <Form.Row>
      <Form.Label />
      <Form.Input />
    </Form.Row>
  </Form>
);

Testing requires utilities

React comes with a set of utilities that makes it easier to test your modules. The same goes with Angular. Logic you want to test should lie outside the framework it selves. All logic should lead to the state of the component and the logic in the template should be as minimal as possible. Unit testing the DOM just seems unnecessary to me. This is something that the frameworks should take care of. The test should expect the output of the state, not the literal rendering that the framework produces.

Bad foundation

A big problem is plugin ability. What happens if I don't want to use React any more? This ripples in all parts of the application. Testing is React. Models are React. Renderings are React. If I ever wanted to change the framework, I'd had to change every line of code in all parts. Some parts should stay in pure JavaScript. Or, at most, use a minimal library that doesn't need a whole lot of bootstrapping to work. I believe that a good framework should be easy to change out. This is a challenge in all applications, regardless implementation. But the JSX seems like an unnatural way to separate the concerns since all formats melts in to each other.

How it should be

By using single responsibility pattern, we can separate the parts of complexity into smaller, more testable containers. I use tape as a test runner and I recommend using it. Testing should be as simple as possible and should only require a state to test the more complex parts of the code. I've previously written about a pattern that used Browserify and Vue.js. In that example, we separate the JS and HTML in the view logic. I think that is the most sensible approach. It's all about the correct separation of concerns. Drawing that line is hard sometimes. This is 100 % possible to achieve with React or any other framework. But it requires some thought and discipline to do development properly. React is a great tool that allows you to do a lot in the templates, but be vary and don't write yourself into a corner. With great tools comes great responsibility.