This week, I wrote about using the CSS @import rule to modularize CSS, and some performance challenges with that approach.
tl;dr: the issue isn't the @import rule itself, but that files under 1kb often end up the same size or even bigger when gzipped, so you get no compression benefits.
I ran a few additional tests, and wanted to share the data I found.
kelp.css file hosted on JSDelivr
| accordion-group { | |
| background-color: #f7f7f7; | |
| border-radius: 0.25em; | |
| display: block; | |
| margin-block-end: 1.5em; | |
| padding: 0.5em 1em; | |
| width: 100%; | |
| } | |
| accordion-group [accordion-trigger] { |
| import Database from 'better-sqlite3'; | |
| import { createDatabaseClient } from './proxy.ts'; | |
| // 1) Create an in-memory DB and your table(s). | |
| const db = new Database(':memory:'); | |
| db.exec(` | |
| CREATE TABLE users ( | |
| id TEXT PRIMARY KEY, | |
| data JSON | |
| ); |
| var client = window.client = new WebTorrent({ | |
| tracker: { | |
| rtcConfig: rtcConfig | |
| } | |
| }) | |
| client.on('warning', onWarning) | |
| client.on('error', onError) | |
| torrent = client.add(TORRENT, onTorrent) |
FFlate is the fastest, smallest, and most effective JavaScript compressor/decompressor currently; to create it, I used a variety of modified or optimized algorithms.
The core of most popular compressed file formats is DEFLATE, or RFC1951. GZIP data, Zlib data, .zip files, PNG images, and more all use some variant of DEFLATE under the hood. At its core, the DEFLATE format is actually not too complex: it's merely a combination of Huffman coding and LZ77 compression.
If you don't understand either of these concepts, feel free to read the following subsections, or skip to Part 2 if you already know what these are and just want to get to implementation details.
Computers think of basically everything as numbers. The smallest unit of information in a computer is a single bit, which can only be either a 0 or a 1. When multiple bits are stringed together, they can be interpreted as a ba
| async function forceSync(account: Account) { | |
| const { syncManager } = account._raw.core.node; | |
| const peer = Object.values(syncManager.peers)[0]; | |
| if (!peer) { | |
| throw new Error("no peer"); | |
| } | |
| const values = Object.values(account._raw.core.node.coValues).flatMap((x) => { | |
| if ("coValue" in x.state) { |
| /** | |
| * Returns PBKDF2 derived key from supplied password. | |
| * | |
| * Stored key can subsequently be used to verify that a password matches the original password used | |
| * to derive the key, using pbkdf2Verify(). | |
| * | |
| * @param {String} password - Password to be hashed using key derivation function. | |
| * @param {Number} [iterations=1e6] - Number of iterations of HMAC function to apply. | |
| * @returns {String} Derived key as base64 string. | |
| * |
So you want to write a sync system for a web app with offline and realtime support? Good luck. You might find the following resources useful.
Database in a browser, a spec (Stepan Parunashvili)
What problem are we trying to solve with a sync system?
The web of tomorrow (Nikita Prokopov)
UPDATE working on this here!
so… I've had this weird idea recently...
In git (and in other secure + distributed systems) you have a tree of hashes where each object is identified by it's hash and objects contain pointers to other objects. They just have the hash of other objects stored inside them.
[!NOTE] Progress on work. Don't rush.
It's Friday. I have a rough timeline for my work with XXX and we're discussing the specifics. I'm feeling tired, but not burned out. I feel like I have balance. I published every day. I learned something new (a piece of tech/concept) and I wrote about it. We planned our trip to XXX. I've spoken with my brothers.