But do you want web designers to mess with your markup? Many of the projects I work on still involve the 'old-fashioned' server-side rendering approach with bits of jQuery for interactive elements. If a non-coder webdesigner were to mess with my markup, everything would break anyways.
I guess what I'm saying is that I've worked on many types of projects in many kinds of environments, and whenever a front-end framework was necessary, the 'webdesigners' were not. I've just never run into the situation where it actually ended up being useful to create logic-less templates...
Honestly I wouldn't hire a web designer that can't code a little Javascript. It's been a while since knowing only HTML as a web designer has been acceptable.
To answer your question though: they're probably about the same level of difficulty, and I don't think it's a great argument for vanilla/React/Angular because a person who doesn't understand code trying to modify stuff that is controlled by code is going to break something regardless of what JS framework you're using.
I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. The ESX syntax is just a nice way of forming a hierarchy of class instances. The beauty of React is that you could come up with your own syntax for doing that and use it just the same, because React is just Javascript.
> I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending.
Yeah, that's what it really boils down to. Many of the principles we apply are holdovers from when we used HTML and CSS for what it was originally intended: pages with content.
The way I see it, HTML and CSS were not meant for any of these apps. But if we are going to 'abuse' these technologies, we might as well chuck out the rulebook and optimize for what apps need to do.
That said, please don't do this if what you're making is 'pages with content'!
Not at all! I might not have expressed myself clearly...
The point I was trying to make is that JSX is significantly more convenient for coders like me, as the markup is is the trivial part and the logic is usually the complicated part. So a javascript-first approach benefits me tremendously over trying to figure out how to get my logic working around the logic-less templating systems, or over learning a html-like DSL as in the case of Angular or Vue.js.
I've even considered not using JSX at all (a bit like mithril.js). The only reason I still do is that I like the visual separation of code and markup, and that I like seeing what the the end result will look like (more or less).
So if the JSX approach is so much more convenient for coders (not all, but many), and if the types of projects where you use React tend to be too complex to involve non-coders writing html/css anyways (in my experience), why not just use JSX?
That said, I don't really have a horse in this race either, I guess, because I'll adjust my choices based on circumstances. A while back, for example, I used Ractive.js instead of React.js for a project, because Ractive.js uses mustache templates and simpler two-way binding (a bit like Knockout.js). Because of the particular circumstances and the relative lack of complexity of the app, I figured I'd optimize for what cheap(er) front-enders with less coding experience could take over from me, as I wasn't planning to stay on the project long-term.
I guess what I'm saying is that I've worked on many types of projects in many kinds of environments, and whenever a front-end framework was necessary, the 'webdesigners' were not. I've just never run into the situation where it actually ended up being useful to create logic-less templates...