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:

// 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:

// 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.

// 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???