Running JavaScript Actually Everywhere

JavaScript has an amazing ecosystem. I'm able to hack on a mobile application with React Native or Expo in seconds. And if I want to develop desktop applications, I can do it with Tauri or Electron. And I also can write server application servers code with either Deno, Node.js, or bin.

But there is not a single runtime which allows me to port my server logic onto the mobile and viz versa. For instance, let's say that I have an NPM module dedicated to cryptographic work. It does some CPU-intensive work, file system operation, and interact with the network stack. I use it on my back end, and I really need to reuse it and reuse that core logic as a backend.

I can't port that logic directly into a React Native application. So if I use Deno, Node.js, or bin, I won't be able to port the logic directly into React Native. And on the other side, I cannot hire a native developer to reimplement that logic in Swift or Kotlin. And then write a binding to React Native, because it will cost me a lot of money. And maybe I have a lot of JavaScript developers in my team, and I cannot hire this kind of specific profile.

And I would like to push myself to ask a question. Mobile is everywhere. Over 90% of mobile time is spent in apps and not in browsers. And for the next billion users, the smartphone is the entire Internet. And then running code natively on low-end devices is not an option. It's necessary because everyone has a phone in their pocket. And it's like the real devices where you have to be, even in JavaScript.

So I asked myself why Node.js, Deno.js, or bin.js does not run on mobile. And before really seeing that, let's just do a quick check. So in that table, I tried to compare Node.js, Deno.js, and bin.js when it comes to mobile. So first, we'll see that Deno.js and bin.js are out of the scope. There are still Node.js mobile packages, which are third-party packages not maintained by the core maintainers or by Node.js itself. The real bad point with that is that when you want to embed your Node.js code, you have to bring the whole Node.js codebase.

Also, it supports React Native, not Expo, and also it didn't have a kind of native integration with iOS or Android, for instance. Let's try to take a look at Bear now. So Bear is a modern runtime. And by design, we can use Bear on iOS and Android. It supports different kinds of engines. And regarding the framework support, it supports React Native, Expo, and also has native integration. And the really big difference is that you can finally opt into your module.

And regarding the framework support, it supports React Native, Expo, and also has native integration. And the really big difference is that you can finally opt into your module. So you didn't have to bring stuff like OS module or performance module if you don't need it in your project. So, yeah, it sounds like Bear could be a good deal for my use case.

Now, how to consume Bear from React Native? So I just have to install React Native BearKit in my project. It will let me use Bear runtime directly. So now we'll try to see which API we can use. So first, I would like to cover two concepts that come with Bear. The first one is Worklet.

So you will see in the documentation when you want to use Bear in a native environment, on desktop, or on mobile, we'll see this concept of Worklet. It's more or less the same thing as a worker. We just differentiate with that term because we have a Bear worker project and we don't want to make confusion with that one. But it's almost the same. It will be something that will run in background. So if you have your React Native application, on the other side, you have the Bear Worklet.

And between both, you will be able to communicate using IPC. So let's see how it works in terms of code. So we have this little snippet. First, you have to import React Native BearKit. Then your bundle. So the bundle, I will explain what it is a bit later. So it's just like your Worklet code, mostly. Then you have to create a Worklet as a class, right? And then you just pass your bundle as a parameter and you give also a name to your Worklet.

And on the Worklet side, it's really similar. So what you could do is you can get the IPC object from the BearKit global object, which is exposed by definition. And then, as any event emitter API, you can listen on data. So each time that the React Native side will send messages, you can get them from here. And you could also write messages. So really basic IPC stuff.

And then, on the React Native side, you have the same API. So remember that Worklet object that we created? You can get the IPC object from there. And same API, like you can listen on data or you could write directly into the IPC. And if you want, there is some abstraction that you can use on top of that Raw IPC to make your life easier. For instance, we have BearRPC. We will have remote procedure call on top of this Raw IPC. And we are FramedStream, just in case you want to frame your IPC stream. And that thing sounds like a detail, but it's a really important aspect of the Bear philosophy, which is bring what you need when you need it. When you bring BearKit into your project, it will expose the minimalist API you need.

And for the rest, you can add modules on top of that. And I will give you much details about that later. So I mentioned Bundle. And it's really important to know that Bundle is more or less like a zip archive. It's just a zip archive for JavaScript module, which will support files like packages or native add-ons. And as I said, in Bear, you pick up and you hopped in for the modules that you want. It will just change your Bundle size. And when you have your worklet ready with all the code and dependencies that you need, we have some command that you will find in the documentation to bundle your worklet. And it will just bring the dependencies that you need. And if you don't need, as I said, the file system, then we won't bring those API. If you didn't need HTTP, we won't bring that into your worklet. You will only get the code that you need.

So it's time for a little demo. So let's try to... Yes, so here, I just cloned the Bear Expo repo, which already integrated React Native BearKit with Expo. So you could just clone that repo. Do a npm install like I did. And then you run npm run ios because I use the simulator of ios here. So now I will open this index.js. So first thing is that we, as we saw, we import a worklet from React Native BearKit. And then the component will just print a response that will be a string, right? So nothing fancy here. And so we have the worklet code that could be a separate file, but here I just pass a string. Then we pass that string to the start function and we give him a file name. It will be really useful when you want to debug, by the way. And then we will listen on data and set the response. And on the other side, we'll just write a message. And normally on the IPC on React Native, it will just change the state of the component. You should see the result directly into the application. So it seems that the build is over now. So the app will open and boom.

There is the welcome from bear, which is the string that was in the worklet. And React Native listens through the IPC data events and it gets the data and it just displays it into the application. So, yeah. So, yeah, you should try the runtime, which actually runs everywhere. So really easy if you want to use Bear locally to do a few tests. You can do npm i g bear and it will install on your machine.

Let's see what is the philosophy which comes with bear. We already mentioned a few points, but I will go through each of these. So first, less is more. We have a small core. The runtime itself is built like that. So it just brings the necessary bits to run. It won't bring the network stack. It won't bring performance and observability stuff. Just what is needed to run a JavaScript.

All bricks are separated, really, with this Linux-Unix philosophy. A lot of time we observe that doing less is really better for performance. As we have a small core, we can bring only what we need. It will avoid having a bloated bundle with a lot of stuff that we don't need. It will load binaries like bear-ttp or bear-rocker only if you opt-in by adding them into the package JSON. Bear could be compiled on top of various engines, V8, GSC, Quick JS, or even Javascript for stuff like IoT.

And also, bear could be compiled on top of various engines. So V8, GSC, Quick JS or even Javascript for stuff like IoT. So we didn't take one engine and just use that one. We create a system that could let you recompile bear with the engine that you want. And by default, it's V8.

Now let's go through a few features. BUNs run everywhere. It runs on servers and CLI like Node-DO. It runs on desktop with Electron. It runs on native desktop like Linux or Mac OS. It runs on React Native and Expo. It runs on native mobile like iOS and Android. It runs on native mobile like iOS and Android directly with BearKit. It also runs on IoT with dedicated Javascript engine that didn't have too much footprint to your program.

Also, we are Node.js compatible. Any system API that you have on Node.js, we also have an equivalent module on Bear. Just you have to install it in your package. You can create modules that will run on both. You can also migrate a Node.js project and add a layer to support Bear. We have plenty of modules that support that, like bear-process, bear-fs, and all the modules available. We provide a template to start your own native add-on, supporting all the NAPI from Node.js symbol. We have gstl on the native add-on side, streamlining the development of add-ons without specific logic.

Native add-on, we provide a template to start your own native add-on. We bring the world build machinery. You just have to follow the doc and run three comments and it works. Also, we support all the NAPI from Node.js symbol. And when you create a Bear add-on, you can target Bear, but you can also target Node, which is pretty nice. Also, we have gstl on the native add-on side, which is an API that streamlines the development of add-ons. And it gets rid of any ng-specific logic. So you interact with an API without relying on JavaScript core internal or v8 internals. And it means also that you can build an add-on on the engine that you like. So it tends to mimix the JavaScript signature of your binding.

For instance, here on the binding side, we have a stream, which is a buffer, and you pass directly the buffer here. You didn't have to handle an array, take the first argument, verify its type like you do on Node.js, for instance. And for instance, as a second argument, we have an id, which is an int and then a number on the JavaScript side. So really easy to use. It deletes a ton of boilerplate code. It's really nice to use. Then you can have also a single executable application. So you can package your JavaScript code as a native application bundle or a standalone executable for both desktop and mobile. And you have the Bear build project to do that.

Then you will forget the anxiety of upgrading. Bear provides no standard library beyond the core JavaScript type APIs available through Bear namespace. Built-in modules like file system are separate modules like Bear FS, so you have control over your code. Legacy libraries can be gracefully upgraded as needed along the way, allowing your codebase to be refactored, upgraded in sync with your code. So upgrading Bear will never break your heart. Also, a really important point is that we love Node.js, right? Bear is not the work of people that wanted a new node. This is the work of people who reached a certain limit of the runtime and wanted to push it further with a new architecture, and mobile and IoT are a really good example.