Hazel Weakly hazelweakly

But yeah, how the css works in my site:

https://github.com/hazelweakly/hazelweakly.me/blob/main/tailwind.config.js#L25

^-- This is the tailwind config and does some fun stuff in there to use like utopia "natively" in tailwind classes, n such.

https://github.com/hazelweakly/hazelweakly.me/blob/main/postcss.config.js#L17

^-- This configures all the CSS purging, minimizing, bundling, bla bla. Mostly so that you can put your entire design token setup and component lib into the site and only pay for what you use.

A nix link dump:

The nix documentation is still getting polished up, but it's much more approachable than it used to be. (This should both delight you and fill you with mild trepidation).

Start here

https://www.haskellforall.com/2022/08/stop-calling-everything-nix.html
https://nix.dev/tutorials/nix-language
alternative intro crash course (in the style of X-in-60-minutes): https://github.com/tazjin/nix-1p

The tl;dr would be "otel-js should look much more like tracing from the rust ecosystem or otel from ruby, and less like otel from the java ecosystem." I think a lot of the friction of otel-js comes from two main areas: not writing a library that takes advantage of most modern conveniences, and writing one that doesn't take into account most peoples use-cases.

Some high level points:

JS has essentially 4 main splits. You have front-end vs back-end, and toolchain vs "raw JS". Importantly, these are often not exclusive camps.
Many JS codebases run on the frontend and the backend with the same code; this is extremely difficult currently and brings almost all of the pain points into full display immediately.
Ergonomically speaking, the library feels like a very low-level library for building a real otel library out of, but it isn't, and there isn't a high level one.
Lastly, the most important style of documentation here is going to be (imo) copy-pasta cookbooks; this is almost entirely missing from o

	# Of all the reasons why I like nix, the ability and ergonomics in which I can do this
	# are high on the list of compelling examples, in my opinion.
	{
	description = "nix shenanigans";

	inputs = {
	nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
	flake-utils.url = "github:numtide/flake-utils";
	};

	<!DOCTYPE html>
	<meta charset="utf-8" />
	<title>Redirecting to the Fediverse</title>
	<head>
	<script>
	// let's say this is hosted at example.com. Given a url of one of the forms:
	// - example.com/@[email protected]/post_id
	// - example.com/@[email protected]
	// - example.com/@instance.com
	// redirect accordingly

	import {
	Attributes,
	Span,
	SpanContext,
	SpanOptions,
	SpanStatusCode,
	trace,
	} from "@opentelemetry/api";

	export const serviceName = process.env.SERVICE_NAME ?? "o11y-demo-app-front-end";

	#include "arithmetic_utilities.h"
	#include <cstdlib>

	// Honestly kinda not seeing why most of these helper functions are a thing if
	// they're all one liners. Most C++ codebases avoid that since the overhead of
	// calling functions is huge compared to just writing the oneliner.

	/**
	* convert char array into a number using the atoi
	* @param char* arr

	font_family Fira Code
	bold_font auto
	italic_font auto
	bold_italic_font auto
	font_size 10.0

	cursor #cccccc
	cursor_text_color #111111

	cursor_shape beam

	function! VimrcLoadPlugins()
	" Install Dein.vim if not available
	if &runtimepath !~# '/dein.vim'
	let s:dein_dir = expand('~/.cache/dein/repos/github.com/Shougo/dein.vim')

	if !isdirectory(s:dein_dir)
	call system('git clone https://github.com/Shougo/dein.vim ' . shellescape(s:dein_dir))
	endif

	execute 'set runtimepath^=' . s:dein_dir