No documentation for the API?

[pranaypratyush]

Maybe a noob question but can I run any nodejs code on just?

[billywhizz]

Hi. I will get some docs up over next week - has been on my list of things to do for some time.

No, just is not compatible with node.js. Having said that, it would not be too difficult to write a compatibility layer for some of the core node.js functionality.

However, going forward, I would imagine more divergence as node.js seems committed to implementing most if not all of the browser APIs and is very much a general purpose toolkit useful for both frontend and backend development and running on a wide range of platforms. I don't see just core ever being much more than what it currently is - a small and simple codebase implementing a very thin layer on top of linux system api's and c/c++ libraries. it could at some point be used as the basis for more complex platforms/runtimes like node.js.

[pranaypratyush]

I would like to use just to run http and ws server. Ability to run express like frameworks would make it really popular.

[billywhizz]

I would like to use just to run http and ws server. Ability to run express like frameworks would make it really popular.

yes. i think it might be possible to do something that would emulate express api and allow a lot of the middleware out there to run. you'd have to be very careful about what libraries you use though. there is no magic going on in just-js - the reason it is so fast for techempower is because it has been hand optimised to minimise garbage collection etc. you can see in the fortunes test where it has to deal with a lot of strings and more complex manipulation of data it doesn't do so well. it still should be possible to outperform most node.js frameworks with an easy to use api as there are so many extra layers of js and c++ in node.js. the main purpose of doing the techempower entry was to see how fast we can go in js and then we can see as we add more features what the impact is on this baseline. sort of the opposite of how most projects do things - i like to call it "performance driven development". :grin:

i'll see if i can put together an example/comparison while i'm putting docs together over next week. if you have any suggestions for examples/demos etc. you would like to see please let me know.

[kizerkizer]

There's an "implementation" of node out there that just requires a syscall function to be supplied, and it builds all the standard modules on top of that. I forget what it's called. It's basically made for cases such as this; that is, "npm compatibility" for alternative JS runtimes.

[billywhizz]

There's an "implementation" of node out there that just requires a syscall function to be supplied, and it builds all the standard modules on top of that. I forget what it's called. It's basically made for cases such as this; that is, "npm compatibility" for alternative JS runtimes.

sounds interesting. let me know if you find it. all of that kind of thing should be possible in userland once i have modules and libraries system working well. i don't see higher level things like express, routing, middleware etc. ever being part of just core.

primary goal is for it to be a small simple and focused codebase that is easy to understand. one of my biggest bugbears these days is the proliferation of frameworks and platforms and when something goes wrong and you have to dig into the code you have a thousand layers of abstraction to wade to before you can see what is actually happening.

[billywhizz]

@pranaypratyush @kizerkizer i've been thinking on your npm support suggestion and in theory it would not be difficult to support the following:

• push just(js) modules into npm
• use npm to install them locally using a package.json
• have just(js) runtime find the packages under current directory in ./node_modules

i might have a look at this in coming days. let me know if you have any suggestions for what minimal level of npm support would be useful.

[kizerkizer]

The bigger barrier is compatibility with node, since most (?) npm modules assume the node API for filesystem, networking, etc. What you're suggesting would be nice too, since otherwise modules would have to be manually required. I'll try to find that library I mentioned in the other thread.

Again, I totally understand not integrating any of that into just(js), but eventually someone would do it in another project if this runtime became popular.

[vaaas]

My two cents, I am in favour of keeping this project as barebones as possible. If I want to use node, I can already use node. The parts of this project that interest me are not being node.

[billywhizz]

My two cents, I am in favour of keeping this project as barebones as possible. If I want to use node, I can already use node. The parts of this project that interest me are not being node.

Hi @vaaas. This is my position currently. Personally I have no great interest in node.js or npm compatibility, at least for now. It should be possible to work/experiment on something like this in userland and I am happy to aid any efforts to do so but I won't have the time or motivation personally to work on it and i don't really see it being part of core.

The focus of this project is very much about being a small, simple, fast, secure, easy to understand JS runtime/toolkit for server side applications mostly. It would also be useful for building command line tools and other system level software on Linux/*nixes. It won't be good for embedded/microcontroller work as v8 engine is a big resource hog but I have already done some useful experiments with implementing a kind of busybox runtime in JS that the kernel can boot straight into.

Also, there are a number of standards implemented/specced for JS that I am not overly interested in. e.g. Web Workers (there is a threading module in the runtime), ES Modules etc. Supporting these adds a huge amount of complexity to the codebase and little to no benefit for server side development as far as I can see.

So, to put it simply, I don't see this being a good platform for "full stack" development which is a key selling point of node.js. I think there is a gap in "the market" for a small fast and secure JS platform for lower level server side development that isn't currently being filled.

@kizerkizer would you be able to express what benefits you would see in particular from node.js compatibility? As @vaaas says, why not just use node.js? or are there issues you have with it that you think this platform could address?

I'll try to put this together more coherently in the docs I am writing up over next week or so. Is nice to see some interest - I have been hacking away on this on my own for quite some time now!

[pranaypratyush]

Very true. Mostly you need the core apis like http on which important things like ws can run. With that it's easy to build a minimal server framework or express. And ofc full compatibility isn't gonna be that much of a selling point as those people are content with node.js itself.

One of my use cases is actually to do SSR. As things get complex you are less likely to want to implement that in anything but js. Another would obviously be high-perf microservices. For that, I would like to see popular broker clients to work, but also brokerless systems like nanomsg.

[billywhizz]

@kizerkizer @pranaypratyush @vaaas i have put a little demo up here that walks through a benchmark for just if you are interested.

[episage]

For people trying to play with just I recommend starting off with the repl and inspecting just global variable.

> Object.keys(just)
[
  "print",
  "error",
  "load",
  "exit",
  "pid",
  "chdir",
  "sleep",
  "builtin",
  "memoryUsage",
  "version",
  "args",
  "opts",
  "vm",
  "loop",
  "fs",
  "net",
  "sys",
  "env",
  "config",
  "path",
  "factory",
  "process",
  "setTimeout",
  "setInterval",
  "clearInterval",
  "clearTimeout",
  "SystemError",
  "library",
  "requireNative",
  "require",
  "cpuUsage",
  "rUsage",
  "heapUsage",
  "hrtime"
]

[billywhizz]

I'll put some docs up over the weekend that should show the main api's. sorry!