JS doesn't type check, generate an AST, or even minifies anything until the user runs the code. If you just write JS in notepad then immediately send it over to your users, then yeah, there's no build in JS.
But if your idea of writing software involves:
* type checking, linting and otherwise ensuring properties of the code before even running it.
* testing code before deploying it.
* turning it from text into a representation that's more compact and safer to run.
* generating documentation.
Then you'll definitely need a build, and a very complex one for that matter, in JS world. Have you ever seen a JS project without any sort of build in a professional context?
And you'll need a big IDE to help you make sense of anything because JS doesn't even have a "compiler" or "helper tool" that'll give you any help to navigate and understand the code base.
> Have you ever seen a JS project without any sort of build in a professional context?
Imagine a world that pre-dates typescript, node, webpack, browserify, gulp, grunt. You were lucky if you had a server framework that concatenated files for you, otherwise you were stuck with 6000+ line "global.js" files. Then you had to fix merge conflicts in that file because SVN.
Whenever someone complains that frontend JS is too much, I just think back to how it used to be.
I'm not an expert at JS internals, but I'm under the impression that if you call a function ten times, its code has to be interpreted ten times, so you get ten, temporary, abstract syntax trees. Such is life in interpreter-land--the code is authoritative, the instructions are ephemeral.
My impression of Unison is that if you want to call a function ten times, you just need to evaluate that code into an AST once. Once you have the hash of that AST, you can delete the code and still call the function 9 more times without having to bother with building the tree each time.
I don't know what to call it, but I don't think it's interpreted because you don't need the code to run it (except the first time, which is how you know find the hash of the function).
> I'm not an expert at JS internals, but I'm under the impression that if you call a function ten times, its code has to be interpreted ten times, so you get ten, temporary, abstract syntax trees.
This is not the case even in an interpreted language. You only need to build an AST once, at parse time. In JavaScript the AST is then compiled into byte code or machine code depending on the implementation.
In JS, if 1 developer and 9 users with a total of 10 separate browser instances all call the same function, the code will be parsed 10 times.
In Unison, the AST is generated by the developer, cached, and the 9 users can call it by hash (assuming they have access to that database where the AST lives) without reparsing the code.
It's in a sqlite database. Unison doesn't prescribe how those are passed around, but since everything is content addressed there are never any name collisions. You can always merge two of them into one without having to resolve conflicts and without breaking anything. Doing so just expands your codebase to include more code than you're currently calling.
The way I intend to use it is that users periodically assemble the codebases from all of the developers that they care about and merge them into a single codebase. This can be very latency tolerant (like, sneak-a-thumb-drive-across-the-border levels of latency tolerant) because it's not like you're waiting around for transport every time you want to do something, just every time you want to upgrade.
Then, when you decide to use the new version of something (the developer would communicate a new hash to you), you just start calling the new hash and now you're using the new software. If something goes wrong, you just go back to calling the old hash. No implicit trust (e.g. no need for SSL, DNS, package names), atomic upgrade/downgrades, no merge conflicts.
