React’s JSX: The Other Side of the Coin
Cory House

I hate to say this, but it feels like the same old arguments that people used for HTML in Java servlets, and then JSP/JSTL and then JSF and then Groovy and GWT and then… The “if everything is just in [language] it’s so much easier to [debug, code, pick-your-problem-du-jour].”

I get it, I really do, having fought with exactly what you’re talking about of a little change over here in HTML means digging through code over here in CSS and JS too and having this cascade. I’m just still not sold on “put everything in JS” as a long term solution to the problem. I also struggle with the reusability of things. One example is I have an address view and an address form but the data populating the view is different depending on where in the app I use it. In one place the data is from patient.addressLine1 and in another place the binding is member.address1. Do I just resolve that I have to have multiple address templates with different bindings or do I have to create some model methods that map my incoming model to what my template is looking for and how much code does that end up being.

Other than “it feels icky” I think about things like code completion and validation. For example, what happens when I decide to wrap that table row in a div, or put a list item as a child of another list item, or nest forms, or use the same ID for two different inputs. Right now I get that information right away in my IDE as a warning and at build time in my problems log. How will JavaScript know that you’re producing valid HTML (not just valid XML) since you’re abstracting that part away. How much does it tie you to a single framework’s implementation. Does the abstraction really help debugging in the long term or is it a short term “feels good” kind of thing.

The other thing I wonder about is the product development lifecycle. When the designers mock up a new product and they have all the HTML/CSS all nice and shiny, do I just tell them to throw it away we’re rewriting it in JavaScript. That seems like a big waste and a potential for losing something during conversion. The alternative would be to pre-build some modules and have them use a library and learn React and do the interface right in JS, but it was hard enough getting them to come the step of making HTML and CSS instead of photoshoping every little detail. Now I have to tell them to either have throw away work again or make a big leap in comfort level to move into JS land so their’s less to transition from mockup/prototype to implementation.

The problem with people touting something as “evolutionary” or “game changing” as I’ve seen many people put this new/old step, is that it’s only provable at some point off in the future 3–5 years away. It needs time to mature and for processes to form around it and for tooling to catch up with the concept before we can call it anything other than “an idea” or “something you might wanna try out.”

Like what you read? Give Michael Ross Havard a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.