Yesterday I posted here and on Twitter this idea:#
I’d like to do a new server-side JavaScript environment that’s compatible with Node, ie runs Node apps, no breakage, but it also eliminates the need for callbacks, promises or async/await. I believe it’s technically possible.#
A friend suggested using Babel to prototype this. #
I could imagine a modifier keyword on a function that means this function is internally going to do async things and calls to it should block until until it completes. That could be translated by a Babel plugin into somewhat that internally uses promises queuing to make callers wait for completion.#
This is the way to start. I wonder if anyone reading this has the expertise in Babel to make this work. I've started a thread over in the repo to discuss. #
I will write up some code to demonstrate what the Babel plug-in will do, hopefully later today. Stay tuned. #
I was asked on Twitter why I want this. There are all kinds of overhead, time, space, and intellectual. I program in a high level language instead of machine language because there's less intellectual overhead. It would save both time and space to use machine language. But I'm saving complexity by programming in a HLL, and that means I can build more complex and useful software. #
Why not just use promises, they're easy my correspondent asks. I say it's easier to not have to program something than use something that makes it easier to program. That's the philosophy of factoring. However the JavaScript I envision would be backward compatible with EC6. It would run any code that runs in Node. But it would also be able to process asynchronous functions with syntax that's as simple for a programmer as calling a synchronous function. #
I don't think there's any question that callbacks are something we'd like to simplify. I'm saying it's possible to simplify callbacks by removing the need to use them for simple asynchronous I/O operations, yet give up none of the efficiency. Most other languages do it, so can JavaScript. #
There's another reasons, transparency in APIs. For example, I might want to prototype a function by storing its data in memory, but at a later time may decide to store it on disk or on the net. I want to keep the interface unchanged, but with today's JavaScript you can't, you have to go to callbacks/promises/etc.#
In general, the philosophy of factoring says you take a problem that you're solving over and over, and create a library of functions that do it, and call them instead of replicating the code. #
Last update: Thursday June 18, 2020; 11:38 AM EDT.
You know those obnoxious sites that pop up dialogs when they think you're about to leave, asking you to subscribe to their email newsletter? Well that won't do for Scripting News readers who are a discerning lot, very loyal, but that wouldn't last long if I did rude stuff like that. So here I am at the bottom of the page quietly encouraging you to sign up for the nightly email. It's got everything from the previous day on Scripting, plus the contents of the linkblog and who knows what else we'll get in there. People really love it. I wish I had done it sooner. And every email has an unsub link so if you want to get out, you can, easily -- no questions asked, and no follow-ups. Go ahead and do it, you won't be sorry! :-)