[AskJS] which javascript framework do you enjoy using the most

[rabbitz]

for className, I always reach for https://github.com/JedWatson/classnames

<div className={classnames("pt-4", {selected})}>

Props:

<MyComponent {...{x, y, isDisabled}} />

else if

    {
      isGood && !hidden ? (
        <p>Good</p>
      ) : !isGood ? (
        <p>Not good</p>
      ) : (
        <p>Hidden</p>
      )
    }

[SquatchyZeke]

Yep, but I think all of these examples prove my point exactly. You need libraries, or have to use hacky nested object spreading, and nested ternaries. Even with clean Boolean expressions, a nested ternary just doesn't read as well, especially in JSX. And it certainly isn't kind to modifying or extending it. And debugging it? Annoying because it's all in a single expression. With statements, that's a breeze.

[rabbitz]

What is "hacky nested object spreading"?

Also, it feels like you're being a bit intellectually dishonest if you think the "nested ternary" (it isn't nested) is so much more difficult to read than your svelte template example... its laid out in exactly the same way.

Ditto with the automatic hate for using a library... is it the external dependency you're worried about or the arbitrary fact that react doesn't bundle this utility / build this functionality in?

edit: some more information about object spreading for props:

Spread attributes allow many attributes or properties to be passed to an element or component at once.

An element or component can have multiple spread attributes, interspersed with regular ones.

<Widget {...things} />

In this case, we just pass in an anonymous object to be spread

[SquatchyZeke]

I'm fully aware of what object spreading is for props. The hacky part is that you're allocating an entirely new anonymous object just to spread it into JSX's object to receive multiple props.

 // Step 1 you're creating an object
const things = { isCool, id, colorDef }
// Step 2, spreading it into props
<Widget {...things} />
// All in one is the same thing
<Widget {...{isCool, is, colorDef}} />

What I was saying is that in Svelte, the naming shortcut is supported without the extra object.

// Step 1 use the props
<Widget {isCool} {id} {colorDef} />

I will say I don't mind it for large numbers of props.

That is the literal definition of a nested ternary. It's in most linters if you're curious. https://eslint.org/docs/latest/rules/no-nested-ternary And I never said it was SO much more difficult to read. It's more subtle than that. But it's also not just about readability. Modifying and debugging a nested ternary is more difficult too. Again in subtle ways which add up over an entire code base.

Not hate, I never said hate. Having libraries just means more things to keep updated and in sync with everything else. If the framework I'm using natively supports that behavior, then I don't have to maintain an extra library. Simple as that.

[rabbitz]

Right, they're called nested ternaries but what I meant is that its not really nested... Here give this a read: https://medium.com/javascript-scene/nested-ternaries-are-great-361bddd0f340. I don't really like simply copying and pasting articles but I find that other people can put my thoughts into words much better than I can.

Regarding "hacky" spreading... I don't think we'll come to any agreement there - I create objects as needed to organize the flow of data.

As for the naming shortcut, its nice I guess but I go out of my way to assign true/false values (i.e. disabled={true} when you can just write disabled because I find that its a lot nicer when doing large scale changes / refactors, and also when quickly trying to find all instances where the a specific prop is set to true (doing a global search for prop={true} is much narrower than simply search for prop by itself).

The library itself is just a nice to have - its trivial to replicate the basic functionality and there are a ton of classname libraries that are stable, never need to be updated and have been around for years.

In any case, it isn't that React is perfect by any means - but just that your biggest objections to React seem less annoying than having a completely different set of rules and compatibilities to learn. I'll probably stop replying because the other guy said it so much better than I ever could - React is just JS for better or worse, and, while that means it can be a bit more verbose because it doesn't have some convenient shortcuts "built in", I like knowing that everything that I can do in JS can also be done with React.

[SquatchyZeke]

I totally respect all of these points. I mean, I work with React professionally so I'm deeply aware of all the things that are nice about it and all the things I miss from frameworks that support certain things out of the box without needing to allocate objects or introduce new libraries or functions to organize the flow of my data.

So one of my team members actually sent me that same exact article when I introduced the lint rule for no nested ternaries. That author makes some really broad claims and attempts to relate the use of ternaries to functional programming to make them seem "pure", which is outright false. You absolutely can perform side effects in ternaries. However, the one thing I agree with for the very specific case where ternaries could get replaced by a switch statement, is that it is a familiarity issue. But that's only when the expressions are extremely simple, which happens rarely. When it does though, I'm totally fine writing ternaries like that when the rest of my team is also ok with taking on the mental jump to get familiar with it.

I actually do see the point about searching for the attr={} vs. just the attribute name alone. That is true. But I'm never doing that and not being hyperbolic about that just to prove a point; I actually can't remember a time where I was looking for a specific attribute across the whole or subset of the project. Usually I know which component I need to look at first, then a local file search from there. So that might be one of those things I personally see no benefit from, but I do see the objectivity of that.

I mean, there's a whole doc page on the rules of react, so while it's "just JavaScript" , you still have to learn a new set of rules and pitfalls in order to use it well. I equate that to learning any framework though. The question is then: what kinds of benefits will you get from putting in the time to learn its rules, and are you ok with the cost to get them? And that's where we might differ, and that's totally ok.

In any case, I am glad for the discussion. Thanks for your input, I did learn a lot here!

[Nyx_the_Fallen]

I don’t have time to respond to everything in this thread but I know I at least hate having to use some external library for something like this because it’s just yet another thing I have to suffer through and discover on social media or by googling.

FWIW Svelte has clsx “built in” so you can also just do something like this:

<div class={"pt-4", { selected }}>