aws-gocljs VS helix

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

In short, performance, easier interop with JS react libraries, better static analysis, and being able to use modern React features. For more details, see https://github.com/lilactown/helix/blob/master/docs/motivation.md and https://github.com/lilactown/helix/blob/master/docs/faq.md#what-about-hiccup. It's also worth checking this blog post: https://fbeyer.com/posts/refx-origins/

You can ignore the malli/react-hook-form part - the relevant parts are the entry namespace and the shadow-cljs config. This example uses https://github.com/lilactown/helix (great tutorial here https://github.com/iwrotesomecode/react-docs-helix) but you can use reagent if you wish. I think this should meet your requirements. You can inline your data in the cljs bundle as data and add UI via react components.

[1] https://github.com/lilactown/helix [2] https://github.com/ferdinand-beyer/refx

> But Reagent supports functional components as well, with hooks and all.

I addressed this already: while reagent is able to emit function components, there is a performance penalty to this.[1]

> I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that.

Hiccup is convenient to write, but it is a constant run-time cost and a significant storage cost given that you have to store long series of constructors to cljs.core.PersistentVector in your bundle, have the JS runtime actually construct the vector, then pass it through a Hiccup interpreter to finally produce DOM nodes and throw away the persistent vector, only to repeat this entire process again on re-render.[2]

> Helix has decided not to support that.

That is simply not true. From the Helix documentation[2],

> If you want to use libraries like sablono, hicada or even hx hiccup parser, you can easily add that by creating a custom macro.

These are all Hiccup interpreters you can readily use.

IME there is very little difference between using the $ macro in Helix and writing Hiccup. I do not really miss Hiccup when I use Helix, and you still have data as code ;)

While this is from an unrelated project, there are benchmarks[3] done against Reagent that demonstrate the sheer overhead it has. In practice it is not a big problem if you rarely trigger a re-render, but otherwise it is a non-trivial cost, and if you want to use modern React features (like Suspense), there is a lot of r/as-element mingling going on, converting cases, etc. that simply make Reagent feel more tedious to use than Helix.

Also, the newer UIx2, which largely borrows from Helix, is "3.2x faster than Reagent" according to one of the contributors.[4]

I think it'd be worthwhile to benchmark all of these libraries against each other and record the data in one place. Maybe I'll get around to doing it this weekend :)

---

[1] https://github.com/reagent-project/reagent/blob/master/doc/R...

[2] https://github.com/lilactown/helix/blob/master/docs/faq.md#w...

[3] https://github.com/roman01la/uix#benchmarks

[4] https://github.com/pitch-io/uix/pull/12

Helix is also worth checking our for lightweight React integration and hooks support.

Helix is a thinner library with access to hooks, if you want them.

helix

You mentioned liking React hooks, would helix be more to your liking?

Keechma/next is integrated directly with React through the hooks system (and using the excellent Helix library. You can find the integration code in the Keechma/next toolbox - especially https://github.com/keechma/keechma-next-toolbox/blob/master/src/keechma/next/helix/core.cljs