4 ms·

I seriously cannot wrap around my head how in 2022 people really like JSX and all that X-in-JS crap, it's like people doesn't know about separation of concerns

I seriously cannot wrap around my head how in 2022 people really like JSX and all that X-in-JS crap, it's like people doesn't know about separation of concerns or clean code at all.

AgentME 4y ago
For almost anything more interactive than a static document, modularizing UI code primarily based on component boundaries makes a lot more sense than modularizing primarily based on markup / interactivity / styling boundaries.
- qbasic_forever 4y ago
  Exactly, it comes from a bygone era when there was a clear separation between frontend developers (i.e. people that wrote markup, CSS, and jquery style JS) and backend developers (people that wrote PHP, ASP, java, etc. to spit out markup that frontend devs wrote). Nowadays everyone is basically full stack with specializations or focus in specific parts.
root_axis 4y ago
There are quite a few motivations for this, but the primary advantage is that it causes markup elements to become first-class entities within your code, allowing your view composition to be checked by the compiler as well as allowing you to design your own reusable markup elements that fold up application level concerns. It's also nice when your views have lexical access to your application state variables so you don't have to pre-render a big string template and interlace it with an explicit map of serialized parameters - it's very nice when the compiler lets you know a view simply cannot display the type of data you're trying to shove into it rather than rendering a broken looking page.
gherkinnn 4y ago
Separating which concerns?
- richeyryan 4y ago
  I guess software is like your cutlery drawer. You want to keep your knives, forks and spoons separate.
  - gherkinnn 4y ago
    True. I like keeping my knives, forks, and spoons separate. Alternatively, try organising your cutlery by "implement" and "handle". Surely, separating what goes in your mouth from what your grubby hands touch is the right thing to do. The two concerns that should be kept separate! To push this analogy over the edge, the former is how I see JSX. And my admittedly facetious proposal is how I view the "classical" approach of strict HTML|CSS|JS separation. Which poses the question: after seven+ years of JSX and it having become the most prominent approach to building UIs, can the "classical"way even be called that anymore?
n3pg 4y ago
Seperation of languages != seperation of concerns One could argue the adoption of JSX actually allows for better seperation and cleaner code as you can group all the necessary pieces of your component together, and use components declaratively without introducing some DSL seen in some frameworks like Vue, Angular etc.
- verdverm 4y ago
  Isn't className custom DSL in React? Vue's concepts in the v-* are more pleasant than the React way, imho. Learning a bit of DAL is not a blocker for me, given how many tools already require this
  - hunterb123 4y ago
    I'd rather just use JS syntax than learn a random v-* syntax. You can just use the std lib to loop, filter, reduce, conditionally render, etc. rather than looking up how to loop in this specific framework with v-if, v-for, etc. Angular 1 did that and it was limiting. Two-way data binding also failed. Templates are dead, long live JSX.
    - yurishimo 4y ago
      Vue doesn’t do two way data binding. Are you more likely to use it knowing that?
      - hunterb123 4y ago
        The data binding was a comment for React and against Angular and similar frameworks. The template syntax was a comment against Vue. And no I'm not interested in Vue due to many reasons. I can expand if you're interested. But why would you switch to copy cat frameworks when you have React and React Native? My main point was for JS DSL and against proprietary template syntax, what are your thoughts on that specifically?
        4y ago
rglover 4y ago
There's hope: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.

I seriously cannot wrap around my head how in 2022 people really like JSX and all that X-in-JS crap, it's like people doesn't know about separation of concerns or clean code at all.

AgentME 4y ago

For almost anything more interactive than a static document, modularizing UI code primarily based on component boundaries makes a lot more sense than modularizing primarily based on markup / interactivity / styling boundaries.

qbasic_forever 4y ago
Exactly, it comes from a bygone era when there was a clear separation between frontend developers (i.e. people that wrote markup, CSS, and jquery style JS) and backend developers (people that wrote PHP, ASP, java, etc. to spit out markup that frontend devs wrote). Nowadays everyone is basically full stack with specializations or focus in specific parts.

root_axis 4y ago

There are quite a few motivations for this, but the primary advantage is that it causes markup elements to become first-class entities within your code, allowing your view composition to be checked by the compiler as well as allowing you to design your own reusable markup elements that fold up application level concerns. It's also nice when your views have lexical access to your application state variables so you don't have to pre-render a big string template and interlace it with an explicit map of serialized parameters - it's very nice when the compiler lets you know a view simply cannot display the type of data you're trying to shove into it rather than rendering a broken looking page.

gherkinnn 4y ago

Separating which concerns?

richeyryan 4y ago
I guess software is like your cutlery drawer. You want to keep your knives, forks and spoons separate.
- gherkinnn 4y ago
  True. I like keeping my knives, forks, and spoons separate. Alternatively, try organising your cutlery by "implement" and "handle". Surely, separating what goes in your mouth from what your grubby hands touch is the right thing to do. The two concerns that should be kept separate! To push this analogy over the edge, the former is how I see JSX. And my admittedly facetious proposal is how I view the "classical" approach of strict HTML|CSS|JS separation. Which poses the question: after seven+ years of JSX and it having become the most prominent approach to building UIs, can the "classical"way even be called that anymore?

n3pg 4y ago

Seperation of languages != seperation of concerns One could argue the adoption of JSX actually allows for better seperation and cleaner code as you can group all the necessary pieces of your component together, and use components declaratively without introducing some DSL seen in some frameworks like Vue, Angular etc.

verdverm 4y ago
Isn't className custom DSL in React? Vue's concepts in the v-* are more pleasant than the React way, imho. Learning a bit of DAL is not a blocker for me, given how many tools already require this
- hunterb123 4y ago
  I'd rather just use JS syntax than learn a random v-* syntax. You can just use the std lib to loop, filter, reduce, conditionally render, etc. rather than looking up how to loop in this specific framework with v-if, v-for, etc. Angular 1 did that and it was limiting. Two-way data binding also failed. Templates are dead, long live JSX.
  - yurishimo 4y ago
    Vue doesn’t do two way data binding. Are you more likely to use it knowing that?
    - hunterb123 4y ago
      The data binding was a comment for React and against Angular and similar frameworks. The template syntax was a comment against Vue. And no I'm not interested in Vue due to many reasons. I can expand if you're interested. But why would you switch to copy cat frameworks when you have React and React Native? My main point was for JS DSL and against proprietary template syntax, what are your thoughts on that specifically?
      - 4y ago

rglover 4y ago

There's hope: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.