JavaScript interpeters...
In recent years, we have witnessed significant evolution in JavaScript interpreters on the server side. One after another, they have emerged, each bringing improvements and unique qualities compared to its predecessor. Each of them is striving for something different: performance, ease of coding, scalability, and more. Among the various newcomers, there is Bun. This new yet formidable competitor has made tremendous strides in terms of development speed and operational performance 😬.
Why bun? 🤔
To describe Bun, we could use various terms, although the most appropriate one might be 'framework.' Bun is conceived as an all-in-one toolkit; this 'toolkit,' as its creators call it, is a bit broader than it might seem. Bun offers much more than other interpreters could or dare to. It functions as a package manager, a testing environment, a runtime environment, and a bundler (Webpack? Not needed with Bun). This, coupled with execution speeds that seem instantaneous and package installations even 10X (or more) faster compared to other dependency managers, puts Bun on the radar of many developers today.
Other features that make Bun unique include 🌟:
Backward compatibility with Node.js: Bun allows for easy migration of existing projects created under Node.js, ensuring interoperability between versions and, at the same time, promising to enhance existing speeds ⏩.
Enables code writing and compatibility with TS, JSX, TSX, JS files.
Bun is more than a runtime. The long-term goal is to be a cohesive, infrastructural toolkit for building apps with JavaScript/TypeScript, including a package manager, transpiler, bundler, script runner, test runner, and more.
Bun/Docs
EX-
With this background, let's get down to the nitty-gritty: how to use it, how to achieve tasks we used to do with other tools, starting with the most common one—setting up a web server (something akin to Express and Node.js). Although there are already frameworks to 'simplify' the process even further with Bun, we will explore how to do it natively, easily, and succinctly with what Bun provides.
First Step
Before we dive into Bun, we need to make sure it's installed. There are several ways to install it, and here's how:
Linux/MacOs:
curl -fsSL https://bun.sh/install | bash
Homebrew:
brew tap oven-sh/bun
brew install bun
Once installed, we will kick off our project as follows:
Server initialization
To initialize our HTTP server with Bun, we can do so by writing the code directly in our index.ts file.
This is the basic way to set up our native server in Bun. In this case, any request reaching the server's base path will receive the same response: 'Example response.' But what if we want to handle more requests? More paths?
This looks a bit better, but is it the best way? Of course not. There isn't a specific way that is the best, but we can certainly strive for it. Here's a new approach:
- All routes should have at least a path and a handler. Knowing this, we can create an interface to represent our APIs.
- With our schema in place, we can generate a handler function capable of representing a switch between the various APIs we want to expose, something like this:
- With this function, we can store our routes dynamically, allowing us to grow in terms of routes and APIs as much as we want to implement.
How to use our handler function?
With this, it's enough to utilize our handler function, opening the door to various implementations. This solution is just one of many, with possible shortcomings and improvements, such as replacing the recurring array search with a switch statement. Nevertheless, it's just an approach to the flexibility and possibilities that Bun opens up for us as developers. Finally, to run our Bun server, it will be sufficient to execute the command [bun run ./src/index.ts]. Below, you'll find the link to the project on GitHub with the project structure and various implementations for our handler function.
Top comments (0)