5 ms·

JSX forces you into small tiny components because anything of any decent size becomes unmanageable. There's way too much mixing of JS into the template. Vue yo

JSX forces you into small tiny components because anything of any decent size becomes unmanageable. There's way too much mixing of JS into the template. Vue you can do <button :disabled="!isFormValid">Submit</button> In React I've seen people do: if (!props.isFormValid) { return <button>Submit</button>; } return <button disabled="disabled">Submit</button>; This is just an example, obviously you can write this better in React. My point is there's /always/ so much conditional markup like this in every react project I've come across or worked on. Edit: I donno how to format code on here sorry. (oh figured it out, bunch of spaces)

azangru 4y ago
> return <button disabled="disabled">Submit</button>; In JSX, the "disabled" attribute is a boolean; so it would be just: return <button disabled={!isFormValid}>Submit</button>;
- philliphaydon 4y ago
  > This is just an example, obviously you can write this better in React. The issue is people write SO much conditional logic into their react templates. Not that disabled is boolean and can be written better.
  - mattwad 4y ago
    Trying to be fair here, but what about vue makes it less likely that you won't put the same conditional logic into your vue template? If it's just impossible, then you're saying the framework is more limited, which is fine but sometimes you want flexibility. This seems to be a 'best practice' issue as well that can be avoided through PR review. My team has been putting logic more and more into local hook files to keep components clean.
    - philliphaydon 4y ago
      There's nothing inherently stopping people from writing clean react projects. But I've never seen one. But watching people fumble around trying to find where they need to make a change when things are so overly abstracted, and STILL try to justify that react is good, is baffling. People break tables up into ~50+ files. It's crazy, and everyone does this, and its an absolute nightmare to maintain. Its 100% engrained into react culture that this is the right path forward. React will never get better if people accept over abstraction as the right path forward.
      - hirvi74 4y ago
        So, I have not used React more than a tutorial here and there. Same with any of the other SPA libraries. I do not understand why everything needs to be a single page application. Sure, my current employer is behind the times in the technology we use, but honestly, we survive just fine with server side rendering and plain, ol'boring, vanilla Javascript and a little JQuery here and there. Of course, some things we have written are difficult to maintain at times, but I doubt any other library would have really made it simpler (more of an issue with the requirements than the technology). Abstraction is simple, for us at least.
- YPCrumble 4y ago
  Incredibly this is more readable than the Vue example given as a reason why Vue’s syntax is better!
  - jaywalk 4y ago
    How so? I don't use Vue or React, but I don't see any real difference in readability between the two examples. They're both very straightforward.
  - edgyquant 4y ago
    The fact is that Vue enforces this and react doesn’t. So most devs do not write things this nicely
MrJohz 4y ago
> JSX forces you into small tiny components I'm surprised you see that as a disadvantage, for me that's always the biggest advantage of JSX-style syntax! I don't want huge components that do everything, I want components to do as little as necessary to be actually useful. It's the same as if I were writing functions: keep them fairly small, make sure they're doing a specific thing usefully, and then compose them together like Lego bricks. When I was doing more Vue work, this is one of the things that I struggled the most with, that splitting one component into two components required a load of boilerplate and a whole new file. (And that itself was a big improvement on Angular, which usually had multiple files doing different things, at least when I was last using it). This inevitably meant that I'd try and fit more and more stuff into a single component until it the pain of maintaining it was greater than the pain of splitting it. (At which point it would usually be a lot harder to extract the would-be child component than it needed to be, because I'd left it too long.) I think the rest is mostly just syntax preferences. Like you say, you can write bad code in both cases, and I think a lot of it comes down to which matches better to your mental model if what HTML generation looks like. But being able to easily start a new component, just like starting a new function, is such an important benefit of JSX, for me at least.
- edgyquant 4y ago
  I also love small and well thought components. But as an engineering lead and manager it’s a lot of effort wrangling devs to do so. They always start small and then overtime converge on multiple return statements full of huge amounts of inline JS.
  - MrJohz 4y ago
    I've been enjoying SolidJS recently, and due to framework limitations, it is generally impossible to have multiple return statements, which I think helps a bit here. The signals stuff also lends itself really well to writing code that operates only on state, and then plugging it into a thinner, dumber DOM layer, so it's easier to compose pieces together. It's like hooks or the Vue composition API, but moreso? It's difficult to describe. That said, SolidJS as a whole requires a completely different mental model of rendering, even if it does look superficially similar to React. It's also a much smaller ecosystem, with less documentation, so getting to grips with it is that much harder. Very rewarding, but probably not ideal for everyone right now.

azangru 4y ago

> return <button disabled="disabled">Submit</button>; In JSX, the "disabled" attribute is a boolean; so it would be just: return <button disabled={!isFormValid}>Submit</button>;

philliphaydon 4y ago
> This is just an example, obviously you can write this better in React. The issue is people write SO much conditional logic into their react templates. Not that disabled is boolean and can be written better.
- mattwad 4y ago
  Trying to be fair here, but what about vue makes it less likely that you won't put the same conditional logic into your vue template? If it's just impossible, then you're saying the framework is more limited, which is fine but sometimes you want flexibility. This seems to be a 'best practice' issue as well that can be avoided through PR review. My team has been putting logic more and more into local hook files to keep components clean.
  - philliphaydon 4y ago
    There's nothing inherently stopping people from writing clean react projects. But I've never seen one. But watching people fumble around trying to find where they need to make a change when things are so overly abstracted, and STILL try to justify that react is good, is baffling. People break tables up into ~50+ files. It's crazy, and everyone does this, and its an absolute nightmare to maintain. Its 100% engrained into react culture that this is the right path forward. React will never get better if people accept over abstraction as the right path forward.
    - hirvi74 4y ago
      So, I have not used React more than a tutorial here and there. Same with any of the other SPA libraries. I do not understand why everything needs to be a single page application. Sure, my current employer is behind the times in the technology we use, but honestly, we survive just fine with server side rendering and plain, ol'boring, vanilla Javascript and a little JQuery here and there. Of course, some things we have written are difficult to maintain at times, but I doubt any other library would have really made it simpler (more of an issue with the requirements than the technology). Abstraction is simple, for us at least.
YPCrumble 4y ago
Incredibly this is more readable than the Vue example given as a reason why Vue’s syntax is better!
- jaywalk 4y ago
  How so? I don't use Vue or React, but I don't see any real difference in readability between the two examples. They're both very straightforward.
- edgyquant 4y ago
  The fact is that Vue enforces this and react doesn’t. So most devs do not write things this nicely

MrJohz 4y ago

> JSX forces you into small tiny components I'm surprised you see that as a disadvantage, for me that's always the biggest advantage of JSX-style syntax! I don't want huge components that do everything, I want components to do as little as necessary to be actually useful. It's the same as if I were writing functions: keep them fairly small, make sure they're doing a specific thing usefully, and then compose them together like Lego bricks. When I was doing more Vue work, this is one of the things that I struggled the most with, that splitting one component into two components required a load of boilerplate and a whole new file. (And that itself was a big improvement on Angular, which usually had multiple files doing different things, at least when I was last using it). This inevitably meant that I'd try and fit more and more stuff into a single component until it the pain of maintaining it was greater than the pain of splitting it. (At which point it would usually be a lot harder to extract the would-be child component than it needed to be, because I'd left it too long.) I think the rest is mostly just syntax preferences. Like you say, you can write bad code in both cases, and I think a lot of it comes down to which matches better to your mental model if what HTML generation looks like. But being able to easily start a new component, just like starting a new function, is such an important benefit of JSX, for me at least.

edgyquant 4y ago
I also love small and well thought components. But as an engineering lead and manager it’s a lot of effort wrangling devs to do so. They always start small and then overtime converge on multiple return statements full of huge amounts of inline JS.
- MrJohz 4y ago
  I've been enjoying SolidJS recently, and due to framework limitations, it is generally impossible to have multiple return statements, which I think helps a bit here. The signals stuff also lends itself really well to writing code that operates only on state, and then plugging it into a thinner, dumber DOM layer, so it's easier to compose pieces together. It's like hooks or the Vue composition API, but moreso? It's difficult to describe. That said, SolidJS as a whole requires a completely different mental model of rendering, even if it does look superficially similar to React. It's also a much smaller ecosystem, with less documentation, so getting to grips with it is that much harder. Very rewarding, but probably not ideal for everyone right now.