hey there @Damien O'Hara... quick update, hope your holiday was great. see update below 🎄

Elide Runtime Progress (upd. Dec 27th, '22): • ✅ Language: Kotlin • ✅ Language: Java • ➡️ Language: JS ◦ ➡️ Intrinsics ▪︎ ✅ console ▪︎ ✅ base64 ▪︎ ➡️ Errors • ✅

ValueError

• ✅

TypeError

• ➡️ (All exception types) • ➡️ Guest VM exception bridge ▪︎ ➡️ URL Specification • ✅

URL

• ➡️

URLSearchParams

▪︎ 🕛 Abort Controller ▪︎ 🕛 Streams (Core) ▪︎ 🕛 Streams (Web) ▪︎ ➡️ Fetch API Specification • ➡️

Request

• ➡️

Response

• ➡️

Headers

• 🕛

fetch

▪︎ 🕛 Streaming React ▪︎ 🕛 TypeScript Runtime ◦ ➡️ Runtime ▪︎ ✅ Toolchain ▪︎ ✅ Embedded in image ▪︎ ➡️

esbuild

at runtime ▪︎ 🕛 TypeScript + JSX runtime (

tslib

, etc) ▪︎ 🕛 Source execution support for TypeScript: CLI + VM ◦ ➡️ CLI ▪︎ ✅ Hooked into JS VM v3 ▪︎ ✅ Intrinsics installed ▪︎ ✅ One-liner install script ▪︎ ✅ x86 macOS ▪︎ ✅ arm64 macOS ▪︎ ✅ x86 linux ▪︎ ✅ Ability to execute code snippets ▪︎ ✅ Ability to execute file scripts ▪︎ ✅ Ability to execute interactively ▪︎ ➡️ Distribution via Brew and apt-get ▪︎ ➡️ Terminal completions (zsh/bash) ▪︎ 🕛 Naked execute (

elide

) should drop into an interactive shell, like Node or Deno • 🕛 Language(s): Python, LLVM, Ruby

Elide Architecture.png

@Damien O'Hara elide architecture map just dropped 🙂

oh, also, you can now try out Elide with

npx run @elide-dev/elide@alpha

🙂 🚀

@suresh welcome 🙂 and happy new year! 🦜

i think it will be very fast, given the flatbuffer backing and i'm anticipating using LZ4 for compression -- but i'm concerned that a custom binary-only format makes inspection difficult for devs

i like that it's a standard tarball but maybe, for example, it should also have a JSON file, so that it can easily be inspected?

the steps at runtime, i'm thinking, are 1. if enabled in app configuration: a. load the tarball from JAR resources or file (it having been placed there by the Gradle plugin, or equivalent, modulo toolchain in use) b. look for magic # header, grab

crc32

and

compression

mode c. seek to beginning of

Tree

flatbuffer, load it into memory while decompressing, according to

compression

d. the

Tree

has the file tree and byte offsets for each file, which we have on hand now e. we load the data region as a

RandomAccessFile

, perhaps written to tmp f. the

Tree

and data region are used to build an in-memory JimFS filesystem, decompressing while we go g. at runtime, guest requests file via I/O: i. impl receives request, enforces security policies ii. allowed requests go to JimFS iii. JimFS serves it from memory in already-decompressed form tradeoff decisions proposed: • Init instead of runtime: load and decompress up-front so that file loading at runtime is instant, it's all already in memory • Emphasis on fast decompression: LZ4 won't save a ton of space, but it will also minimize impact on startup time to the greatest extent possible • Non-goal of pre-compressed browser assets: The assets subsystem already pre-compresses assets at build time, so it's a moot issue • Backed by well-tested code: After boot, JimFS kicks in which is well tested and performant (we don't have to deliver crazy runtime performance) • Streaming and copy-free: As much as possible, we shouldn't have to copy while initializing the runtime, which Flatbuffers and streaming compression deliver (for reference, this is the guest FS that will be used to load ESM, NPM, Python modules, etc).

sry let me put that in-thread

i think it will be very fast, given the flatbuffer backing and i'm anticipating using LZ4 for compression -- but i'm concerned that a custom binary-only format makes inspection difficult for devs i like that it's a standard tarball but maybe, for example, it should also have a JSON file, so that it can easily be inspected? the steps at runtime, i'm thinking, are 1. if enabled in app configuration: a. load the tarball from JAR resources or file (it having been placed there by the Gradle plugin, or equivalent, modulo toolchain in use) b. look for magic # header, grab

crc32

and

compression

mode c. seek to beginning of

Tree

flatbuffer, load it into memory while decompressing, according to

compression

d. the

Tree

has the file tree and byte offsets for each file, which we have on hand now e. verify the

Tree

by calculating the

crc32

and comparing it f. we load the data region as a

RandomAccessFile

, perhaps written to tmp g. the

Tree

and data region are used to build an in-memory JimFS filesystem, decompressing while we go i. while each file is decompressed, a checksum is calculated and compared h. at runtime, guest requests file via I/O: i. impl receives request, enforces security policies ii. allowed requests go to JimFS iii. JimFS serves it from memory in already-decompressed form tradeoff decisions proposed: • Init instead of runtime: load and decompress up-front so that file loading at runtime is instant, it's all already in memory • Emphasis on fast decompression: LZ4 won't save major space, but it will minimize the impact on startup time to the greatest extent possible • Non-goal of pre-compressed browser assets: The assets subsystem already pre-compresses assets at build time, so it's a moot issue • Backed by well-tested code: After boot, JimFS kicks in which is well tested and performant (we don't have to deliver crazy runtime performance) • Streaming and copy-free: As much as possible, we shouldn't have to copy while initializing the runtime, which Flatbuffers and streaming compression deliver (for reference, this is the guest FS that will be used to load ESM, NPM, Python modules, etc).

sorry the channel has been quiet, because of the rains on the west coast of the U.S. i was flooded out but i'm back at my desk! we should have a contributors guide ready in the next 48 hrs or so.

Screenshot 2023-01-11 at 8.33.09 PM.png

quick preview of the design for errors that surface in user code

errors: a comparison of js runtimes

PNG image.png,PNG image.png,PNG image.png

very strange behavior from deno tbh

hey guys, wanted to announce that a few changes will be made this evening (Sun Jan 15th, 2023) • the

v3

repo will be renamed to "elide" (the previous "elide" repo has been archived, it was v1/v2, which are now old) • github discussions will get activated • gitter and a button for this slack channel added to README separately, a test version of the CLI is out which has the error support shown above, plus a bunch of other goodies under testing. release coming soon. you can try it by running the one-line installer:

curl -sSL --tlsv1.2 dl.elide.dev/cli/install.sh | bash -s -

Elide's new website is built with Elide Elide's website is designed to be a paragon example of an Elide React SSR application. It is designed to be extremely fast, cheap to run, and quick/fun to develop on. At the same time, it demoes use of the latest web standards, like CSPv3, Trusted Types, and more. Features of the site basically break down into Performance/Experience, Security, and Dev. Performance/Experience ✅ Native React SSR (

view-source

to see it working!) ✅ Nearly perfect WebPageTest score ✅ Excellent Core Web Vitals ✅ Builds to a native amd64 binary ✅ Dynamic caching of SSR output ✅ Pre-compressed Brotli and Gzip SSR ✅ Profile-Guided Optimization (PGO) with GraalVM EE ✅ CDN with CloudFlare ✅ Modern image formats (webp, avif) ✅ Favicon that automatically changes based on dark/light mode ✅ Alpine (

musl

)-based binary and Docker image, in static mode Security ✅ CORP, COEP, CSPv3 ✅ Very strong CSP ✅ Script and source nonce sharing with JS VM ✅ A+ TLS rating ✅ Full suite of security headers ✅ DNSSEC Dev ✅ Builds as single optimized amd64 native binary ✅ Alpine-based Docker image (

<http://us-docker.pkg.dev/elide-fw/app/site:latest|us-docker.pkg.dev/elide-fw/app/site:latest>

if you want to try it out) ✅ Support for MDX via KotlinJS (very quick builds for site content) ✅ Plug-in support for customized

esbuild

(for SSR target)

Stats about the Docker Image The Docker image is especially interesting. It is a

FROM scratch

image which only contains the application binary, there is no Linux kernel -- so the app's UI, JavaScript, CSS, images, and Kotlin server code are all packaged into one runnable unit. ✅ 0 detectable vulnerabilities in Docker image ✅ Built with Alpine Linux, GraalVM ✅ Completely static binary (

FROM scratch

) ✅ Size: 137.3MB (!)

big day for the framework tomorrow

get ready yall wish me luck

good morning all

good morning (two days later)

hello all

i am happy to announce that Elide is finally available on Maven Central https://central.sonatype.com/search?namespace=dev.elide

is the latest version -- the BOM and the Gradle Catalog are the only two components which are missing at this time

(publishing those to central can be a pain, they should be live in a day or two)