Introduction

Welcome to the World of JavaScript!

Where (almost) everybody has a shiny new package to show off.
Where there is a package for almost anything imaginable, see this.
Where you could easily get confused over a package to choose because a simple Google search gave you results of packages like: dom-markdown, dom_markdown, dommarkdown...
Where you could easily fall into information overload and become indecisive in doing basic stuffs because no matter what you use, someone always recommends a (better) shiny new toy.

How do I stay sane?

Well, it's pretty easy: "IGNORE THEM ALL."
Yes, you read that right.
"IGNORE THEM ALL"

"I don't think that's good advice buddy.Why should i ignore them all?"

See, you want to stay sane and choose what's best for the project, right?

"IGNORE THEM ALL"
I'm going to explain why during the course of this article.

I see many beginners struggle with Library Dilemma. They spend time asking on different groups about which to choose from a set of libraries.
And you can guess what happens most of the times: "Many folks share their Shiny New Toy" as a better alternative" which in turn makes the beginner more confused. Plus, he/she now has +n amount of new libraries to choose from. Lucky You!! (in Joyner Lucas's voice) ;)

This might look good from one perspective, having lots of options to choose from.

"IGNORE THEM ALL"

"Why?"

As a beginner, you should spend more time understanding the language.
Trying to know the capabilities of this language.
Figuring out where the native API shines and where it lacks.
This might look boring but Lucky You, JavaScript on browsers comes with DOM, so you could learn all these in a fun and interactive way by building small web apps in your browser.

You should learn about AJAX, JSON, fetch and all the goodness of the JavaScript world. You should try to create a simple SPA without any libraries. You should get comfortable with the language. You should be a "Firefox", exploring the capabilities of this beautiful but misunderstood language.

"Dude! What about Internet Explorer?"

Okay, or an "Internet Explorer"

"You forgot to add Microsoft Edg.."

DUDE!!! STFU!!! Let's be serious here! Don't "slow" me down (pun intended).

A little history

I started coding back in 2010.
Then, JavaScript was just a client side scripting language that ran (only) on web browsers. I mainly used it to validate forms, get inputs from forms to perform actions with a script, create animations (carousels, modal box), et al.

Okay, i just checked Google, Node.js was released the previous year and npm was released that same year but i did not know about it back then. I mean, PHP was still cool back then ;)

Resources were limited. Many folks were still getting a hold of the language. The language was(is) still growing. The options to choose from were not as much as we have now. We had some popular libraries: jQuery, Dojo, et al. We downloaded libraries as zip files. NPM was not yet viral. If you created some library, it had to be really cool eg Lightbox (i think this was released in 2011) by Lokesh Dhakar. Plus, you'll have to do some real work by writing articles, build cool stuffs with your library and do some convincing as to what problem your library solves and why we should use it.

OR, you could become an instant hit if someone like Chris Coyier uses your library on css-tricks.

You see the process? Most libraries where created out of a need of some project or sometimes when you feel you could make some processes easier. Many folks wrote tutorials about this or shared their scripts on forums. There were "Standard Toys" which we played with and everybody was happy.

As years passed, JavaScript was making advancements and improving and gaining more popularity. NPM was becoming popular. Every new kid on the block could write a new script and O boy....i forgot to mention Github. Folks were publishing libraries. Some libraries were made up of functions. Functions that could have been added to an already existing library by making a simple pull request and contributing it to an existing library that has gathered some popularity.

NO WAY!! It's my "Shiny New Toy" and it must live in its own Github repo and published under my name on NPM...lol (Just joking...or am i?).

But seriously, many of the libraries on NPM could have not been, if only the author had a discussion with the author of the current library he/she uses and offer to add the functionality as an improvement instead of creating one from scratch.

You could also say that creating your own library could be a learning process for you. You're right though, but in the spirit of open source:

"If folks are already doing it, join in and contribute."

Why Ignore them?

Okay back to the main point. I've already given a brief overview of how the ecosystem was many years ago and how JavaScript was seen plus its capabilities. Plus, what the library ecosystem felt like.

"So why Ignore them?"

Well, it could be from my personal experience in the past plus what i see from new developers.
Following the rapid changes in the JavaScript ecosystem back then, i did not really go far with the language. I just downloaded lots of video tutorials and saved hundreds of web pages with the hope of learning them some day.
That day never came :(

Back in 2016, i decided to revisit JavaScript. I was building a startup. I had an idea of how to solve a pending problem in Nigerian Universities. I started working on JavaScript using AngularJS (yes, Angular with a JS at the end).
I used AngularJS for the web client and Ionic for the mobile app. The backend guy used NodeJS (ExpressJS). We wanted it to be a MEAN stack app because: That's whats Up.
MEAN stack was the new word for cool back then. It was trending and was our Shiny New Toy.

Okay, So why Ignore them? You haven't still answered the question.

Fast forward into the project. 90% done.
Ding! Ding!! Google announces that it is releasing Angular 2.
"Okay no problem. Bring em on", we said.
"Errmm...you would be coding in TypeScript", Google says.
I go over to check out the release docs for Angular 2 and everything is so different from AngularJS. I'm like: "OMG."
Why so much changes?
Why didn't you you see this coming and change gradually or something?
Plus, Ionic was not a comfortable experience. Many issues with gradle (which was solved, though). Slow webview. Animations was not smooth. But i couldn't complain: "It was everyone's Shiny New Toy."

I wouldn't rewrite my app immediately because that would be a stupid thing to do, obviously.
But, Angular 2 was the Shiny New Toy. I fell into the Shiny New Toy train of MEAN stack without doing the needed research to see what was best for my project. MEAN stack just sounded too cool.

At that moment, i decided not to be moved by the "Shiny New Toy" effect.
I realized that my mobile app would have been better off if i had created it with Native Android since its a start up and the IOS (is it IOS or IOs or iOS or ioS?) version could come later as the product gains traction. AJAX with JavaScript would have been enough for some Single Page effects in the web app.

I learnt this the hard way.

Conclusion

The front end ecosystem moves very fast and is very open because there are not much perquisites as compared to back-end.
In this article, i shared with you why you should ignore everyone's "Shiny New Toy" because no matter the library you're currently using (in JavaScript), someone would always have something he/she feels is more shinnier than what you're using. This happened in a post i wrote some weeks ago about axios.

So, whenever someone introduces a Shiny New Toy to you, ask yourself:

• If you know what this library is trying to solve.
• If you understand the problem and how this library could be helpful to you.
• If this could be easily done without a library because sometimes, the functionality you want might be just one function and the library size might be very large.

And if you're already using a library/framework or whatever:

• Ask what the benefits are and trade-offs of your current tool-set.
• Check if there is a way around that with the current library/framework you're using?
• Check if there is something that your current tool-set can't do and this "Shiny New Toy" does. The extra thing some library does that might be different from yours might just be a simple function which you can add by yourself.
• If this is a real issues, then why don't you call the attention of your current library's community and try fix the problem or add the feature.
• Ask yourself if this library/framework is revolutionary for example: Flutter. If it is, then you check if it is mature enough to be used "now" or to be added to your watch list.

I hope you get my point? Don't just jump from library to library all because everyone is using it OR the community says its the coolest thing that has ever happened. Do your analysis and if it doesn't pass, IGNORE IT.

I did not say you should not learn new stuffs O! (in Yoruba accent).

You can call it VueJS, SvelteJS or even Angular but i'm currently using ReactJS and it gets the job done and i am okay with it. If i have a problem and i feel i can contribute, then i'll just do that in this library.

I'll always IGNORE YOU unless my current tool-set fails the above test.

Once more thing...

Errmmm... i am also guilty of installing libraries in a StackOverflow answer without checking all the above stuffs. We have deadlines and we've been on that bug for days. Let it work first. We'll come back and check all these stuffs later jari ;)

Thanks for reading.
I'll see you in the next post.