3 ms·

I'm on the opposite side. I think JSX is a horror show. We've been trying to remove view from logic since the 90s, and move towards declarative views with data

by keyle 6y ago

I'm on the opposite side. I think JSX is a horror show. We've been trying to remove view from logic since the 90s, and move towards declarative views with data binding. Keep your nook and crannies away from the presentation layer. But all the industry wants is shoving PHP in the browser. I think it's sad. We're making the UI layer always more complicated. Let's say your UI changes, like a redesign... you can rewrite your component and probably need to change most of them. If your UI was just dumb and declarative and the data was salt on top, changing the UI is trivial. The UI should declare what the UI should look like, not describe how it should do it. This is why, as an old timer, I much prefer the direction VueJS took. Edit: great lib though, anything small is a win.

postalrat 6y ago
Till you want to render a list or something. Then your vue template starts looking a lot more like javascript.
- keyle 6y ago
  That's plain wrong, it's still all inline with the markup, and more importantly, it doesn't reveal any of the inner working of the list.
daveidol 6y ago
People always talk about separation of HTML and JS is a separation of concerns, but it's really not in my experience. It's separation of technologies. The JS has to grab DOM nodes by class or ID and is highly coupled to its structure anyway, so putting them together (as React does) seems far more logical in my opinion. Separating them into files and using string classes to look them up is far less easier to read and leads to runtime issues (since a typo isn't actually a code error but just silently doesn't work). JSX is really not like PHP at all. PHP just writes out strings - JSX is all JavaScript objects. What you are describing is more akin to something like Handlebars or Angular templates. Plus, JSX is just sugar and is not required to use React if you prefer something like hyperscript (no compile step needed in that case).
- keyle 6y ago
  Fair enough, my PHP in the browser line is a knee jerk comment which is extending its welcome. My point mostly was: separate view from logic. Intertwining them only makes maintainability and cognitive juggling worse.
bern4444 6y ago
> Let's say your UI changes, like a redesign... you can rewrite your component and probably need to change most of them. This is exactly what React does especially for stateless components that purely consume data. The component declartively says this is the data I need. The component doesn't care how that data is retrieved, that's an implementation detail separate from React. For stateful components, this is also achievable but requires a little engineering and some good architecture (this is IMO the hardest part of 'React' - and this isn't even a concern of React - since React doesn't prescribe any specific approach). If you define all the functionality for a component well, you should be able to easily rewrite just the view (the return value of a fucntional component or of the render method for class components) without changing any of the existing functionality. This can be done by defining your component's behaviors via hooks (custom or builtin). Those hooks should provide any functionality and data your view needs and exposes that to the component. If no new data or functionality is needed, then nothing in these hooks (and more broadly code external to the render/return value) changes. All that changes is the return value of your component and any css you want. If you change the view, yeah you might have to update some event handlers for buttons that are now inputs, but that's not a UI only change, thats changing functionality too.
eyelidlessness 6y ago
JSX is entirely about removing view from logic. Templates/render pipelines all have their own logic depending on the data available to them. That’s all JSX does. The benefit of JSX vs the other solutions in its space is that it’s a data structure and it’s render-target agnostic, as well as rendering engine agnostic (so you can render the same structure to different outputs or in different ways for the same output).
dceddia 6y ago
I felt this way when I first saw React and JSX a few years ago. Mixing concerns seemed like a terrible idea that would lead to ruin. And then I tried it, and realized it’s wonderful actually - that most of the time, when I changed some HTML, I had to update the corresponding JS anyway, and usually in a separate file (which at the time was jQuery or Angular 1). React put those things in one place, and writing components felt like writing functions. The worst PHP code I’ve seen is the kind that mixed database queries with presentation, and that was just bonkers. Just a really truly awful mess. For me, that was the “PHP” I envisioned and what I didn’t want to rehash with React, and I can confidently say that has worked out pretty well.

by keyle 6y ago

postalrat 6y ago

Till you want to render a list or something. Then your vue template starts looking a lot more like javascript.

keyle 6y ago
That's plain wrong, it's still all inline with the markup, and more importantly, it doesn't reveal any of the inner working of the list.

daveidol 6y ago

People always talk about separation of HTML and JS is a separation of concerns, but it's really not in my experience. It's separation of technologies. The JS has to grab DOM nodes by class or ID and is highly coupled to its structure anyway, so putting them together (as React does) seems far more logical in my opinion. Separating them into files and using string classes to look them up is far less easier to read and leads to runtime issues (since a typo isn't actually a code error but just silently doesn't work). JSX is really not like PHP at all. PHP just writes out strings - JSX is all JavaScript objects. What you are describing is more akin to something like Handlebars or Angular templates. Plus, JSX is just sugar and is not required to use React if you prefer something like hyperscript (no compile step needed in that case).

keyle 6y ago
Fair enough, my PHP in the browser line is a knee jerk comment which is extending its welcome. My point mostly was: separate view from logic. Intertwining them only makes maintainability and cognitive juggling worse.

bern4444 6y ago

> Let's say your UI changes, like a redesign... you can rewrite your component and probably need to change most of them. This is exactly what React does especially for stateless components that purely consume data. The component declartively says this is the data I need. The component doesn't care how that data is retrieved, that's an implementation detail separate from React. For stateful components, this is also achievable but requires a little engineering and some good architecture (this is IMO the hardest part of 'React' - and this isn't even a concern of React - since React doesn't prescribe any specific approach). If you define all the functionality for a component well, you should be able to easily rewrite just the view (the return value of a fucntional component or of the render method for class components) without changing any of the existing functionality. This can be done by defining your component's behaviors via hooks (custom or builtin). Those hooks should provide any functionality and data your view needs and exposes that to the component. If no new data or functionality is needed, then nothing in these hooks (and more broadly code external to the render/return value) changes. All that changes is the return value of your component and any css you want. If you change the view, yeah you might have to update some event handlers for buttons that are now inputs, but that's not a UI only change, thats changing functionality too.

eyelidlessness 6y ago

JSX is entirely about removing view from logic. Templates/render pipelines all have their own logic depending on the data available to them. That’s all JSX does. The benefit of JSX vs the other solutions in its space is that it’s a data structure and it’s render-target agnostic, as well as rendering engine agnostic (so you can render the same structure to different outputs or in different ways for the same output).

dceddia 6y ago

I felt this way when I first saw React and JSX a few years ago. Mixing concerns seemed like a terrible idea that would lead to ruin. And then I tried it, and realized it’s wonderful actually - that most of the time, when I changed some HTML, I had to update the corresponding JS anyway, and usually in a separate file (which at the time was jQuery or Angular 1). React put those things in one place, and writing components felt like writing functions. The worst PHP code I’ve seen is the kind that mixed database queries with presentation, and that was just bonkers. Just a really truly awful mess. For me, that was the “PHP” I envisioned and what I didn’t want to rehash with React, and I can confidently say that has worked out pretty well.