“ Do you know the most powerful thing about Javascript? Spoiler Alert, It is not asynchronicity, first-class citizen principles, not even my favorite, closures. While all of these make javascript a delight, what makes javascript powerful is not focusing on attaining power. Javascript is not power-hungry by design.”
Javascript in its vanilla form does not intend to provide you with capabilities touching skies and jumping oceans. That is where the amazing dev community along with packages breaks into the scene, bringing in powers from dark dimensions, Human Batteries, Arc Reactor, and who knows where else.
Yes, I exaggerated. Now that I have your attention, let’s dive deep into the perspective this blog aims to set. The core parts of javascript, widely popular and used, are not its own. That still does not take away the joy of working with it and It is still technically javascript.
This blog tries to answer its own title with a big Yes. It sets to establish "building for public "patterns while talking about javascript, modules, and publishing to npm. If you are still reading this blog, I assume you are familiar with what npm is. The exciting part of working in javascript (like many other languages) is the ability to share your work with others in a manner that they might use your work in their projects. Let’s begin with going over the basics of publishing your own module to npm, and then how to make use of that in a project.
Pilot: Getting hands dirty!
That might have been fairly easy. If you see something not right there, it's only because you figured it out ;)
A fun way to get started is by thinking small and smart. Before you begin writing your own modules, a good read would be how modules work in javascript, especially post ES6. You can find one here.
Episode 2: The Code Isomer Conundrum
Code isomers are two or more pieces of code that do the same work but differ in the way they are written. (Yes, I just made that up but it doesn't make it any less relevant)
This is the most fundamental example of it. When writing code that delivers much bigger the style developers use takes the shape of patterns. When writing modules that are intended for public use, a well-defined pattern reduces the headache of the person consuming that module. These patterns are categorically closer to the purpose of being used by anyone, anywhere and anytime than the language hence I call them "building for public patterns".
Have you ever come across a cool npm package, the intention of which gave you a tickle, but the implementation could not? When you installed the package you could not really understand what does what, there was no documentation readily available and you ultimately had to drop it? Yes, it does not happen when Facebook releases react.js or any organization releases a big package. But out there are many developers working on pretty cool stuff, some of which unfortunately fails to abide by the rather misty de facto standards of releasing to the public. These misty de facto standards are what we introduce here as building for public patterns.
There are two schools of thought on how to write code in any language. The first school of thought is that it should be written in a manner that is easily understood by the person who wrote it. The second school of thought is that it should be written in a fashion that is easily understood by the person who reads it.
The first school of thought is more often linked to the phrase "write self-documenting code" and is often referred to as "write-what-you-know" or "write-what-you-need". Regardless, it is a very common factor in programming, and it is often a necessity to write code this way when a project is small and the time of writing the code outweighs the time of reading it.
The second school of thought is a little closer to what we just introduced as "building for public patterns" and is often linked to the phrase "write clean code" and also called "write-what-you-need-to-know". It is also common to write code to be read by others. A programmer who is writing code that will be read by other programmers will write the code in a manner that is easily understood by the one who reads it. This is especially true when the code is in a highly complex area of the program.
"Building for public" patterns somewhere introduce a new school of thought that is closer to the person consuming the code and not does not care much about how the actual code is written. In javascript, the concept of modules post ES6 pretty much standardizes this notion. However, much is still left on the developer to abide by. This includes naming the handlers, exporting, shaping the module, and much more. It also goes on further to include optimizing the size of the module, adding more weight to the "consumer-first" approach of publishing your work.
Let's assume you are sick of the native console API and you have promised yourself that you won't use console.log() again. You decide to write your own function which uses an API you build to send logs to your phone.
const unConsoleLog = (data) => {
fetch(API_URL, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'token': 'XXXX-XXX-XXX-XXXXX',
},
body: JSON.stringify(data),
})
.then(response => response.json())
.then(data => {
console.log('Success:', data);
})
.catch((error) => {
console.error('Error:', error);
});
}
The idea becomes so exciting that you now want to make it accessible for public use. You decide to release this as an npm module.
Can you think of the best possible way to release this to the public using "Building for Public"?
to be completed...
Next on "Can you make JS more powerful?"
- Consumer First principles in "Building for public" patterns.
- Encapsulation in JS and life before ES6
- "For and by the public" with open-source
- Making javascript powerful with your first module. (.js)
Top comments (0)