nseaSeb
AcmeScript — Writing JS hooks as if I were still using Elixir
I’ve been having fun building a little something over the last few days: AcmeScript.
The idea started with something pretty simple: when working in Phoenix/LiveView, I really love the way code is written in Elixir… but as soon as I have to dive into a phx-hook, I switch back to JavaScript and lose a bit of that comfort. ![]()
So, I tried tweaking JS a bit.
For example:
pipe(
users,
Enum.filter((u) => u.active),
Enum.map((u) => u.name),
Enum.uniq()
)
Or:
getIn(state, ["user", "profile", "name"])
putIn(state, ["user", "profile", "name"], "Seb")
And for hooks, the idea is to have a slightly more convenient context:
createHook({
mounted(ctx) {
ctx.handle("something", (payload) => {
// ...
})
ctx.push("something_happened")
}
})
I also ended up including a few other things I frequently missed: ok/error, match, a little withDo, H/J, some DOM helpers, a client-side PubSub, etc.
Obviously, this isn’t an attempt to turn JavaScript into Elixir (well… maybe a little bit
).
The fun part is that it actually fits into very little code and can be used directly as an ES module, without a mandatory build step.
GitHub - nseaSeb/acmescript: Helpers JS façon Elixir pour hooks LiveView et templates .heex · GitHub
I’d be curious to hear your thoughts: do you find this kind of helper pleasant to use, or am I simply trying to force JS to become Elixir against its will? ![]()
Ideas and suggestions are welcome.
Trending in Discussions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
jam
Cool. Also you might be interested in https://hologram.page/
OndrejValenta
Or you might be interested in this, based on scope of you javascript and what it does. In my experience meddling with LiveView code is really not something you want to do
nseaSeb
Thanks for the feedback! I agree — it really depends on the context and the choices you want to make.
To my mind, there are roughly three levels:
Level 1 — AcmeScript: small JS utilities with no build step, for cases where you genuinely need to write some “inline” JavaScript in a hook, but want to make that code a little more pleasant and Elixir-like.
Level 2 — lightweight declarative tools: things like Alpine, where you rely more on conventions and declarative patterns while staying very close to native JavaScript.
Level 3 — full-fledged frameworks: Svelte/React islands, Hologram, etc., with a build step and a proper application infrastructure.
Each approach solves a different problem.
Hologram and
keen_phoenix_svelteare excellent examples of approaches that can make hooks unnecessary in many cases — which is a perfectly valid direction.AcmeScript is deliberately much more modest: it’s simply a small JS helper library for the cases where you do need a hook. It can even be used as a foundation for building your own helpers.
So I don’t really see them as competing approaches — more like different points on the same spectrum.
nseaSeb
Hey, I added classics hooks in a demo