JavaScript Through Ruby Eyes

JavaScript through Ruby Eyes

Thoughts of Clarity from Lessons Learned in Ruby

JavaScript Through Ruby Eyes

JavaScript is evolving,and we love it… though, there’s something fundamental that needs to be said. Ruby and JavaScript devs can argue all day, but at the end of the day, there are self-evident truths that must be reckoned.

Hold your haunches JavaScript devs, I’m going to say something: Ruby is the most beautiful language I’ve ever used. I say “used” because we’ve all seen elegant snippets for specific situations in other languages. Ruby fundamentally got things right in the real world projects. Think about it, a programming language from Japan revolutionized the English-based domain.

Now, JavaScript is back! Node.js jobs are climbing! React Native rocks!

As JavaScript evolves, will it be so proud that it will discard the wisdom and elegance of a language that was King? What can JavaScript learn from Ruby?

Connotation & Denotation

What does the symbol # denote to you?Is it a phone’s pound sign? Or a number sign? Or commented out bash command? Or a Twitter/Facebook hashtag!? Depending on your age and experience, this symbol can be called and have meaning for a variety of things. This denotation has ambiguous connotation, but fortunately the context in which it’s used ( e.g. Online, in a phone number, in a .zshrc ) can usually give us a safe definition and monicker for the symbol.

When there are multiple connotations for each denotation, the context becomes a critical factor. Since the definition is dependent on an external context, our functionality becomes arguably impure. ( Functional programmers feel free to squirm)

Now let’s look at JavaScript with the latest hotness, ES2015 and React JS. What does {} mean? Take a moment, and really think about this.

Unfortunately, the context clues are needed… a lot. This is another context-dependent situation. In JavaScript, {} indicates an object literal AND could be opening/closing a block. Compound this with ES2015, where it is used to de-structure an object. Lastly, add JSX so that the symbol means to denote embedded JavaScript!

That’s 4 different uses for the same symbol. Did I miss any? JavaScript continues to pay homage to traditional ALGOL-like syntax from the technology of the 60s rather than recent readability advances. It’s arguable that Object Oriented centrism justifies their reuse, but this symbol madness is generally reserved for advanced regular expressions. I find myself fixing this often in a junior developer’s code. It’s not that we’re lacking new possible symbols; we’re lacking the alarm bells to say that this is a bad idea.

One could argue that ES2015 shouldn’t care about JSX, but fundamentally differing actions, like spread operators and rest parameters, both new ES2015 concepts, should not share syntax. Enforce clarity and readability with growth.

JavaScript Through Ruby Eyes
Takeaway: Aim for one connotation for each denotation when talking to computers

Seattle Style Ruby

You may have heard of Seattle Style Ruby, which is an arguable topic amongst Ruby developers. But ultimately, the concept that birthed Seattle Style is timeless. Jim Weirich (Big Jim), the creator of Rake, blogged about writing a script to remove all alphanumeric characters from Ruby file to leave behind extraneous characters that MUST contribute to the semantic meaning of the code. Thus Seattle Style ruby was born as a style geared towards the minimization of noise in code, by minimizing these semantic characters.

Source Ryan Davis, RubyConf 2015

With ASI (Automatic Semicolon Insertion) we get a taste of this clarity, which in turn leads to movements and standards . As ES2016 and ES2017 become evaluated in JavaScript, our opportunity to cleanse noisy characters grows! We should look to Ruby to identify practices that have been time-tested.

Less denotation, less noise.

JavaScript Through Ruby Eyes
Takeaway: Optional syntax is a friend of readability

Modus Ponens

The biggest thing I miss from Ruby syntax is stupid simple. It’s the concept of speaking in the affirmative rather than negative. You see, in Ruby, wherever you’d type:

if !some_bool

Instead you could type:

unless some_bool

You may think this trivial, as did I. Modus Ponens is the method of affirming, and though logically no different than it’s counterpart Modus Tolens (method of denying), one is fundamentally clearer and nicer.

JavaScript Through Ruby Eyes
Logic likes modus ponens

It’s like the word non-fiction. It sticks in your throat even after you’ve mastered its definition. For Rubyists this goes beyond code.

Being positive fueled a community for Ruby, and that community is well known for having a supportive and friendly circle. They’ve set the bar high for something I didn’t even know I enjoyed.

I’ve seen a lot of, let’s call it, interesting logic performed in JavaScript, which the Rubyist in me condemns. It’s also fair to say, I’ve seen that same negativity grow beyond code in JavaScript. Alas , the metaphor applies to community here, too.

Some of the most talented JavaScript developers, though probably well-meaning, have failed to embrace the power of a positive fellowship. Since my re-adoption, I’ve had to reach out to people personally in Open Source Github discussions, to quite directly ask them to try to be nicer. Since JavaScript is changing, there are a lot of opinions being unearthed, and though this must be new for JavaScript devs there’s no reason for negativity beyond basic critical analysis. JavaScript and associated leaders can avoid pyrrhic victories by remembering the power of remaining positive in logic with regards to computers AND people.

JavaScript Through Ruby Eyes
Takeaway: Don’t re-un-dis-enable your incapacity to remove no negatives.


JavaScript gets a lot of things right, and because of that it’s time to be bold. We’re already seeing the influence of Ruby in ES2015 and I’m glad ES2016 will finally add simple functions like includes . Lacking a decent standard library causes hundreds of implementations and outlandish dependencies that lead to fiascos like NPM gate . Deeper concepts need to take root during these changes.

A fundamental care of readability and clarity should be evaluated and honed as first priority. This clarity allows us to identify these complications before they happen, rather than vaguely remember them as they bite us time and time again.

As a community member, this starts with you.

About Gant Laborde

Gant Laborde is Technical Lead atInfinite Red (⚙ web and mobile app dev ⚙), published author, public speaker, and mad-scientist in training. Read the writings of Gant and his co-workers in our Red Shift publication . If you’re looking to discuss nerdy tech, he’s all ears. View half-witty half-groan technical tweets with @GantLaborde on twitter.

JavaScript Through Ruby Eyes

Takeaway image provided by: http://www.freeimages.com/photo/chinese-take-away-box-1319752

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » JavaScript Through Ruby Eyes

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址