3 ms·

> "fuck it, everything is javascript" is react's great insight, for interactive applications. I'd argue that jsx was react's great insight. But maybe that's t

> "fuck it, everything is javascript" is react's great insight, for interactive applications. I'd argue that jsx was react's great insight. But maybe that's the same thing. Anyway yes. But unfortunately, you can't use react without using the rest of its insights, such as all data must be immutable, and DOM updates are based on reconciliation. > The frontend ecosystem overall, i find very exhausting, yes. but that's not on react. That's true. React has more than enough of its own problems though.

elif 2y ago
jsx is handy but clearly react's 'great insight' if it were to be so reduced, is implicit state management.
- recursive 2y ago
  If by implicit state management, you're including the abomination that is `useState`, I could not possibly disagree any harder.
mewpmewp2 2y ago
I despise JSX as well. Simply because no one is able to handle if else and conditionals in a readable non spaghetti way. Every time I see {condition && <Component />} or {condition ? <ThisComponent /> : <ThatComponent />} I die a little bit inside. In addition to that people to get around these things will do helper functions within the component itself e.g. {renderSomething()} This ends up inside of the component being really unreadable and spaghetti where you have to jump up and down everywhere. I prefer VueJS or Svelte much more, but unfortunately due to its popularity I am stuck with React.
- recursive 2y ago
  Yes. And .map(). And the tag closing semantics are slightly different from HTML. And approximately no one understands how HTML tag closing works anymore because of it.
- apsurd 2y ago
  It's true, components can get unwieldy. That's the feature aspect of components built with a full programming language (js). In contrast, I can't understand how magic attributes on html nodes is more clear. What's your take on that? For example in Vue's introduction: <div id="app"> <button @click="count++"> Count is: {{ count }} </button> </div> The completely made up "@click" makes no sense outside of Vue. "count++" is a string that stands for real programming code? So we're making up pseudo code now. And the {{}} interpolation isn't real either, so it's not actually an HTML <template> Using native HTML nodes, templates, and tags makes it seem standard. This is the worst learning curve: the bait and switch vs being clear—albeit intense—that the component is 100% a JS programming env that yields the UI. React component is not the UI it's a JS function that yields the UI.
  - mewpmewp2 2y ago
    Despite Vue having this separate template syntax it felt very easy to learn and natural as opposed to the boilerplate that you get with React. It is not like JSX is understandable out of the gate if you know JS. I have done html templating syntax in many different languages and frameworks starting with Laravel Blade and it always felt much better than the native syntax of doing that e.g. with PHP. I don't think it ks a worthwhile feature to have everything strictly JS. Use different tools as they are appropriate, why hinder yourself. Ultimately there are some very frequent and limited patterns in defining interactive html elements so best to use the syntax that has the highest meaning to noise ratio. The combination of useState, stateValue, setStateValue are simply unnecessary boilerplate that makes important things like the state variable itself hidden in a sea of noise. > React component is not the UI it's a JS function that yields the UI I don't think that is a good philosophy at all. The code should be about clarity not around an odd dogma about having to be a JS function that yields the UI. It in my view is a misplaced enthusiasm for something that really doesn't matter, but will hinder things since you have to constantly work and hack around those self posed arbitrary restrictions.
    - apsurd 2y ago
      JS function that yields the UI is not about dogma or JS enthusiasm, to be clear, I would prefer NOT to use JS. And I concede that frontend ecosystem really seems to see "everything in one language" as some kind of benefit and virtue. It's not! The "everything is JS" and "JS yields the UI" is 100% based on the constraints of the runtime. Modern UIs need browser APIs, events, DOM management, and stying. We MUST use HTML/CSS/JS. My take is "everything in JS" _in this context_ is more reasonable, more integrated, and ultimately more intuitive, not that it's simple or easy, but that we're stuck with the runtime, we're going to need these all to integrate with one another, let's be clear on in the integration interfaces.

elif 2y ago

jsx is handy but clearly react's 'great insight' if it were to be so reduced, is implicit state management.

recursive 2y ago
If by implicit state management, you're including the abomination that is `useState`, I could not possibly disagree any harder.

mewpmewp2 2y ago

I despise JSX as well. Simply because no one is able to handle if else and conditionals in a readable non spaghetti way. Every time I see {condition && <Component />} or {condition ? <ThisComponent /> : <ThatComponent />} I die a little bit inside. In addition to that people to get around these things will do helper functions within the component itself e.g. {renderSomething()} This ends up inside of the component being really unreadable and spaghetti where you have to jump up and down everywhere. I prefer VueJS or Svelte much more, but unfortunately due to its popularity I am stuck with React.

recursive 2y ago
Yes. And .map(). And the tag closing semantics are slightly different from HTML. And approximately no one understands how HTML tag closing works anymore because of it.
apsurd 2y ago
It's true, components can get unwieldy. That's the feature aspect of components built with a full programming language (js). In contrast, I can't understand how magic attributes on html nodes is more clear. What's your take on that? For example in Vue's introduction: <div id="app"> <button @click="count++"> Count is: {{ count }} </button> </div> The completely made up "@click" makes no sense outside of Vue. "count++" is a string that stands for real programming code? So we're making up pseudo code now. And the {{}} interpolation isn't real either, so it's not actually an HTML <template> Using native HTML nodes, templates, and tags makes it seem standard. This is the worst learning curve: the bait and switch vs being clear—albeit intense—that the component is 100% a JS programming env that yields the UI. React component is not the UI it's a JS function that yields the UI.
- mewpmewp2 2y ago
  Despite Vue having this separate template syntax it felt very easy to learn and natural as opposed to the boilerplate that you get with React. It is not like JSX is understandable out of the gate if you know JS. I have done html templating syntax in many different languages and frameworks starting with Laravel Blade and it always felt much better than the native syntax of doing that e.g. with PHP. I don't think it ks a worthwhile feature to have everything strictly JS. Use different tools as they are appropriate, why hinder yourself. Ultimately there are some very frequent and limited patterns in defining interactive html elements so best to use the syntax that has the highest meaning to noise ratio. The combination of useState, stateValue, setStateValue are simply unnecessary boilerplate that makes important things like the state variable itself hidden in a sea of noise. > React component is not the UI it's a JS function that yields the UI I don't think that is a good philosophy at all. The code should be about clarity not around an odd dogma about having to be a JS function that yields the UI. It in my view is a misplaced enthusiasm for something that really doesn't matter, but will hinder things since you have to constantly work and hack around those self posed arbitrary restrictions.
  - apsurd 2y ago
    JS function that yields the UI is not about dogma or JS enthusiasm, to be clear, I would prefer NOT to use JS. And I concede that frontend ecosystem really seems to see "everything in one language" as some kind of benefit and virtue. It's not! The "everything is JS" and "JS yields the UI" is 100% based on the constraints of the runtime. Modern UIs need browser APIs, events, DOM management, and stying. We MUST use HTML/CSS/JS. My take is "everything in JS" _in this context_ is more reasonable, more integrated, and ultimately more intuitive, not that it's simple or easy, but that we're stuck with the runtime, we're going to need these all to integrate with one another, let's be clear on in the integration interfaces.