fbpx

Posts tagged "javascript"

Node.js Foundation and JS Foundation Announce Intent to Create Joint Organization to Support the Broad Node.js and JavaScript Communities

October 4, 2018 Posted by News, Programming 0 thoughts on “Node.js Foundation and JS Foundation Announce Intent to Create Joint Organization to Support the Broad Node.js and JavaScript Communities”

The Node.js Foundation and JS Foundation today announced an intent to merge. A Q&A session will be held onsite at Node+JS Interactive from 7:30am – 8:30am PT, October 10 at West Ballroom A. Anyone attending Node+JS Interactive is welcome to attend; questions can be submitted in advance anonymously via this Google Form.

Leaders from the Node.js Foundation Board of Directors, Technical Steering Committee and Community Committee will join representatives from the JS Foundation Board of Directors and Technical Advisory Committee to facilitate the discussion, answer questions and solicit community input on the possible structure of a new Foundation. Joining forces will not change the technical independence or autonomy for Node.js or any of the 28 JS Foundation projects such as Appium, ESLint, or jQuery.

JavaScript is a versatile programming language that has expanded far beyond its role as a backbone of the web, entering new environments such as IoT, native apps, DevOps, and protocols. As the ecosystem continues to evolve — moving from browsers to servers, desktop applications to embedded devices — increased collaboration in the JavaScript ecosystem is more important than ever to sustain continued and healthy growth.

“The Node.js Foundation and JS Foundation boards have met several times already to discuss a potential alignment of the communities. The Foundation leaders and key technical stakeholders believe that a tighter alignment of communities will expand the scope of the current Foundations and enable greater support for Node.js and a broader range of JavaScript projects,” said Mike Dolan, Vice President of Strategic Programs, the Linux Foundation.

“We are very interested in hearing directly from the community and welcome all questions, ideas and opinions so that the structure aligns with the expectations of the community. For this reason, no formal decisions regarding a merged Foundation and its potential organizational structure, governance policies, technical framework or leadership have been made at this point and will be formalized based on feedback from the community.”

Additional goals for a merger include:

  • Enhanced operational excellence;
  • Streamlined member engagement;
  • Increased collaboration across the JavaScript ecosystem and affiliated standards bodies;
  • An “umbrella” project structure that brings stronger collaboration across all JavaScript projects; and
  • A single, clear home available for any project in the JavaScript ecosystem.

Today, JavaScript is nearly ubiquitous. Enterprises have been able to greatly reduce training costs and increase developer productivity because frontend JS developers can work on the server side, and vice-versa, eliminating the context switches and enabling all developers to pull from the same knowledge base and vast module ecosystem. Node.js is a major catalyst for this growth. It has become an important part of the modern web development stack and is often the assumed default when working with JavaScript. Merging the Foundations will bring the governance of these technologies in line with its real-world use.

“JavaScript is at the core of an ecosystem of technologies that form the backbone of the web and play an increasingly vital role across industry and society,” said Dan Appelquist, Director of Web Advocacy & Open Source at Samsung Research UK and JSF Board Member. “Strong governance, encouraging inclusive contributor communities and engagement in the ongoing standards development are all important factors in ensuring this ecosystem continues healthy development. A merged foundation is well positioned to deliver on these goals.”

“The possibility of a combined Foundation and the synergistic enhancements this can bring to end users is exciting,” said Todd Moore, Node.js Board Chairperson and IBM VP Opentech. “Our ecosystem can only grow stronger and the Foundations ability to support the contributors to the many great projects involved improve as a result.”

About the Node.js Foundation
Node.js is used by tens of thousands of organizations in more than 200 countries and has around 10 million users. It is the runtime of choice for high-performance, low latency applications, powering everything from enterprise applications, robots, API engines, cloud stacks and mobile websites.

The Foundation’s membership base includes Platinum members Google, IBM, Intel, Joyent, and Microsoft. Gold members include GoDaddy, PayPal, and NodeSource, and Silver members include Bitnami, Chef, Dynatrace, Fidelity, Groupon, HackerOne, NearForm, npm, Oath:, Profound Logic, Red Hat, RisingStack, SafetyCulture, Sauce Labs, Snyk, and YLD. Get involved here: https://foundation.nodejs.org.

About the JS Foundation
The JS Foundation’s mission is to drive broad adoption and ongoing development of key JavaScript solutions and related technologies through ongoing efforts and services such as mentorship programs, events and support of web standards. The JS Foundation works to facilitate collaboration within the JavaScript development community to ensure its projects maintain the quality and diverse contribution bases that provide for long-term sustainability.

The Foundation is supported by members IBM and Samsung (Platinum); Accenture (Gold); and Agile FAQs, Blog Starter, BLOQspace, Bocoup, BrowserStack, Cloud Grey, Kenzan, Particle, Ripple, Sauce Labs, SitePen, Sourcegraph, StackPath, WebsiteSetup, and White October Events (Silver). Learn more about the members who support the Foundation and how to join at https://js.foundation/about/members.

Please follow and like us:
0

Code JS in Stlye: Early Return

October 4, 2018 Posted by Programming 0 thoughts on “Code JS in Stlye: Early Return”

There comes a point in the life cycle of a project that we no longer have to worry about whether or not the darn piece of code works in the first place. We’ve got to look back and see if the darn piece of code has style.

In this series, we’ll explore how we can write code that’s worthy of the runway.

Today, we will be implementing the early return.

The IF Spaghetti

When we’re controlling the flow of data within a function, it can be tempting to use only a single return statement. A variable will be assigned a new value depending on a condition.

function divider(dividend, divisor){
   let response;
   if(isNaN(dividend) || isNaN(divisor))
   {
     response = "Error: input a number";
   }
   else if(divisor === 0)
   {
    response = "Error: cannot divide by 0";
   }
   else 
   {
    response = dividend / divisor;
   }
return response;
 }

Note: Admittedly, that else block is a stretch.

The code above has a single exit point(return statement), which is fine if you’re thinking in terms of functional logic. When we learn about functions for the first time, it’s ingrained in our being that you only return once. A function is a dog and a dog only has one tail, the return statement. Logically-speaking, the notion of multiple exit points can appear confusing…like a dog with multiple tails. “Which tail will the dog wag next?” is the sort of thing a cynic might say about functions that have multiple returns.

But a single exit point in a maze can create a game of cat and mouse as we peruse through nested conditions. If you looked at the earlier code example long enough, you may have gotten that nagging feeling that said, ‘if the condition is met, why are we not exiting right now? Why do we have to wait?’

It’s as if we reached a possible exit after meeting a condition, only to be funneled to a waiting room. Think: your flight’s delayed after meeting the condition of booking your ticket and being there on time. Yeah, rough.

Conversely, we can use early returns.

function divider(dividend, divisor){
   if(isNaN(dividend) || isNaN(divisor))
   {
     return "Error: input a number";
   }
   else if(divisor === 0)
   {
    return "Error: cannot divide by 0";
   }
return dividend / divisor;
 }

Multiple exit points allow us to make sense of the logic. Sometimes, we need to be reminded that we’re still within a function as we traverse conditions.

When you think about early returns in terms of pseudo code, you’ll realize that early returns are succinct.

If a condition is true 
  return value.

As opposed to,

If a condition is true
 assign a value
the value may or may not change...
return value

There’s less ambiguity, less confusion, and more assurance with early returns. It feels good to know that if you have a base case that handles invalid input, you are exiting the function immediately.

Doing otherwise is akin to dragging your feet, saying, “Yeah, yeah I’ll take care of that later.” Then, assigning the task of garbage disposal to someone else.

if(hackyInput)
{ 
  return; //!!!!
}
//vs
if(hackyInput)
{ 
  handleLater = ERROR_MSG; 
}

Sprinkling More Style

All of this code can be stripped down by deleting all of those brackets.

function divider(dividend, divisor){
   if(isNaN(dividend) || isNaN(divisor))
     return "Error: input a number";
   else if(divisor === 0)
    return "Error: cannot divide by 0";
return dividend / divisor;
 }
if(hackyInput) return; //!!!!
//vs
if(hackyInput) handleLater = ERROR_MSG;

Thoughts?

Of course, all of the above should be taken with a grain (or a couple more) of salt. At the end of the day, it is a style of programming. There is a time and place for early returns just like there’s a time and place for fanny packs(is there?).

It would be responsible to include a disclaimer. So here it is:

When you abuse the return statement by placing it in the middle of code, or, worse, a callback, you can create a hellish “Where’s Waldo?” debugging scenario. When your logic is bursting at the seams with complexity, so much so, that you need multiple returns to diffuse some of that complexity, then early returns become a crutch, rather than a tool. In that case, you may want to decouple your code, which is a nice way of telling you to nuke it.

Semantically, an early return should signify to the code reviewer that your first validation is make or break. The function cannot run without the condition being met. In that case, the early return reads more like a fail safe than clever coding.

At the end of the day, good style is in the eye of the beholder…for the most part.

Please follow and like us:
0