TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Electric Clojure – A signals DSL for full-stack web UI

330 点作者 Borkdude大约 2 年前

17 条评论

den1k大约 2 年前
I&#x27;ve been building with electric for several months now and it&#x27;s hands down incredible! Why? I think most importantly because it allows for functional composition across the network (client&#x2F;server–distributed systems more generally) while also ensuring payloads are as small as possible (only what functions in each env access) which translates to FAST.<p>IMO this is a paradigm shift similar to GC. No one wants to manage their garbage. No one wants to manage the network. It&#x27;s grunt work. Let the compiler take care of it.<p>I&#x27;ve naively rewritten a re-frame (react&#x2F;redux in js) app that started getting prohibitively slow due to a bunch of deserialization on the client in electric and the performance is outstanding! TBH I&#x27;m taking a break from additional UI work on the app to do research because I realized that with electric I can build something much more amazing than I thought possible before.<p>Caveat: the future will not be served on a silver platter. it&#x27;s early days and there are some quirks
评论 #34774532 未加载
dustingetz大约 2 年前
Founder here - woke up to this. Here is some context for HN:<p>Demo videos: <a href="https:&#x2F;&#x2F;hyperfiddle.notion.site&#x2F;Electric-Clojure-progress-Dec-2022-5416dda526e24e5ab7ccb7eb48c797ed" rel="nofollow">https:&#x2F;&#x2F;hyperfiddle.notion.site&#x2F;Electric-Clojure-progress-De...</a><p>Prior HN discussions addressing many of the FAQs: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28630209" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28630209</a> <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31217448" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31217448</a><p>Some notes on the network layer: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Clojure&#x2F;comments&#x2F;vizdcc&#x2F;hyperfiddlephoton_progress_update&#x2F;idk0dy5&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;Clojure&#x2F;comments&#x2F;vizdcc&#x2F;hyperfiddle...</a><p>I&#x27;ll try to address some FAQs in another post
评论 #34774406 未加载
college_physics大约 2 年前
Practicalities aside (and there might be many issues and even be show-stoppers), the approach is a breath of fresh air in what appears like a stagnating swamp. How to orchestrate overall client&#x2F;server computations is obviously a vital importance if not <i>the</i> most important design choice in the modern tech landscape. Yet while strong opinions abound, frameworks that help us to think more concretely and rationally about the tradeoffs and break the redundancy of infinite alternative possibilities are not common.<p>If I understand the idea correctly effectively here you have a platform where alternative choices are simple rearrangements of code.
评论 #34783842 未加载
yladiz大约 2 年前
Not to be a downer, but while I think in theory this sounds interesting, and treating frontend and backend differences as a DAG that is compiled for the different environments seems cool, I&#x27;m skeptical that it would actually be productive in a large application.<p>One thing I&#x27;d be particularly concerned about is debugging. One of the things that&#x27;s on the roadmap is &quot;developer experience&quot;, and I don&#x27;t see any particular debug docs or helpers, so it tells me that if there is a bug somewhere debugging it is going to be a pain, even more so because I won&#x27;t easily be able to see whether the problem is my client or server code as they live together and are compiled into separate things. As a critique the fact that developer experience is on the roadmap rather than thought about from the beginning is a little off-putting, but maybe that&#x27;s not what was meant here.<p>Another thing that gives me hesitation is that I can&#x27;t see how I would extend the setup to support offline capable applications. This is increasingly becoming a big thing for web+desktop apps, does this easily support that?<p>Lastly, the docs seem to point to use a homegrown DOM library, rather than one of the major players. How easily would this work with a library like Reagent, Helix, or UIx?
评论 #34778460 未加载
评论 #34779597 未加载
评论 #34776725 未加载
评论 #34774341 未加载
评论 #34773453 未加载
评论 #34774953 未加载
kimi大约 2 年前
This is major - potentially killing off a thousand tons of boilerplate.<p>Not sure if it is too late, because Elixir&#x27;s LiveView seem to have gotten important because it works around the same issue.<p>But it&#x27;s time to push the wooden stake through the heart of the SPA (and the phone app too, but that&#x27;s for another day).
评论 #34772931 未加载
i_cannot_hack大约 2 年前
I don&#x27;t know much about this kind of architecture, but wouldn&#x27;t it be problematic from an infosec standpoint? It seems like it would be very easy to accidentally leak information from the server to the client in a subtle manner if the developer makes a mistake somewhere. And in ways which would not be obvious from reading the code unless you carefully consider the implications of each e&#x2F;server and e&#x2F;client with respect to the mentioned graph analysis?<p>Are there any mitigations in place to prevent this, except the obvious &quot;be careful and don&#x27;t write bad code&quot;? Or have I misunderstood things completely and it&#x27;s a non-issue?
评论 #34772958 未加载
评论 #34776973 未加载
评论 #34774394 未加载
评论 #34772795 未加载
emmanueloga_大约 2 年前
Hey Dustin, could you share a few details of how you are funding your projects? I know that you have been working in hyperfiddle for a long while but not sure if you have any revenue from it yet.<p>Your projects are very “futuristic” and the kind of thing I imagine may be hard to get financial backing for, because of the novelty and other considerations… so makes me curious how you balance innovation with monetization in your work.<p>Thank you!
评论 #34790337 未加载
eduction大约 2 年前
“The Electric compiler performs deep graph analysis of your unified frontend&#x2F;backend program to automatically determine the optimal network cut, and then compile it into separate client and server target programs that cooperate and anticipate each other&#x27;s needs.”<p>This make it sound like client and server segments are determined on the fly based on prevailing conditions, but then the sample code has forms wrapped with e&#x2F;client and e&#x2F;server. What do you mean when you say you determine “the optimal network cut” and how do you reconcile this with the expressly marked client and server code?<p>By the way I’ve been following this project for a while and am very excited about it, kudos on getting to this point.
评论 #34780029 未加载
beders大约 2 年前
Can&#x27;t wait to try this.<p>Congratulations on the release! A great showcase for the flexibility of Lisp.<p>Others invent whole programming languages around a paradigm, while Lisp just marches on with s-expressions. Well done!
iLemming大约 2 年前
Looks very awesome. Will definitely give it a try. Hopefully it doesn&#x27;t end up like Om.next. Om.next felt like an amazing quasi-revolutionary thing when David announced it. But it was so poorly documented and hard to get it right, almost nobody used it in production. I don&#x27;t know for a fact, but it felt like it complicated Circle CI&#x27;s frontend to the point that they&#x27;d decided to abandon Clojurescript altogether. It&#x27;s sad, because Om.Next really did have some cool ideas. Fulcro project fixed many problems, but it was too late, the momentum for Om.Next was already wavering.
patates大约 2 年前
&gt; There is no client&#x2F;server dichotomy from the programmer&#x27;s perspective<p>But on the first example, I see a lot of e&#x2F;client and e&#x2F;server calls. Am I misunderstanding this? If so, how is this different from meteor.js?
评论 #34772529 未加载
nih0大约 2 年前
Is this similar too Java&#x2F;Vaadin, that also allows calling of backend database repos and the like from the frontend ?
评论 #34774407 未加载
samsquire大约 2 年前
This is similar to my idea &quot;structured logging 2 system&quot;<p>The idea is that we write what should be done and it is scheduled onto different systems and communication is inserted.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;samsquire&#x2F;structured-logging-2-system">https:&#x2F;&#x2F;github.com&#x2F;samsquire&#x2F;structured-logging-2-system</a><p>I really like the idea of being capable of switching where something runs on the server or the client by changing a boundary.
waldrews大约 2 年前
Could someone who understands the similar blurring of lines between client and server in the F# world, through Fable or more broadly in Blazor&#x2F;Bolero, comment on how this approach compares?
the-alchemist大约 2 年前
Noob question: Can HTMX be used together with hyperfiddle?
评论 #34803441 未加载
gfodor大约 2 年前
This looks cool. If I think one step ahead, this reduces enough incidental complexity its the kind of thing that, when combined with AI, could produce the holy grail of an AI writing most of the code for a full CRUD app.
评论 #34778336 未加载
tr14大约 2 年前
I respect an engineers that can code Clojure. Nice job.