As agentic coding matures, this kind of project is the right direction. The mechanics of writing the code become less important. But having a language framework that naturally resists mistakes will become increasingly useful and important.
Similar to how Rust is obviously a better choice today than C++. Who cares if the language is “more difficult” to code in, if the agents are doing the coding. What we need is building blocks that make it harder to author bugs.
I don't know, as far as I can tell the demo on the homepage is bugged? Or maybe I misunderstand how it's supposed to work? If I click reset after 2 seconds and then click add 1 right after it, the reset never fires. What's up with that, that's not what I expected to happen?
Just wondering how a matching backend framework for correctness would look like. Ideally something that doesn't repeat the React mess with two routers but fits right in Inertia style.
Maybe a bit late to ask but how would an EffectTS backend integrate seamlessly? Im looking for a full stack agent driven workflow including domain modeling, designing state machines (with Xstate or SCXML?) etc.
Is it just me? But every time I use a paradigm of global immutable state, almost always I run into edge cases where practically it falls apart either semantically (mental model explosion) or creates performance issues, whether they stem from architectural problems with the framework itself, or just the way computers operate.
I love both effect and elm, but I cannot swallow yet another Vue/React crap even if it adds effect niceties.
Especially after having used ruby and elixir extensively after years of react/Vue, it feels so backwards (and LLM unfriendly) to split front and backend unless you have gargantuan reactivity needs (you don't).
I wish JS offered just one proper server side focused frontend solution.
Given their heads, most clients / product owners drift toward not just major reactivity but real-time. A lot of us work for others, under barrages of feature requests, and Effect and other tools (which may seem like overkill) can reveal themselves as a very practical lifeline.
The project seems super interesting and I've been following since the creator went on an effect podcast I listened to. My only gripe/concern is the fact that the docs are so glaringly AI (likely claude) generated which is something I've come to not expect from technical documentation writing specifically. All in all though, the verbosity tradeoff for explicit design choice here is the right one and I think it does better than elm by remaining in javascript land rather than building a nicer abstraction layer on top that often needs to reach in to do interesting things with the web apis.
27 comments
[ 0.24 ms ] story [ 44.0 ms ] threadSimilar to how Rust is obviously a better choice today than C++. Who cares if the language is “more difficult” to code in, if the agents are doing the coding. What we need is building blocks that make it harder to author bugs.
Cons: The API surface is huge so there is a steep learning curve.
Especially after having used ruby and elixir extensively after years of react/Vue, it feels so backwards (and LLM unfriendly) to split front and backend unless you have gargantuan reactivity needs (you don't).
I wish JS offered just one proper server side focused frontend solution.
a) Actually ship docs, and use AI to help (I also do a ton of hand editing and review cycles)
b) Have poor docs coverage because I’m handwriting everything
I’ve chosen A, but plan to do a few weeks of docs rewrites before I ship 1.0.0. I would rather it sound like me.
https://x.com/devinjameson/status/2073452791843131675?s=46
https://webcontainers.io/guides/browser-support
Is this using a different WebContainers?
Styling is all gross, sorry.
- please more of you start doing this and flood HN with frontend frameworks please