@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.
@billywhizz: Thanks for the good API Examples for v8 and the Benchmarks i was aware that libuv slows down NodeJS i saw that via heatmaps and Also the GraalVM Demo of ES4X Showed that. But your Research results are awsome i will expand on that i just started fixing the libv8 builds so that they are less redundant and clean. I am Also working on some General Patterns and Documenting them.
Out of my view this solves a big usecase (Micro services) as this enables to Produce JS v8 Isolates. I was Working with GraalVM and DENO to reduce the needed layers but i was by far not as successfull as you,
If you need anything or got any plans feel free to msg me until then. Thanks for all that great Examples.
@frank-dspeed:matrix.org : thanks for the comments. am definitely interested in hearing what you would find it useful for. i'm hopeful i can get back to coding on it some more in next few weeks but free to chat/discuss online if you have any questions/ideas. i'll keep an eye on here over next few days.
@viskogurl if the pace of development is not to your liking you are free to build your own "useful" frameworks on top of what is already there. the one i am working on will not be part of core and will be an external third party module. there's nothing stopping you doing the same. this is a system-level framework, not another batteries included all singing all dancing mess like node.js. you're welcome.
@billywhizz Okay, thanks. To be clear, I wasn't meaning the framework you built was unuseful. I was referring to your previous message where you stated 'i have been putting together a "useful" web framework' so I was just looking for an update since this community isn't very active and the last update I could find on github was from February. Thanks for the info.
i'm sorry if i was a little short - i read it the wrong way and thanks for clarifying. if you want to check out the in-progress latest you should be able to with the recent 0.1.1 release. the updated techempower project is using the new code which has a "useful" api. still working on this but not too far away having something stable and fast now. https://github.com/just-js/techempower/blob/main/techempower.js. justify and pg libs are now much more streamlined and hopefully easier to use. at moment i am trying to clean up codebase and write some docs.
once i get over this hump it should hopefully be easier to get other people involved if interest is there and plan out some kind of roadmap to a 1.0 release.
It's no problem! I didn't structure my message very well so that was my fault.
Awesome! I've been extremely excited to try it out so thank you for sharing the techempower.js server file and the justify library. The Justify syntax should be a breeze to learn for anyone coming from Express so I'm hoping JustJs will start attracting some of that crowd soon :)
Do you have any plans to add MacOS or Windows support? I know almost all the servers in the world run on Linux but I just thought it might be easier to get more people on the JustJs train if it was easier for developers to jump right in without having to configure WSL on Windows or a VM on MacOS. I'm currently a little busy right not but I would gladly help implementing it sometime soon if that's something you'd be interested in down the road.
@viskogurl no plans for cross platform at the moment. maybe once it gets to a nice stable release on linux/x86_64 can start looking at what would be possible in terms of porting to other platforms. happy to help with any effort others want to make down this road but probably best until api/features etc. have stabilised first. porting to linux on arm/i386/risc-v shouldn't be very difficult. porting to BSD/MacOS should be a little more difficult but not too daunting (although i have little experience of this myself) imho. windows support i would imagine will involve a lot of work.
one thing i would like to avoid is what the codebase for most cross-platform projects looks like - full of macros and #ifdefs which imho gets in way of understanding and reasoning about the code. so there's a tradeoff there that i am happy to discuss but don't want to take any firm decisions on yet.
as a server side/system utility platform (which is what i see it as currently) i think linux on x86_64 is a good starting point for deployment. for development, is possible to seamlessly run docker in vscode (https://code.visualstudio.com/docs/remote/containers) and use browser based ide's like gitpod if folks are on mac/windows machines.
if anybody is interested in taking a look at macOS portability i am happy to be involved as i do realise that is a desktop/laptop platform a lot of backend devs like. but i don't have much experience with BSD/macOS api's so would have to do a lot of catching up which i just don't have time for right now.
Ahh I see. Would it be better to just create a branch for MacOS and Windows support so there aren't all the macros and #ifdefs when the time comes?
I totally agree that Linux is the best option for a production app. I'm currently on MacOS but I'm not very good with Docker so I'll see what I can do about adding a development environment for Mac. What exactly about JustJs is strictly Linux? Is it only because it uses epoll instead of kqueue for the event loop?
Sorry for all the questions. I can just do some more digging in the source code if you don't currently have the time to respond :)
or there are github discussions now too
re. linux - all the c code and system api's are linux specific at moment. there are lots of constants defined which are linux specific. it's an area i need to do some more research in and tbh cross-platform not a big priority for me right now. one of main goals is codebase should be easy for someone with some basic C/C++ knowledge and a vague understanding of linux system apis.
i have spent a lot of years working on node.js projects and digging into problems/bugs/weird behaviour is very difficult because of the layers and layers of complexity in the codebase. a lot of that complexity imho comes from the desire to be all things to everyone. that's fine - node.js is really good at being that, but it comes at a cost.
i love javascript and i love the linux system apis and i think the combination of those two in a very simple, easy to understand and reason about framework is something a lot of people might found useful, especially when you consider most server software these days is deployed on linux whether it is virtualised or not. i don't see that changing a lot in years ahead - if anything, it will become more the norm.
the big issue, as you point out, is ease of development when most devs are on either macOS or windows as their main machines. i use ubuntu myself but i'm not under any illusions that linux on the desktop is going to become the norm anytime soon, if ever.
so, open to suggestions discussion around this while being quite firm i don't want to "waste time" worrying about cross platform too much until i get close to a 1.0 stable release of the system that has a reasonable standard library on linux.
having said all of the above i don't think making this work on other platforms would be an enormous effort as the codebase is quite small. but probably best to wait for that until we get a nice stable api and then can have a look at that and make better decisions on what would need to change in order to allow it to be ported more easily.