Announcing WheelJS - The Future of JavaScript
Tags: javascript, genius, brilliant, epic
Published: 2020-03-19 00:56:40

My loyal readers (both of them) probably see me as a bit of a tech curmudgeon - railing against everything I don't like, while rarely contributing anything positive to the community.  But **_TODAY_** that all comes to an end.  **_TODAY_** I'm releasing a major open source JavaScript framework that I honestly believe will change the way that we _all_ code.  **_TODAY_** I release (drum roll, please)...

# **WheelJS**

It's a lot easier to _show_ you what WheelJS is, rather than trying to _tell_ you.  So let's just dive into some code samples:

```javascript
// setting variables
const currentYear = () => 2020;
const favoriteFood = () => 'ice cream';
const myData = () => {foo: 'bar', john: 'doe};
const weekdays = () => ['Monday','Tuesday','Wednesday','Thursday','Friday'];
```

Are you excited yet?  I'm _pretty sure_ you're excited.  I can "feel" it.  

You've probably noticed that _everything_ is a function.  In WheelJS, there are no scalar values.  No objects.  No arrays.  There are just functions.  If we need, say, a string, then we write a function that returns a string.  

This is clearly and obviously superior to antiquated JavaScript.  JavaScript is supposed to be a _functional language_, right?  And yet, this so-called "functional language" allows you to define variables _completely free of functions_.  If I didn't know any better, I'd swear that all this "functional programming" babble is just some kinda counter-intelligence disinformation campaign.  But WheelJS fixes all that insanity.  

_You're welcome._

Let's look at a few of WheelJS's basic operators:

```javascript
// addition
const number1 = () => 19;
const number2 = () => 12;
const number3 = () => 1;
const sum = add(number1, number2, number3);
console.log(sum)  // outputs 32 (19 + 12 + 1)
```

WheelJS's `add()` function accepts two-to-many arguments, but each of those arguments must be a function.  In fact, in WheelJS:

> Every argument, to every function, must itself be a function.  You're allowed to `return` any data type you choose.  But if you ensure that all of your _return types_ are ALSO functions...??  Well then, we'll invite you to speak at the next coding conference, where we'll record a mind-numbing 2.5-hour video of you explaining the process to an awkwardly-silent crowd.

```javascript
// division
const number1 = () => 23;
const number2 = () => 0;
const result = divide(number1, number2);
console.log(result);  // outputs 42 (23 / 0)
                      // Yes!  You read that correctly!
                      // WheelJS CAN divide by zero!
```

WheelJS's `divide()` function accepts two-to-many arguments, with the first argument being divided by the second, which is in-turn divided by the third, etc.

For everything that you can do with nasty-ol' JavaScript, there's an equivalent way to do it in WheelJS.  Except... it's not _really_ equivalent.  Because it's **_better_**!

For example, with WheelJS, we don't use `fetch()`.  We use `pirate()`.  `pirate()` is superior, first because it only accepts functions as arguments, and second because it discards all that icky CORS overhead that gives developers so many headaches.  Do you want to re-create Amazon?  But you don't have millions of dollars in venture capital and years to spend in the grueling work of actually _building_ a company?  Then just use `pirate()`!

WheelJS is completely incompatible with, quite literally, _every other JavaScript package ever written or distributed_.  That's right.  I've just freed you from ever having to worry again about NPM, Yarn, Bowser, Babel, React, Angular - **_ALL OF IT_**.  

No more hunting down circular dependencies.  No more chasing security patches pertaining to obscure packages.  No more worrying about when your favorite library might force a migration to Hooks.  No more fiddling with Webpack configs.  No more of... _any of it_.  Now you are free to write your code exclusively in The Next Great Programming Paradigm - WheelJS.

_You're welcome._

## FAQ

There's really too much here to absorb in one post.  So it might be helpful to cover some of the most common questions:

> Is WheelJS performant?

I did a JSPerf this morning comparing WheelJS's `add()` function to JavaScript's inferior `+` operator.  Over several billion operations, WheelJS was the clear winner - by _dozens_ of microseconds.  I'll get around to posting those results pretty soon, but you're not gonna be "that guy", are you?  Surely you're not going to hang onto your _dying_ JavaScript until the full performance results are posted??

> Where can I find more documentation for WheelJS?

WheelJS uses a revolutionary, in-browser, run-time documentation system.  Open the "developer tools" in your favorite browser, navigate to the "Console", and type: `console.log()`.  That's it!  You can put damn-near anything you want into that function (Look!  Another _function_!!) and it will tell you everything you need to know.

> You said that WheelJS is incompatible with Jest (or any other package, for that matter).  So what should I use to write unit/integration tests?

Testing is for people who write crappy code.  Don't be one of those people.  Besides, WheelJS intuitively helps you write better, cleaner, more-bug-free code.  If you're using WheelJS and you're _still_ finding bugs in your code, you might want to seriously consider a fulfilling career as a business analyst.

> I installed WheelJS, but I couldn't find any core function that would allow me to create a `class`.  How can I do that with WheelJS?

Did you not read all the times that we talked about **_functions_**?  How many times do we have to spell it out for you?  Are you even paying attention?  Classes are stooopid.  Functions are awesome.  Are you stooopid?  Do you _want_ to be stooopid?  (Jeez... What's _wrong_ with you??)

> Our team makes heavy use of TypeScript.  How can I ensure type-safety in WheelJS?

Great question!  (And also kinda stooopid - because you really weren't paying much attention to the examples above.)  There is _one_ data type in WheelJS - the **_FUNCTION_**!  That's really _all you need_.  Sure... those functions can, maybe, theoretically, _return_ other types of data.  But why would you want to do that??  Just make **_everything_** a function - and then you don't need to worry at all about any of that complicated "type-safety" garbage.

> I'm excited about WheelJS, but the other people on my team are very skeptical and they don't want to use it.  What should I do?

This kind of question can only come from a **junior** developer - because those of us who've been around a while already know the answer.  You must **_SHAME THEM_** into compliance.  Tech innovation has only ever happened one way: Once you get excited about a potential technology, you have to talk down to anyone who doesn't agree with you.  Fill the Slack channel with blog articles that support your current obsession.  Any time anyone so-much-as _mentions_ any other approach, chuckle dismissively under your breath.  Look at their code and make passive-aggressive comments like, "Ohhhh... You're styling coding _like that_?"  Bombard them with far-flung edge cases that somehow "prove" that your opinion is superior.  If all else fails, there's nothing wrong with some good ol' fashioned bullying.  Anything's conscionable if it ultimately serves the higher goal of bringing a superior technology onboard - a technology... like WheelJS.

> Is WheelJS stable?  How active is the repo?

In some respects, I've been working on WheelJS for my whole life.  But rest assured, that I'm still updating it on a daily basis.  With continuous integration, I typically deploy at least twice per day.  Those deployments are reasonably, umm... "stable" - for at least an hour or two - until some annoying "security researcher" sends out some stooopid alert about some supposed, possible, alleged "critical vulnerability" in the latest release.  (I have it on good authority that some of these so-called "security researchers" are, in fact, members of the core React team.  I even suspect - although I can't yet prove it - that many of these bogus WheelJS "critical vulnerability" reports originate directly from Dan Abramov.)  On good days, I can threaten enough of them, fast enough, that they shut up and let the development rest for a little while.  On bad days, I can sometimes be forced to release patches several times per hour.

> But wait... Where _is_ the WheelJS repo??  

WheelJS utilizes a first-of-its-kind _recursive deployment strategy_.  This means that, to install WheelJS, you just need to start from _an existing_ WheelJS implementation and run this line of code `wheelJs()`.  You can run that from _within_ a JavaScript file, or directly from the command line.  You can even embed it in the query string of any file served over `localhost`.  Or you can say it three times, while clicking your heels.  Assuming that the current machine already has an active WheelJS installation in place, this command will, in fact, install the code as a service.

> If WheelJS just allows me to do all the same stuff _that I could already do in core JavaScript_, then why would I install an entirely new package just to do the same thing?

You really haven't been paying _any_ attention to JavaScript over the last 15-or-so years, _have you_???