3 ms·
why do you hate it? i loved react when it came out, it was magnitude improvement for rapid prototyping. jsx as an idea seems ridiculous, but in practice, might
by apsurd 2y ago
why do you hate it?
i loved react when it came out, it was magnitude improvement for rapid prototyping. jsx as an idea seems ridiculous, but in practice, might as well make everything js and use the programming language's full power—otherwise you get pseudo-code-in-html. html directives will never be a full programming language, I can't understand why frameworks go down this path, repeatedly!
"fuck it, everything is javascript" is react's great insight, for interactive applications.
The frontend ecosystem overall, i find very exhausting, yes. but that's not on react.
What don't you like about it?
- recursive 2y ago> "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 agojsx is handy but clearly react's 'great insight' if it were to be so reduced, is implicit state management.
- recursive 2y agoIf by implicit state management, you're including the abomination that is `useState`, I could not possibly disagree any harder.
- mewpmewp2 2y agoI 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 agoYes. 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 agoIt'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 agoDespite 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.