@pro-script/as-is is a game changing library. Use cases 1.

At a recent interview, a Java developer walked in, eager to pivot to Node.js. He shared that while Java is predominantly used in banking and large corporations, he was tired of the constant type declarations required in Java. Over time, Microsoft has given us type safety in JavaScript with the development of TypeScript, now unofficially recognized as the standard in the JavaScript ecosystem. Interestingly, TypeScript turns 12 years old this October, Nest.js 7, React.js 11, and Node.js 15. Their age doesn't imply they are outdated; rather, it highlights the lengthy and rich evolution each has undergone.

However, the world is changing, technologies are evolving, and if you've never visited https://node.green, I highly recommend checking it out to see the myriad of exciting features already implemented in modern versions of Node.js and JavaScript.

The old is valuable, but without nurturing new technologies to develop and grow, we risk technological stagnation. About seven years ago, the IT community started voicing concerns that open source was in a crisis. Open source enthusiasts proved their mettle, with some starting their own companies and others moving to large corporations to make their mark. Today, the open source market struggles to thrive, which could lead to the dystopian future that 90s IT activists feared: a world dominated by large corporations, depriving developers of alternatives. Without alternatives, a young person might one day find themselves paying tens of thousands of dollars for, an example, a TypeScript certification. To make education cost-effective and profitable, tools would need to become more complex. The more complex the tool, the longer and more costly the training.

I’m not here to criticize TypeScript or Microsoft—I continue to work within this ecosystem. But I would like to offer you an alternative that has its own set of advantages and, of course, its drawbacks. Look at how straightforward some tasks can be, read through the resulting code, and perhaps you’ll discover the joy I find in using simple, intuitive tools.

Let’s dive into type checking in JavaScript.

To be honest, I'm not a fan. On one hand, there's typeof; on the other, there's isArray. Why not standardize and handle everything through typeof or through methods like isString, isNumber, isSomeType? Converting a string to an array through the strange method split. Why not have a toArray?

Of course, it's possible! This is JS, after all:

It's possible, but it often looks very complicated—we frequently say during code reviews that it's "unreadable" or "hard to read." Here's another example with TypeScript, where, besides being unreadable, it's also unclear if you're not familiar with the implementation mechanisms.

Robert Martin in his book "Clean Code" says that code should tell a story. Any story can be told in simple or complex language. My favorite story in JavaScript goes like this:

Let's move on to some simple examples.

You can check all existing types in JavaScript using a unified and readable method from @pro-script/as-is. Here’s a list of types and their aliases that you can verify:

Number | number, String | string, Boolean | boolean, Symbol | symbol, Function | function, BigInt | bigInt | bigint, Array | array, TypedArray | typedArray | Typedarray | typedarray, Buffer | buffer, SharedArrayBuffer | sharedArrayBuffer | SharedarrayBuffer | sharedsrrayBuffer | sharedsrraybuffer, Date | date, Object | object, Class | class, instance, Enum | enum, Set | set, Map | map, Iterator | iterator, Nullish | nullish, WeakSet | weakSet | weeakset, WeakMap | wearMap | weakmap, WeakRef | weakRef | weakref, RegExp | regExp | regexp, Promise | promise, Error | error, RangeError | rangeError, ReferenceError | referenceError, SyntaxError |syntaxError, TypeError | typeError, Any | any.

If the type does not match the declaration, the call will return false during the execution of the JavaScript code.

Yes, @pro-script/as-is checks types only at runtime, unlike TypeScript. You may be disappointed by this fact, or perhaps you'll find it reassuring. With the appropriate support, @pro-script/as-is could potentially implement static typing and check types before script execution if necessary. However, after 12 years of using TypeScript, it turns out that IDEs handle this task very well even without static typing; 12 years ago, we didn't have such smart IDEs as we do now. Furthermore, errors found through static typing account for only 20% of all potential bugs.

A discerning reader will notice in the library name @pro-script/as-is not just a set of methods for "is", but may also infer that there are methods for "as" — and they would be correct. The "as" methods have a slight difference from the "is" methods. In "as", if the type check is successful, it doesn't return a boolean value, but rather the value that was checked. Otherwise, a type error is thrown.

Such a small difference, but it can transform and protect your code from many misunderstandings and errors. When I was working on this implementation, I thought that a simple runtime type check would just be a tool for me, and that I would be protected from accidental errors. However, as I experimented, I discovered a whole world hidden beneath this simple syntax. A world where the code becomes less and starts to read better. But now, according to marketing rules, I should pause here and promise to reveal more details in a future post. One convenient feature per post, so you stay focused on what's important.

I really hope for your like, repost, and comment. The world always starts changing with simple steps, which over time turn into something grand.