Hi @billywhizz Am wondering... do you welcome submission of changes to the repository or wiki? Namely things like perhaps adding readme files (for examples, or anything), and possibly adding some pages to the Wiki for helping others (and benchmarks)? Would like to contribute in these ways if possible
and here are my benchmark results on my (slow) remote Ubuntu server:
RUST remote/live server:
ab -k -l -c 50 -n 10000 http://144.202.51.193:8081/
Requests per second: 351.73 [#/sec] (mean)
w/ c=250: Requests per second: 1582.45 [#/sec] (mean)
GO remote/live server:
ab -k -l -c 50 -n 10000 http://144.202.51.193:8081/
Requests per second: 349.72 [#/sec] (mean)
w/ c=250: Requests per second: 1567.35 [#/sec] (mean)
JustJS remote/live server:
ab -k -l -c 50 -n 10000 http://144.202.51.193:8888/
Requests per second: 346.26 [#/sec] (mean)
w/ c=250: Requests per second: 1588.87 [#/sec] (mean)
perfectly happy for you to do some submissions with docs/examples and have them included. i need to spend some time myself doing the same and adding tests etc.
btw. you should also be able to get vscode debugging working now: https://github.com/just-js/just/blob/main/VSCode.md#debugging-javascript
will likely crash a lot but useful for when you need it
@billywhizz Wondering if you can tell me if I'm doing the debugging correctly...
It seems it attaches to the process, but the breakpoints aren't getting hit. Here's what I'm doing:
-Open the JustJS Docker container in VSCode... and then in the terminal there, start the server with 'just --inspector server.js'
-Then, in a new VSCode window, I open any example project folder, and a .vscode/launch.json file with the configuration mentioned in the VSCode debugging link above...
-I then add some breakpoints in the new non-container VSCode instance/example, and run the configuration... (Attach to Remote) from this VSCode instance...
... hitting localhost:3000/json shows me content, but none of the breakpoints are getting hit. Is there anything wrong with the above approach?
It seems it attaches to the process, but the breakpoints aren't getting hit. Here's what I'm doing:
-Open the JustJS Docker container in VSCode... and then in the terminal there, start the server with 'just --inspector server.js'
-Then, in a new VSCode window, I open any example project folder, and a .vscode/launch.json file with the configuration mentioned in the VSCode debugging link above...
-I then add some breakpoints in the new non-container VSCode instance/example, and run the configuration... (Attach to Remote) from this VSCode instance...
... hitting localhost:3000/json shows me content, but none of the breakpoints are getting hit. Is there anything wrong with the above approach?
hmmm. you should be able to do everything in the same vscode session using the config i provided. it seems to have an issue when you set the breakpoints in the original source file. you need to wait until you see the loaded vm file pop up when the debugger is attached and set your breakpoint in that. i'll see if can do a screencast of me doing it here.
@rw3iss here is a little screencap i did of me debugging using the latest release in a remote container. https://billywhizz.io/sample.mp4
Thanks @billywhizz That helped... it looks like I have the .vscode folder inside of the .devcontainer folder, adn that's why I wasn't see VSCode prompt me for the run configurations when I went to the Run tab, which is why I thought to do it in a new/separate instance.. maybe I accidentally moved the folder, moving it back works and I'm able to debug... thank you :)
I'm assuming that is' ok to ask questions here, I've got two:
- Lets say I wrote a library that runs on node. With no dependencies. Can it run as is on
just? Will things like accessingprocess.env.NODE_ENVbe a problem? - What about
await? Doesjustsupport it?
- no it won't work on just. the api is completely different and i don't see it converging. it would likely be possible to write some kind of wrapper on top of just that would expose an nodejs compatible api but tbh not something i am very interested in at the moment. i'll go into some of the reasons why in more detail when i get a chance.
- async/await works and is part of ECMAScript/V8 so it comes out of the box. just does not currently support top level await but this would be possible, although i am not sure of a huge benefit.
@antonkatz yes, it sounds like if it is just standard javascript and uses little or none of the node.js libraries then it should work fine. anything that's using the standard out of the box JS like algorithms and data structures that would be common across browsers/node.js should be easy to "port". having said that, it is not going to be any faster or better on just as it's not using any of the node.js standard library.... if you want to send me a link to the code feel free and i can take a look.
for the env var above you would just do "just.env().NODE_ENV"
that makes sense given that in this case it's just V8 that's doing all the work, and both
node and just use the same V8
So the main use case for
just would be servers and IoT?
@antonkatz they would be good use cases. i'm not sure i could speculate too strongly on what it would be good or bad for. if it gains some traction i would hope people would find all sorts of uses for it i could never even imagine. the main benefits it brings to the table i think are simplicity and access to lower level fundamentals that are not available or difficult to get at on other JS and higher level language platforms.
and when i say simplicity i am talking about it in this sense: https://www.infoq.com/presentations/Simple-Made-Easy/. the runtime is simple. anyone with some basic knowledge of JS and C/C++ could look at the codebase and figure out very quickly what is actually going on. it has hardly any dependencies beyond the linux kernel and v8. imho, the problem with a lot of frameworks and platforms is they provide layers and layers of complex abstractions on top of what is actually happening at the system level. this leads to developer confusion, poor mental models and an inability to detect and diagnose production issues when they happen. this is a much bigger waste of time and resources than having to write a little more code or think a little longer up front the way i see it.
I guess, I shouldn't say good or bad use cases. Rather, what are the original use cases for the early adopters of
I would love to see a future for this project. Have you thought about "selling" it (free or not) to businesses?
just? I'm not going to start writing enterprise software with just yet because I'm limited for libraries that I can use. However, if I have very specific needs, eg. serving a website with limited functionality then I'll go for it.I would love to see a future for this project. Have you thought about "selling" it (free or not) to businesses?
PPS. I don't think it's a good use of time to create a node like interface, but would it be possible to execute certain pieces of code in
node and get back the result in just?
eg.
const res = node("./node-dependant-module").run("hello", "world")
i have been putting together a "useful" web framework which might be along the lines of what you are looking for. the goal with this is to put a more "realistic" entry in the techempower benchmarks, iron out any bugs/issues i find along the way and hopefully in next day or two i can share that and get some feedback on it.
right now, i have found it useful myself for writing small applications that do a specific thing and need low level access to system apis and good performance. things like packet filters, encryption/compression utilites etc. i have got a basic shell working inside a vm with js as the init process and no dependency on any other system applications. i've also got various libraries in various states of disrepair for postgres/sqlite/ffi/rocksdb/openssl and others.