DEV Community: Christian Siemoneit

JavaScript Flaws: 5 stupid NPM packages

Christian Siemoneit — Fri, 22 Jan 2021 15:48:03 +0000

As co-founder of Codesphere and Ex-Googler I have been passionate about coding since I was a child. I love NodeJS/JavaScript/Typescript with all their flaws (and there are many lol). One of these flaws for which the JavaScript Community takes a ton of heat is NPM.

For those who do not know NPM - let me explain: NPM is the dominant package manager for JavaScript and NodeJs and it allows importing other source code into your project.

As you probably know, NPM is a pretty easy meme target, unless you avoided the internet for the last couple of years. The promise is that you include ten things, ten things depend on five things, five things depend on ten things and the next thing is that you have half a gigabyte of node modules on your disk.

NPM is essentially unrestricted and even more than on wikipedia anyone can publish anything. This can even lead to a point where you publish something that is meant to be a joke and people actually start depending on it. One example where unnecessary dependencies have been dangerous is leftpad, a library that prepended a number of characters to a string. Its removal led to outages all over the internet.

Here are my TOP 5 Unnecessary NPM Libraries on which people actually depend:

1: is-ten-thousand

This library is used to find out if (yep, actually) a number is equal to ten thousand.

There are actually some people depending on it and if you need even more help with questions of this kind, there are also is-hundred and is-ten available at your command.

Funny enough, is-ten even states how it is used by 10x engineers ;)

2: owoifyx

This library is very straightforward to use and it does exactly what you would expect:

It ‘owoifies’ (Hello -> Hewwo) your text.



const owoify = require('owoifyx');
console.log(owoify('Hello friend!')); // Hewwo fwiend (*^ω^)

26 people this week decided that they would need exactly this in their project.

3: true

This package is “A JavaScript port of the Unix utility 'true'” and it returns ‘true’. It even states how it should be used when you need a function that returns true.

The super clean three lines of code were developed by nine contributors in 30 commits, and like every good package, it has 100% test coverage. You might think: Why not use the built in constant ‘true’? - Uhm.. I don’t know!

More than 300 people couldn’t live without this core utility this week.

There is also a companion package false which does exactly the same for false.

4: emoji-poop

As one would expect, this returns the poop emoji, but what is really great about this piece of code is that this also has a 100% test coverage and therefore will - guaranteed! - return the poop emoji.

11 people this week used it, maybe to prove a point?

5: is-odd

A trivial operation to do in JavaScript, though the most used library in this list. It returns true if a number is odd, and it has more than 500k downloads this week.

For all of you who might have wondered if you could also check if a number is even? Surprise - this package exists (is-even) and was downloaded more than 100k times this week.

Fun fact: After some investigation by the Codesphere experts, we found that it imports the is-odd package, and negates it to your convenience.

Many thanks for reading this post, hope you liked it! What's your favorite NPM package?

Get a free VM!

Christian Siemoneit — Tue, 05 Jan 2021 13:10:34 +0000

Early access + pre-launch gift! Sign up for Codesphere to get a free VM --> https://codesphere.cloud/

Why online coding is the future ✅

Christian Siemoneit — Tue, 05 Jan 2021 12:33:44 +0000

Google uses Cider internally. Cider is a custom browser code editor which mounts the enormous Piper file system and provides a super tight integration with internal review, build and testing tools.

Github recently announced Github Codespaces to jump directly into a working environment when looking at a repository. Gitlab recently announced their partnership with Gitpod, building their own opensource clone of VSCode, providing the same functionality as Codespaces since some time already.

But why all this? Simply put, desktop IDE’s do not scale up!
In times of microservices and cloud developers just have to work on more complex projects… faster 🤓

While it is clear for Google that a single desktop, no matter how powerful, can not handle the Google Dev environment alone, it becomes almost equally important for smaller companies to not spend months on setting up a development environment.

The next logical step?

Move the full development infrastructure (from dev to production) to the cloud and unlock the potential of tools that exceed the abilities of my desktop.

This is why we built Codesphere 🚀

IDE’s are stuck in the past

Christian Siemoneit — Tue, 05 Jan 2021 11:07:58 +0000

IDE’s come from a time in which the majority of what we programmed were monolithic desktop applications.

But that’s not the reality anymore for many of us.

As web developers we now work on distributed systems consisting of many different microservices.

Let me give you an example: Not long ago we were all happy to listen to our music with Windows Media Player, a nice and simple desktop application that could probably build and run in any C-IDE without many problems.

Today many people use Spotify or similar streaming services to not only listen to music but also share and interact with the artists.

I don’t even want to imagine the hassle of setting up a development version of such a big software system.

A typical workflow of mine
Here is an example of the Codesphere co-founder Jonas. It is about setting up a new project from one of his friend. Spoiler: It’s not a great experience.

Because I recently got a new development machine I set up my keymap, installed a couple plugins, pulled out my split keyboard and I was able to do my code changes at a reasonable speed (ignoring the occasional wrong import suggestion I always seem to get).

Now the time comes to test my changes.

I begin with installing the project dependencies and at this point my hands begin to sweat as the CPU fan of my modern 2k€ laptop begins to spin at its maximum rate.

The IDE has started indexing a couple million of files and is burning away my battery at light speed. After a couple of minutes my computer becomes responsive again and I try to start the build and run script. But it’s not working!

It looks like some of the linux commands from my colleague don’t work on my windows computer. Also, I accidentally change the line endings from LF to CRLF on the files I modified, which will probably cause a headache later on when I try to deploy this to the production linux infrastructure.

Finally I get some of the microservices I want to test running. They are complaining about wrong credentials and about being blocked by the Azure firewall.

So I whitelist my daily changing IP address and gather the development secrets from the companies file share.

Even now: one of the services is still not fully healthy.

I ask my friend for help… He tells me that that particular service manages cluster resources and can only be run in a kubernetes environment and that I would have to install it if I wanted to debug that.

At this point my morning is over and I leave the desk to get a second coffee and ask myself:

‘Integration’ is a significant part of I(ntegrated) D(evelopment) E(nvironments) — so why are IDEs disconnected from our workflows today?

Let’s fix this

As web developers we always try to port as many desktop apps as possible to the browser.

After all, the browser seems to have solved the problem of software distribution allowing users to work at any place and any time.

Anywhere: Imagine being able to code anywhere, even on your Android tablet without having your lap burned from the CPU quickly burning away your battery.

Anytime: New collaborators could simply click a link and start coding right away. No individual setup process for the specific hardware.

There are more advantages to think of like real-time collaboration, having your settings synced everywhere and simplifying the integration of cloud services just to name a few.

At Codesphere we make this vision a reality.

Do you know the limitations and painpoints Jonas is describing in his article? Let us know! If you enjoyed reading this article, feel free to share it and follow us!