Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Let's maybe start by defining what separation of concern is. You seem to make the destiction based in what you consider JS and what you consider HTML. Strictly speaking, JSX is not HTML. It's a template engine. And a template has certain things it should "take care of" and things it shouldn't. And of course you can and should separate these concerns with React just like when using anything else. The only reason to argue for the "freedom" of mixing up business logic and templating is if you don't want to follow this separation.
What you consider "pseudo JS" in other frameworks is the binding between markup and JS. As a simple example:
Here our "HTML" binds to our state which is absolutely okay for templating and belongs there. The markup is a question of taste, of course, but nothing wrong with this.
...return(<divclassName="some">{props.condition?(constparseCondition=()=>{// Let there be mess....}...):null}</div>
)...
In this extreme example we start mixing business logic and templating. And that will have issues with scope next to being a mess in itself. And I am sure you wouldn't write like that, bringing us back to the question: what freedom are you missing in alternative solutions?
JSX and other solutions need to be compiled. So wether or not business logic and template are in the same source file is again completely irrelevant from a functional perspective. It would just force clean code hence I would personally prefer it.
Linting is also completely irrelevant as all popular frameworks have a solution for popular IDEs (and only Vue when used as UMD would have valid markup without bundlers and IDEs taking care of things).
Lastly, being only concerned with one isolated UI component is not achievable in reality. At the end of the day, you will always have a page/route handling props, listening to events or passing down callbacks. Especially because we want to limit coupling separation of concern is so important.
Anyway, all if that doesn't mean that JSX isn't a nice solution. It just happens to be the worst when comparing it to Angular or Vue. And it is always hard to believe for me when people say they have spent extensive time as professionals with all these solutions and then say that JSX is most solid. In all honesty - and I really don't mean to offend - I tend to believe that either the complexity of the applications they built wasn't high enough or they are exaggerating the amount of time spent on different solutions.
Angular and Vue both try to shove a half-baked attempt at integrating js into their HTML and it comes off very difficult and limited
I agree with @seanmclem
. I'm a big fan of separation of concerns and keeping UI as dummy as possible. And the templating languages provide kind of API/contract. I even had a chance to develop one and I soon realised I need to provide more flexibility. My problem with templating languages is that they are still mix of HTML and pseudo JS (e.g. loops and conditionals). I understand using attributes in a declarative way (passing strings) to tell renderer what is what, but having kind of inline JS in them is just too much. Therefore, I decided to develop a pure JS syntax which is always consistent, even in edge cases and can be easily generated from HTML (codepen.io/Czopp/pen/zYKRrXo). How to constrain it so developers (especially less experienced) don't make a spaghetti out of it might be done by linting or at transpiling.
We can agree to disagree then. JSX works best for me in everything that I do. I would caution passing judgement on everyone who doesn't agree with you..
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Absolutely, you should take pride of your informed tech decisions. The nice thing about this industry is a large choice of tools which I believe drives the progress and innovation.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Let's maybe start by defining what separation of concern is. You seem to make the destiction based in what you consider JS and what you consider HTML. Strictly speaking, JSX is not HTML. It's a template engine. And a template has certain things it should "take care of" and things it shouldn't. And of course you can and should separate these concerns with React just like when using anything else. The only reason to argue for the "freedom" of mixing up business logic and templating is if you don't want to follow this separation.
What you consider "pseudo JS" in other frameworks is the binding between markup and JS. As a simple example:
Here our "HTML" binds to our state which is absolutely okay for templating and belongs there. The markup is a question of taste, of course, but nothing wrong with this.
In this extreme example we start mixing business logic and templating. And that will have issues with scope next to being a mess in itself. And I am sure you wouldn't write like that, bringing us back to the question: what freedom are you missing in alternative solutions?
JSX and other solutions need to be compiled. So wether or not business logic and template are in the same source file is again completely irrelevant from a functional perspective. It would just force clean code hence I would personally prefer it.
Linting is also completely irrelevant as all popular frameworks have a solution for popular IDEs (and only Vue when used as UMD would have valid markup without bundlers and IDEs taking care of things).
Lastly, being only concerned with one isolated UI component is not achievable in reality. At the end of the day, you will always have a page/route handling props, listening to events or passing down callbacks. Especially because we want to limit coupling separation of concern is so important.
Anyway, all if that doesn't mean that JSX isn't a nice solution. It just happens to be the worst when comparing it to Angular or Vue. And it is always hard to believe for me when people say they have spent extensive time as professionals with all these solutions and then say that JSX is most solid. In all honesty - and I really don't mean to offend - I tend to believe that either the complexity of the applications they built wasn't high enough or they are exaggerating the amount of time spent on different solutions.
I agree with @seanmclem . I'm a big fan of separation of concerns and keeping UI as dummy as possible. And the templating languages provide kind of API/contract. I even had a chance to develop one and I soon realised I need to provide more flexibility. My problem with templating languages is that they are still mix of HTML and pseudo JS (e.g. loops and conditionals). I understand using attributes in a declarative way (passing strings) to tell renderer what is what, but having kind of inline JS in them is just too much. Therefore, I decided to develop a pure JS syntax which is always consistent, even in edge cases and can be easily generated from HTML (codepen.io/Czopp/pen/zYKRrXo). How to constrain it so developers (especially less experienced) don't make a spaghetti out of it might be done by linting or at transpiling.
We can agree to disagree then. JSX works best for me in everything that I do. I would caution passing judgement on everyone who doesn't agree with you..
Didn't mean to judge, it's more of a disbelief that one can come to that conclusion. So sorry if that sounded too harsh
Well I have worked with many other formats and I take pride in my informed decision of preference
Absolutely, you should take pride of your informed tech decisions. The nice thing about this industry is a large choice of tools which I believe drives the progress and innovation.