Why are some developers against mixing HTML and JavaScript (as in React)?

I recently came across this article that discusses the sad state of web development. But the question is why "mixing JavaScript and HTML bad"? Companies like Khan Academy, Atlassian, Instagram, Facebook etc have embraced React and they are doing it successfully. So, why are some developers still skeptic?

Comments (15)

Denny Trebbin's photo

The time wasn't right until React + JSX taught us it is.

That is because developers are also just humans after all. Misunderstanding is common. And our tools wasn't good enough to support mixing languages in the same file (ye few existed, and also we loved to create new faster template languages).

Separation of concerns was​ always used as separation of technologies - we all felt comfortable. Projects like jQuery and Wordpress showed us how bad mixing technologies in a single file can be. Spaghetti code was all around. We've tried to overcome that misunderstanding by creating templating libraries. A mixture of 2 languages. We all liked it.

Since React + JSX and tools like Babel.js or Atom, it's easy to put all the view logic in one file. No need for a template language anymore, that can be parsed by our <programming language> compiler/transpiler in our IDE.

Now IDEs can detect multiple syntaxes in one file and support with code highlighting and error detection. And also, older IDEs and Editors have become useful thanks to plugins or CLI tools.

The time is right to keep code where it belongs to.

Jan Vladimir Mostert's photo

Just as inline styling and inline JS is bad practice, so is is inlining HTML in your JS. Same goes for mixing HTML inside you PHP or for mixing Java code inside your JSP tags via scriptlets.

If you look at why MVC was created in the first place, it was created to seperate view logic from business logic from data logic, same goes for MVP or MVVP or whatever they're called these days.

The general design principal is called Seperation of Concerns

The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.

HTML, CSS and JavaScript specific:

HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript (JS) are complementary languages used in the development of webpages and websites. HTML is mainly used for organization of webpage content, CSS is used for definition of content presentation style, and JS defines how the content interacts and behaves with the user. Historically, this was not the case: prior to the introduction of CSS, HTML performed both duties of defining semantics and style.

Show all replies
Michael Brown's photo

CSS within React components is not something that I'm doing in my projects. React certainly lets you go that way, but it doesn't mandate it. If you're happy to load your CSS with good old link tag, like me, then you'll be fine.

Explain why having to look in two files (JS file and template file) it's easier to follow the logic of your app than if you only have to look in one. Even if you have two monitors it's a pain. (I have two monitors, incidentally: one has my editor, Sublime Text, and the other has my browser. Maybe I need three monitors to do things your way!)

I can move React components from project to project easily. As long as I have documented what the props are, and what the event callbacks are, if any. I don't have to pick up a bit of JavaScript and a bit of templating language and sort out where then need to go in my destination project, and how they work together.

And did I mention that templating languages just suck? They bring their own language elements that are non-standard and a pain to work with. If a designer can work with Angular's multitude of ngWhatevers, I think they ought to be able to work with JSX, which looks just like HTML.

Jaroslaw Zabiello's photo

JSX has nothing to do with HTML. It only resembles it. JSX is just a syntactic sugar for plain JavaScript functions. It is also optional. And as we look at packages like react-native, react-art, react-canvas, and react-three, it's become also clear that the beauty and essence of React has nothing to do with browsers or the DOM.

Show all replies
Ingmars Lazdins's photo

Probably The Best Sarcasm In The World.

Or was it?

Yesid Ghisays's photo

React never uses html, it uses JSX which hides the following:

React.createElement('div')

There is no issue of separtion of concerns because in the first place you never wrote html in js.

Timothy Wu's photo

I have not understand React enough. However, the argument doesn't appear hold for me because it doesn't take a way the fact that there is no separation between the view templates and the logical that bind the models (states) together.

Torsten Hein's photo

i think it is the misconception that technology is your concern. but it is not. the domian is our concern. the tech is only a tool. a detail. so separation of concern is not separation of technology.

alsjemeneus's photo

It is not necessarily wrong, however there is absolutely no reason to do it that way. Especially not the way that react does it with HTML strings in javascript, never seen anything more rediculous than that. Angular does it the other way around, they do all kind of js style syntax in there HTML view. Also not a fan.

In the end it's all about personal preferences and your own clear development vision and strategy. IMO: do not use inline HTML and use inline JS only to bind an event handler like onclick="controller.click" or when using a fw for data binding. No statements in markup like: x for x in items or { (x + y) }