Don’t use JSX

Valera Tretyak
4 min readMar 14, 2016

--

You already have all you need in js (jsnox — pure js). And it’s good enough, so you don’t need to use something new.

Code length comparison

Here is an example from ToDoMVC:

And the same in js

SLOC: 8% more using JSX

Symbols: 14% more using JSX

JS wins

Syntax complexity comparison

  • `=` means `:`

There is object type in js with the key-value notation that all we know from childhood. Between key and value should be `:`. Why do you need another way to do the same. Is `=` better than `:`? Especially when we have already decided what should be there.

  • {} or not {}

Should you wrap `true` with {}?

Should you place string literals in {}?

For callbacks, should I put execution code or link to function?

When to use `<main/>`?

There are answers and they are simple. But it’s additional cognitive weight.

  • gt < and lt >

This two symbols with JSX used for two things — comparison and tag brackets.

  • duplication of tag names

When you use JSnoX you change the name of rendered component only in one place. With JSX, you need to make all this changes twice.

In the end:

syntaxComplexity(JSX)~=syntaxComplexity(JS) + syntaxComplexity(XML)

JS wins

Copy-paste HTML snippets

Do you want to copy-paste HTML snippets without changes?

You can’t do this with JSX.

  • If you need to use big pieces of static HTML you just don’t need React
  • Most of React components is very dynamic. So you’ll rewrite this piece of code
  • There are differences with XML, so you should check them after paste (className in every tag, but not only)

Sure, also you can’t do this with pure js.

But how often do you need this? For all the time I’ve never needed it.

JSX wins, but it doesn’t matter

Leaky abstraction

When you write JSX, actually you write JS code in JS context. So you should think in one way but write in another.

Because of that, usually, you want something from JS world in JSX. And JSX makes it harder because you should switch to JS to do the thing, and switch back then.

With JS, you are a bit closer to what really happens in your code, and there are fewer barriers between code and what it does.

JS wins

Tools

JSX is a new language. It needs its own tools and adapters for tools.

Count of tools for JS > Tools for JSX

No Tern, some troubles with beautifying, weird autocomplete in most editors, etc.

JS wins

Time spent on tools

There are no reasons to create JSX (let’s assume that if you still don’t believe me).

And now imagine how much time spent on JSX compiler, adding JSX support to Atom, Visual Studio, VIM, emacs, sublime, beautify, typescript, coffeescript, jsbin, jsfiddle, babel compiler, JSX for virutaldom, etc. and etc.

And all that for simply wrap component names with `<>`!?

Build step

Most of the developers use compile step for their projects, and probably you too.

It is always simpler to just write pure js and run it in the browser without any setup. It really matters for newbies. If you are not a nerd unlikely you want to spend your evening on choosing build tool and setup it for your needs.

And it’s true for small libraries. React is nice because while writing your private project you can move some of your components to its own modules and open source. And if you use JSX, you’ll need to setup building environment for just one small component. Most likely you’ll decide to do nothing because you’re lazy and “that’s ok”.

JS wins

How to make life harder (IF in JSX, react-router)

Some developers like XML as much as they think, that they can replace JS with it.

Isn’t it weird? You add JSX to add the library to make if in xml? And then this if isn’t so lazy as you are, and it renders both if and else branches but uses only one for actual rendering.

There is a tendency to move some functional parts of an application to components that don’t render anything. react-router isn’t so bad, but I think, that there is no reason to make it using components.

My JSnoX style guide

These simple rules help me to understand and maintain code in render methods easily.

Designers don’t understand JS

100% that they’ll break JSX. Especially after some dynamics has been added, if designers don’t understand JS, you’ll sit near and make their work.

You have troubles anyway, I think it’s better to fix them in the root.

JS is really important to everyone in web-dev. You shouldn’t avoid it, it’s better to get a profit from the knowledge.

Is there anyone who enjoy JSX?

You can try to search the web on “JSX is awesome”. And there are some results, but all of them about “JSX is not so bad”, “JSX is awesome (and I haven’t known that React works without JSX, so actually, I talk about React awesomeness)”.

No one actually loves it. They just use it without reason, probably, because facebook says that JSX is better.

Why should JSX be deprecated?

Ok, JSX is not so good. But maybe it’s an issue of preferences?

Actually, no one died because of JSX.

But there is so much unnecessary shit here, so community would rather concentrate on more useful things.

--

--