aws-gocljs VS lowtechguys

i make two kinds of websites:

- static. markdown rendered to html using github’s api[1].

- dynamic. a go binary and an html file with inlined js zipped together and shipped somewhere[2].

it’s nice to never consider the machinery of either of these anymore. instead i think about building interesting things.

1.

https://github.com/nathants/render

https://nathants.com/

2.

https://github.com/nathants/aws-gocljs

https://gocljs.nathants.com/

have you tried cljs and reagent? it’s a different vibe.

my bootstrap: https://github.com/nathants/aws-gocljs

the project: https://reagent-project.github.io/

https://gocljs.nathants.com is 300kb gzipped on deploy in a single html file. setup is here: https://github.com/nathants/aws-gocljs.

aws, go, and clojurescript.

go is notoriously boring.

the reagent api for clojurescript hasn’t changed in a decade, though recent things like shadow-cljs do improve qol.

aws releases services with 2 in their name instead of changing existing ones. the old boring service will plod along forever.

aws apigateway v2 is much better, but i have many deployed projects i will never migrate because they are fine on v1.

i do it like this: https://github.com/nathants/aws-gocljs

lambdas updatecode api takes less than a second. using container instead of a zip for lambda has advantages, but speed is not one of them.

i auto rebuild my go zip and patch aws on every code change. it’s done before i alt tab and curl.

script: https://github.com/nathants/aws-gocljs/blob/master/bin/dev.s...

lambda + s3. add ec2 spot if you need it.

just make sure you understand how billing works. mostly it’s just egress bandwidth is expensive.

do something like this:

https://github.com/nathants/aws-gocljs

or with less opinions:

https://github.com/nathants/libaws/tree/master/examples/simp...

welcome to cloud, glhf!

using remote resources as a part of your local dev flow can be very useful if your local environment is constrained on:

- upload and/or download bandwidth

- cpu/ram/gpu/ssd

this can be as simple as an ephemeral ec2 spot machine that reacts every time files on it’s filesystem change. it then does stuff, like building and shipping.

your local setup then needs to rsync files from local to remote every time you save a file.

i’m on an upload constrained setup right now, and this[1] significantly speeds up my iterations uploading lambda zips.

fancier setups probably are similarly advantageous, but add tradeoffs proportional to their complexity.

1. https://github.com/nathants/aws-gocljs/blob/258ea5bb72d06a50...

go, clojurescript, and aws. all three of these have problems, but like linux are the least bad of the available options. from some angles they are even quite good.

- go, a natural fit for backend with types and compilers and speed

- clojurescript (and react via reagent), a natural fit for frontend with dynamism, flexibility, and data centrism

- aws, a natural fit for infra. like linux, literally everyone is using it. if you avoid architect advice and tape over most of the knobs it’s quite good

example:

https://github.com/nathants/aws-gocljs

on aws as scale to zero services. lambda, dynamo, s3, and ephemeral ec2 spot.

when egress bandwidth is needed i use cloudflare workers + r2 just like i would use s3 presigned urls.

typically i start from a full project template[1][2]. sometimes i start from scratch[3].

1. https://github.com/nathants/aws-gocljs

2. https://github.com/nathants/aws-exec

3. https://github.com/nathants/libaws

I use something very similar on https://lunar.fyi and https://lowtechguys.com but I wouldn’t call this “simple” anymore.

They use Jinja templating, I prefer Slim (https://github.com/slim-template/slim#syntax-example) which has a more Pythonic syntax (there is plim [0] in Python for that)

I use Tailwind as well for terse styling and fast experimentation (allows me to write a darkMode-aware and responsive 100 line CSS in a single line with about 10 classes)

For interaction I can write CoffeeScript directly in the page [1] and have it compiled by plim.

I run a Caddy static server [2] and use Syncthing [3] to have every file save deployed instantly to my Hetzner server.

I use entr [4] and livereloadx [5] to rebuild the pages and do hot reload on file save. All the commands are managed in a simple Makefile [6]

———

You can already see how the footnotes take up a large chunk of this comment, this is not my idea of simple. Sure, the end result is readable static HTML and I never have to fight obscure React errors, but it’s a high effort setup for starters.

Simple for me would be: write markdown files for pages, a simple CSS for general styling (should be optional), click to deploy on my domain. Images should automatically be resized to multiple sizes and optimized, videos re-encoded for smaller filesize etc.

I have mostly implemented that for myself (https://notes.alinpanaitiu.com/How%20I%20write%20this%20blog...) but it feels fragile. I’d rather pay for a professional solution.

[0] https://plim.readthedocs.io/en/latest/

[1] https://github.com/FuzzyIdeas/lowtechguys/blob/main/src/rcmd...

[2] https://caddyserver.com/docs/command-line#caddy-file-server

[3] https://syncthing.net

[4] https://github.com/eradman/entr

[5] https://nitoyon.github.io/livereloadx/

[6] https://github.com/FuzzyIdeas/lowtechguys/blob/main/Makefile

One less known use case for this is creating animated UI demos, which as a dev I find harder to do using video editing software.

I used it to create the simple demo on the rcmd frontpage: https://lowtechguys.com/rcmd

This is the code, where I'm just animating elements of an SVG I previously created with Sketch: https://github.com/FuzzyIdeas/lowtechguys/blob/main/src/rcmd...

I'm also doing the same thing for the Lunar frontpage: https://lunar.fyi/

But because Lunar's demo is a lot more resource intensive, I pre-rendered it into a video, and heavily optimized it for each screen size, in H.265, WEBM and H.264.