I would rephrase the title: "It runs on the user's platform or it is wrong."
The example discussed throughout the article is Clujure vs. ClojureScript.
The author takes issue with the difference in compile time (6.5 seconds vs. 78 seconds, respectively).
But this really is an apples/oranges comparison. If the user expects to run the program in their browser, then any solution that doesn't deliver that experience is wrong. End of story.
If the user can't be bothered to figure out how to install your native or byte code binary, then your solution is wrong. Find a way to give the user what they expect or stop trying to write software for a living.
Here's a common programmer dilemma:
You are familiar with development system X. However, your users demand that your software run on platform Y. Platform Y doesn't support X natively.
What do you do?
One option is to refuse to learn the development tools for platform Y, bringing shims, transpilers and a bunch of other dreck needed to get X running on platform Y.
But the user will notice the difference and not like it.
You're better off learning the native development tools for platform Y, and delivering a native experience.
In other words, drop ClojureScript and write the application in JavaScript if your deployment target is the Web browser.
> However, your users demand that your software run on platform Y. Platform Y doesn't support X natively.
What do you do?
Use Electron apparently…
> One option is to refuse to learn the development tools for platform Y, bringing shims, transpilers and a bunch of other dreck needed to get X running on platform Y.
> But the user will notice the difference and not like it.
GTK+ and especially Qt are still used. Both have had native rendering on macOS for a long time. It seems like some people compare the most polished Electron apps to the least polished examples of other frameworks.
> In other words, drop ClojureScript and write the application in JavaScript if your deployment target is the Web browser.
On the other side of the same coin: Drop the web stack and write the application in an appropriate native development environment if your deployment target is desktop or mobile.
Dropping Clojurescript in favor of JavaScript doesn't really solve the problem. Modern JavaScript has compilers, bundlers, minifiers etc that all slow down the build process as well. Almost no one actually just open up a JavaScript file an runs it as-is in the browser these days.
In addition, unlike say GTK vs a native windows app, the only perceptible difference to a user of a Clojurescript app versus some other flavor of JavaScript will be bundle size. Clojurescript embraces the JavaScript VM, unlike languages that attempt to bring their own runtime to JavaScript.
The example discussed throughout the article is Clujure vs. ClojureScript.
The author takes issue with the difference in compile time (6.5 seconds vs. 78 seconds, respectively).
But this really is an apples/oranges comparison. If the user expects to run the program in their browser, then any solution that doesn't deliver that experience is wrong. End of story.
If the user can't be bothered to figure out how to install your native or byte code binary, then your solution is wrong. Find a way to give the user what they expect or stop trying to write software for a living.
Here's a common programmer dilemma:
You are familiar with development system X. However, your users demand that your software run on platform Y. Platform Y doesn't support X natively.
What do you do?
One option is to refuse to learn the development tools for platform Y, bringing shims, transpilers and a bunch of other dreck needed to get X running on platform Y.
But the user will notice the difference and not like it.
You're better off learning the native development tools for platform Y, and delivering a native experience.
In other words, drop ClojureScript and write the application in JavaScript if your deployment target is the Web browser.