As opposed to working with regular HTML, razor pages, AngularJS or Angular's HTML implementations, and vue's. I've used them all. Not just in hobby projects but pretty extensively in my career. After spending much time with each I definitely prefer jsx the best
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
I so consistently need to control my html with Javascript. Feel like the separation of HTML and JavaScript doesn't really make any sense in modern Frameworks. 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. Something like v-for="video in playlist" inside html makes a lot less sense to me than using a js map to loop over an array to return markup
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
Feel like the separation of HTML and JavaScript doesn't really make any sense in modern Frameworks
These concepts are about separation of view and controller, not JS and html. And with monitors becoming bigger and frameworks compiling into components anyway, I personally hope the trend of holding both of these concerns in one file dies again. I would prefer having the view and the business logic next to each other, rather than stacked or worse - like often seen in React code - intertwined. So my perspective is a completely different one: declaration should happen in the view but state managed in the controller. And then "limiting" the view to bindings, iterations and conditions simply makes a way cleaner application.
That said, one can of course have different opinions on how markup for these cases should look like. But I would boldly and unapologetic claim that wanting to "not separate" is not an informed opinion and that clean and testable React components don't do that either. Or am I misunderstanding your point?
but they are not separated. The respective frameworks have pseudo JS in the HTML anyway. Since it's not actual JS -it's not as useful or flexible. Other frameworks html often feels like a hacky, unstable way to try and be plain HTML but be dynamic.
But typically, there is still separation anyway in frameworks like React. Separate UI components live separately from each other. The UI logic of a component makes sense to be right alongside the UI view of a component. There's no reason they need to pass data between 2 files to each other when they are only ever concerned with each other.
You are completely flexible to join or separate anything you want anyway. I prefer the freedom, and I love that JSX has become its own thing completely separate from just being a Facebook thing. It works very well to be parsed into an AST. Which allows it to have great intellisense, linting, other IDE plugins, transformations, transpiling to other languages, etc etc.
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.
As opposed to working with regular HTML, razor pages, AngularJS or Angular's HTML implementations, and vue's. I've used them all. Not just in hobby projects but pretty extensively in my career. After spending much time with each I definitely prefer jsx the best
Okay. And why is that? What does JSX solve nicer in your mind?
I so consistently need to control my html with Javascript. Feel like the separation of HTML and JavaScript doesn't really make any sense in modern Frameworks. 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. Something like
v-for="video in playlist"
inside html makes a lot less sense to me than using a js map to loop over an array to return markupThese concepts are about separation of view and controller, not JS and html. And with monitors becoming bigger and frameworks compiling into components anyway, I personally hope the trend of holding both of these concerns in one file dies again. I would prefer having the view and the business logic next to each other, rather than stacked or worse - like often seen in React code - intertwined. So my perspective is a completely different one: declaration should happen in the view but state managed in the controller. And then "limiting" the view to bindings, iterations and conditions simply makes a way cleaner application.
That said, one can of course have different opinions on how markup for these cases should look like. But I would boldly and unapologetic claim that wanting to "not separate" is not an informed opinion and that clean and testable React components don't do that either. Or am I misunderstanding your point?
but they are not separated. The respective frameworks have pseudo JS in the HTML anyway. Since it's not actual JS -it's not as useful or flexible. Other frameworks html often feels like a hacky, unstable way to try and be plain HTML but be dynamic.
But typically, there is still separation anyway in frameworks like React. Separate UI components live separately from each other. The UI logic of a component makes sense to be right alongside the UI view of a component. There's no reason they need to pass data between 2 files to each other when they are only ever concerned with each other.
You are completely flexible to join or separate anything you want anyway. I prefer the freedom, and I love that JSX has become its own thing completely separate from just being a Facebook thing. It works very well to be parsed into an AST. Which allows it to have great intellisense, linting, other IDE plugins, transformations, transpiling to other languages, etc etc.
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.