Reloading... 0.0s

Metal

Vapor, Reverb, Canopy all run on Metal, there is no need for Docker Containers or Runtimes.

It runs on my Machine!

As we all know, switching machines, or having to reinstall megabytes of dependencies is a pain, and eventually leads to the dreaded "It works on my machine" problem. Running a static blog shouldn’t require an entire runtime environment, build chain, and container stack. Nor should a full-stack app.

The framework that is installed on one machine should run deterministically on another. Every current JS framework or other framework currently ships dependencies. And there is no way to avoid them.

Binary

Metal is how Vapor, Reverb and Canopy, compile and build the binaries. Depending on persmissions, Vapor will use wasm-opt and brotli, to compress the WASM binaries, this will reduce the total bundle size. For example, the raw WASM binary of this site it 7MB, after compressing using Metal, we result in 180kb total. While other frameworks may ship 100kb-200kb by default. Remember Vapor, is running WASM, so the browser not only parses this 10x-20x faster, but also runs 1.5x-2x faster. And again, we only have one binary file running the Vapor server, and one vapor.wasm file which contains our UI, and client side functionality.

Total file count

  • Vapor: server.exe, vapor.wasm, bundle.min.js

  • Reverb: server.exe

  • Canopy: server.exe

Caveat

Alot of people are going to tell you that, Yes WASM is faster, but the overhead, between JS bridging to WASM, kills your performace. This claim is valid, however the amount of time to bridge between WASM and JS is 10ns so you would need to perform over 10,000,000 operations to hit and overhead of 1 second. Moving string around costs anywhere from hundreds of nanoseconds up to a few milliseconds, because of size. You pay for the linear encoding, due UTF-8 and UTF-16 differences. However, WASM is contionously being improved and changed, in the next year or so, a new model will be release, where no copying will be needed. And you will be able to interact with JS string and object without the need of crossing a 'bridge' ie negligible cost. One very simple way to not cross this boundary a ton, is just batch. Vapor does this by default.

Commands

Metal is a CLI tool, and it has a lot of commands. You can run metal --help to see all the commands.

Every command is run within the current directory. You can specify a output path with the -o flag.

Metal differentiates between Vapor, Reverb, and Canopy, with -v, -r, and -c flags. After this, you can run various generation commands, like metal -v create my-app or metal -v gen DataTable.

Vapor Gen Command

When passing the gen command, we can generate various component types, like DataTable. We can also generate Form components, based on a struct argument. For example, Vaporize can be used to generate the base Form UI, and then one can mutate the styles, or add custom logic. This is useful for rapid prototyping.

Reverb Gen Command

We follow the same pattern as Vapor, with Reverb, we can generate cruds, routes, auth, and more.

Release & Deployment Commands

We can release with Metal, via:

This will generate various types of files, based on the mode. For Vapor specifically, release-mode small and fast, will run the wasm-opt and brotli commands. This will further compress the WASM binary, reaching an average 40x reduction in size.

Vapor's server runs on Reverb, and so we get all the performance benefits of Reverb, by default.

Vapor also takes the pre-gen command, which at build time, will generate a static HTML files, and serve them on initial request, then following up with the WASM binary, this improves the first paint time, and reduces the time to first byte.

Senet

Docs

On this page