Discussion on: 30 JavaScript Tricky Hacks

[Ben Sinclair]

If the premise is to "help you optimize your code, make it more readable, and save you time", then I'd steer clear of some of these.

Using !! to convert to boolean

This is probably less readable, especially for people new to Javascript. There's nothing wrong with using a truthy value directly or casting things explicilty.

"short-circuit" evaluation

Again, there's nothing wrong with using more characters to make things easier to read, and in fact there are good reasons to keep separate things on separate lines (like always using a block for if).

Using ^ for Swapping Values

This hasn't been useful for at least 30 years unless you're trying to impress someone in a coding interview. It's not readable, and it doesn't save any time or effort.

Converting to Numbers with Unary Plus

Same deal as before. Be explicit.

[João Filipe Ventura Coelho]

Was about to comment the exact same thing

[M Mainul Hasan]

Thank you for taking the time to share your excellent thoughts. I truly appreciate your perspective and understand the concerns about readability, particularly for those new to JavaScript.

The intention behind showcasing these techniques, such as using !! to force a boolean context or the unary + for type conversion, was to present a spectrum of approaches that developers might encounter in practice or find useful in specific scenarios.

It’s a valid point that explicit casting and traditional methods can enhance clarity, especially for less experienced developers. The utility of these tips often depends on the context in which they’re used and the audience interpreting the code.

Regarding the bitwise XOR for value swapping, I agree that it’s not a common practice in every day coding. It’s indeed more of a fun trick that could be useful to understand when reading legacy code or preparing for interviews, as you mentioned.

Ultimately, the goal is to inspire developers to think critically about the tools at their disposal and to choose the best tool for the task, balancing efficiency and readability.

Thanks again for providing friendly suggestions and feedback.

[iakovosvo]

Regarding the use of !!, I find Boolean(isThisAtruthyValue) to be more expressive and easier to read.

[M Mainul Hasan]

Absolutely, using Boolean(isThisTruthyValue) is indeed more expressive and can be clearer to read, especially for those who are not as familiar with the nuances of JavaScript’s type coercion. It’s great that you’ve highlighted an alternative that prioritizes readability and self-documenting code.

The choice between !! and Boolean() often comes down to personal or team preference, and the context in which the code will be read and maintained. I appreciate you bringing this up — it’s always beneficial for developers to be aware of different options that can make their intent more explicit.

Thank you for adding to the conversation with your insightful suggestion!

[Charles F. Munat]

True. And the way to convert to Boolean is Boolean(value).

[Sean Dinan]

As a counter-point for short circuit evaluation, I've mostly switched over to it for conditionally rendering things in JSX. I stuck to ternary for years but have gradually switched over.

I'd now say that:

return (
  <section>
    {isLoading && <LoadingMessage/>}
    {/* ... */}
  </section>
)

is at least as clear as:

return (
  <section>
    {isLoading ? <LoadingMessage/> : null}
    {/* ... */}
  </section>
)

[Ben Sinclair]

I agree, for things like JSX (which still look uncomfortable to me even after a few years) it is still readable - provided you keep things simple.