Reactive Clojure: A web language

This is not reinvention of PHP as some are commenting. In fact I think this is extremely cool.<p>If I understand it correctly, it allows you to achieve reactive data flow in a single page app without any boilerplate.<p>Meaning - you update the database on the server and all the relevant UI(s) will automatically receive the updated data and re-render only the parts of the UI that display that data.<p>This would require a ton of PHP and Javascript dealing with networking, websockets, routing, serializing data and so on.<p>Haven&#x27;t tried it yet, but very curious to see if it works.

One thing I admire about the Clojure community is audacious projects like this. While a ton of these seem to run out of steam, they certainly shoot for the stars and tend to come pretty dang close for a while.<p>For those working in Typescript, Blitz.js seems to do a great job at drastically decreasing the plumbing you have to write to shuttle data between Postgres and React. There’s also a ton of goodies like auth built in. From my first impression it’s the closest the JS community has ever come to a Django, and that’s very high praise in my book.

This reminds me of Meteor.js[0] from back in the day (2014?), which had a very similar approach—you wrote code that ran on both the frontend and the backend, and database updates were propagated automatically. It suffered from a pretty hard reliance on Mongodb and its own package manager (Atmosphere), and it was at odds with the rest of the JS ecosystem which was settling on NPM.<p>This project looks very cool! I like the focus on composition, Meteor was lacking that (and really, most other frameworks do as well).<p>[0] <a href="https:&#x2F;&#x2F;www.meteor.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.meteor.com&#x2F;</a>

So from what I can tell this is conceptually similar to the LiveView model, except that the problem is approached from the perspective of the SPA&#x2F;client stack instead of the SSR stack. It’s a refreshing idea that I’ve never seen executed like this before.<p>However I think it’s missing the point of de-coupling. Security would be very hard to reason about, as would handling of intermittent network connections when the real structure of the client and server are abstracted away from you.<p>Ultimately I think GraphQL with live queries is the best model for this type of reactive work. You get a decoupled client&#x2F;server, reactivity, support for mobile clients as you have an API, as well as full type-safety on the client.<p>Nonetheless I applaud the creativity on display here and I hope I’m proven wrong. Maybe this will be the next paradigm shift? Who knows

This is exactly what I&#x27;ve been thinking of lately. I started web development in 1998 and in 2000 I got searching for some way to store data.<p>At first I tried Macromedia Coldfusion, later acquired by Adobe. Now that I checked on it, it seems to be going strong, to my surprise. It was too hard for me. And it was closed software. There was no way for me to learn it without spending money on it. And it wasn&#x27;t what I was really looking for.<p>But I just needed something simple. Something to tinker with. So I found PHP. It was exactly what I needed at the time. Later I also found MySQL.<p>The amount of garbage required to build a single website is enormous. So enormous that we have gone a full circle and people start using static site generators to create pure HTML sites. Because of speed and few other reasons.<p>So I got to thinking, why is it that we&#x27;re building webshops with all these open source technologies, with a huge amount of overhead and &quot;bloat&quot;, when all you really need is a few simple things.<p>Well, as the creator said it, there are a lot of unknowns. Huge learning curve etc. But that&#x27;s how Linux got started, as a tinkering platform. I really think this is the right path to take. Making an open source web programming language, that handles all the needs directly built-in. I totally agree with the philosophy and if you will, proposed abstraction, of the problem at hand.<p>But also, it makes me shiver to look at the code and not understand it. So much to learn. But it gives me hope to see, that other&#x27;s have come to the same conclusions. Looking forward to hearing more!

Quite a few comments that are dishonest or didn&#x27;t focus on what the author focused on, but rather on auxiliary things.<p>There are concrete similarities to PHP, which is effectively what this server&#x2F;client macro setup gives you at a superficial level. However, from what I&#x27;m seeing, this will behave more like a LiveView or Hotwire, with the focus being on optimizing network requests in an automated manner.<p>My big question with the tool is this: if you&#x27;re passing environments back and forth, how secure can this feasibly be? Is there an automated limit on what will be considered based on the generated code? How do you handle malicious environments?

This is tangential but also a validation.<p>FoxPro (&amp; dBase) is a realization of the concept: To deal with databases, you <i>need</i> a database language.<p>Exist a lot of minor things that our apparent &quot;general-purpose&quot; languages lack in the moment you need to deal with certain niches. From very small stuff as not-even available decimals, dates, currencies, units types, to lack of simple way to transform data, to ad-hoc queries, to ad-hoc data validations, to lack of relationship modeling, etc.<p>Even if you say &quot;linq!, ActiveRecord!, functional!, lisp!, pandas!...&quot; and others all that are a <i>shadow</i> of what the dBase family provides.<p>How far? I was not in worry about all the stuff everyone worry about today (injection? orms? impedance mismatch? reactivity? &lt;- an over-complicated patch on top of unfit languages for it, so kudos for this idea!). That is what make me put some time aside in build a language in the spirit of it, because is so much details that are not available if the languages is not designed with data(as of the kind of business) in mind.<p>So, in short, most languages, even php, python, ruby, ... are not that good for web programming (and worse for database programming!), just that are not that terrible, either.

When the framework does so much for you, I always worry about what it looks like at scale when you need to start optimizing. Can you instrument all the plumbing, if something breaks can you get at it to fix it? How will you add caches at various different layers? On the browser, http cache, db cache, CDN, etc.? If the generated JavaScript that’s ultimately running on the browser has a bug, how many layers of library do I have to sift through to fix it? When I want to simulate the network for testing or deal with intermittent connection failures on the frontend how hard it is to plug in? What do schema migrations look like? What do deployments across a fleet of servers look like (there’s some point in time when some servers are old and some servers are new…)?<p>These are problems with any framework, but the more all-in-one a framework attempts to be the harder it is to get in between the joints with your glue gun to fix things up.<p>That said, this is Clojure and usually you have pretty easy access to all the intermediate bits and bobs and macros so maybe it’ll be great.

This is beautiful. I used to think about this problem deeply. The best imaginary system I did imagine was:<p>- A system that starts with our database schema<p>- a language in the front-end that abstracts away server connection and db access<p>- this imaginary language should allow defining react-like components but treat the db as a local datastore<p>- Most clients are UI stricture interpolated with that user’s data queried from the central db. So this imaginary front-end language should allow querying from user-level views from the db<p>Most of what I read from the post, looks like a realization of this dream.

It had me at the title &quot;You don&#x27;t need a web framework, you need a web language&quot; but then it immediately dived into arbitrary syntax instead of exploring in abstract what a modern web language would entail.

It does seem a bit convoluted after going through it a couple of times, but I&#x27;m down to try it if my reagent React interop still works, e.g. `[:&gt; MyJsComponent {...}]`.<p>I would say that I am very happy with the FE stack of reagent &#x2F; reframe at the core. I have long chased the dragon of co-located queries ala GraphQL instead of basic re-frame subscriptions, or redux.connect and pulling fields off a map. Obviously having the ability to be more expressive with data queries is great, but in reality I have come to settle on basic subscriptions into maps, syncing data into my db via events. It&#x27;s not super pretty but it scales!<p>This seems like it&#x27;s trying to push the needle, and I will it.

The Web After Tomorrow beckons: <a href="https:&#x2F;&#x2F;tonsky.me&#x2F;blog&#x2F;the-web-after-tomorrow&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tonsky.me&#x2F;blog&#x2F;the-web-after-tomorrow&#x2F;</a><p>Well done, @dustingetz!

&#x27;compiler managed network&#x27; in here is a useful concept<p>buildsystems are increasingly doing the heavy lifting of telling backend how to deliver a pre-hydrated frontend, and telling frontend how to speak backend&#x27;s language<p>would be nicer if this was just types and schemas, so you didn&#x27;t have to use a full-stack framework to get full-stack accelerations and linting

As a web developer with 25 years of experience and (I thought) up to the minute skills ... I have no idea what any of that means but it sounds cool and important and I want to try it.

Interesting how no one has mentioned Fulcro. There seems to be a lot of overlap between the two. Anyone who has used both and mind comparing them?<p><a href="https:&#x2F;&#x2F;fulcro.fulcrologic.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fulcro.fulcrologic.com&#x2F;</a>

How does the reactivity work with Datomic? Is it polling those queries? Or I’d it listening to the log of transactions and figuring out when relevant parts have changed?

This reminds me a lot of imba[1], which mixes the front end and the back end. Though ReactiveClojure seems to be more about reasoning in terms of a lisp for all parts of the app, whereas imba is more focused on reducing syntax noise as much as possible.<p>[1] <a href="https:&#x2F;&#x2F;imba.io" rel="nofollow">https:&#x2F;&#x2F;imba.io</a>

I think people are overlooking the fact that javascript and css is a hot mess to deal with. We need something like flutter that makes maintaining these easier.

Coincidentally, Alephjs (<a href="https:&#x2F;&#x2F;github.com&#x2F;alephjs&#x2F;aleph.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;alephjs&#x2F;aleph.js</a>) added a commit hours ago that also seems to solve this particular problem for React.<p>So now there&#x27;s a React hook (useDeno) that takes a callback that is only executed on the server-side, and the returned value is sent back to the client side transparently.

I think I fail to see the advantage in the example given. Is the point that there&#x27;s a server side call attached to the UI component directly? How is this any different than what can already be done with old school full stack like Rails or even smaller libraries like Sinatra&#x2F;Flask.

If you are trying to allure front end devs, maybe don&#x27;t use tables in you example.<p>To my taste, all of that is way too overcomplicated. I don&#x27;t know why we need to make writing and maintaining web pages more complex with every year that goes by. To my mind, this industry looks completely derailed.

My arrow and page up&#x2F;down keys do not work on this website. Very annoying.

&quot;Photon will likely be technical alpha for all of 2022 or longer&quot;. Wake me up in a couple of years then.

great to see hyperfiddle here, delightful surprise, deserves the attention, kudos @dustingetz, ty for the writeup

Can someone translate this for a relative web dev noob? or can anyone? which may be a better question

I like how client and server code is separated, but I do wonder how changes in expressions are evaluated.<p>I&#x27;m thinking about autocomplete that on new user input (needle=&#x27;ad&#x27;) filters previous result from server (needle=&#x27;a&#x27;) in the client before server returns a new response from new input (needle=&#x27;ad&#x27;).<p>Essentially can inner parts of expression update even when they are somewhat dependent on reactive data from server that comes from their parent expression?

This is very cool, and ambitious, but i have one major objection: the claim that web apps are an about unidirectional data flow from a managed data store to a consuming front end.<p>That&#x27;s not the kind of apps I want to build. I want workspaces where I can make and edit and work freely. I don&#x27;t care to be online to do it, and conserving bandwidth is not a constraint that should define how I use it.<p>The DAG goes from me to me.

Lots of people saying it’s like PHP or liveview with elixir.<p>We kinda have that with livewire[1] and inertia[2] and as awesome as they are (no separate api etc) they also suffer from the “magic”<p>[1] <a href="https:&#x2F;&#x2F;laravel-livewire.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;laravel-livewire.com&#x2F;</a> [2] <a href="https:&#x2F;&#x2F;inertiajs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;inertiajs.com&#x2F;</a>

Off topic, but please don&#x27;t use Notion for static sites. The page is 1.8MB (9.4MB uncompressed) - 1.6MB of that is javascript.

This is great. It&#x27;s the dream that was promised 4-5 years ago of with om and reagent fully realized.

How does this compare to frameworks that abstracts over network calls such as ocsigen&#x2F;eliom [1] ?<p>[1]: <a href="https:&#x2F;&#x2F;ocsigen.org&#x2F;tuto&#x2F;latest&#x2F;manual&#x2F;application" rel="nofollow">https:&#x2F;&#x2F;ocsigen.org&#x2F;tuto&#x2F;latest&#x2F;manual&#x2F;application</a>

I think no-code&#x2F;low-code backend is here to stay. Products like Hasura put authorization&#x2F;ratelimiting&#x2F;graphql&#x2F;api-GW on top of trusted postgres. Now BE and no serialization up and down. Simply generate a client based on the graphql schema and off you go.

I&#x27;ve thought of doing this several times, and always shied away at the complexity and nuance that goes into it. Kudos to the devs for having the skill and determination needed to actually make this real. Very impressive work, and I hope it works great in practice.

I think that several of the fallacies of distributed computing are being ignored here.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Fallacies_of_distributed_computing" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Fallacies_of_distributed_compu...</a>

I&#x27;m a bit confused, is this a product or a project?

I’m very into stuff like this, and I really can’t make heads or tails of what this post is about. There’s a ton of hand waving, and a ton of words, but why not use them to explain exactly what this thing is doing?

looks very overcomplicated for generating an html table, building something more powerful would result in even more complex code. There&#x27;s a reason why these things get decoupled

Finally the problem which PHP solved more than two decades ago has been solved again. How do we include server-side code in client-side code?<p>Do we build the client-side on the sever, and render? Why no, that would be PHP.<p>Let&#x27;s build the client-side in the browser, and rig a series of complex code-generating primitives disguised by the beauty of a language, to AJAX our way to a presumably good-enough solution.<p>I think its a serious question whether apps built with this are more performant, easier to use, (and so on) than the equivalent PHP-approach.

We did that, it was called PHP, and it turns out DSL are pretty limited outside of their sweat spot. Also they don&#x27;t evolve as fast as libs and framework.<p>Case in point: PHP worked well, but framework like Rails and Django became very attractive because their offered more, and used languages that could be good outside of their niche.<p>And what did the PHP community to stay relevant ? They developed great frameworks, and improved the non web language capabilities.<p>Turns out the web moves fast, and coding a web app is more than web programming anyway.

Am I missing something or is reactive clojure a web framework for a language too?<p>I don’t recall Clojure being a web centric language like PHP, ASP, etc.

Hi Very interesting read. What would be the possible business models for this to make money?

Hugged to death and I’m afraid there is no wayback archive right now.

This is nice but it doesn&#x27;t give you a reasoning system for making assertions about components. I&#x27;d rather work backwards from that point to a web language but playing around with things dynamically is the most natural and explored model.

Not related, but is Notion becoming new Medium?

Loving this for you...<p>)))))))))))

Thanks. I hate it.

They chose a parenthesis-language, interesting choice. I don’t think the syntax is going to attract many web devs.

I&#x27;d love to know why any time I read something about clojure, it&#x27;s inevitably cluttered with big words that the author (or some other clojurian) invented that have a lot of deep and important meaning, that make it impenetrable to anyone else.

Premature compositionally in the root of all evil, or something like that. I&#x27;ve looking for better ways to do document.createElement and addEventListener ever since the days of DHTML. Anyone looked into diagram theory already? The only productivity gain I&#x27;ve found is being fluent enough in your stack of choice to do the work to solve a problem and nothing more. And sure, spend the rest of your time researching diagram theory, but try to be honest about why you do it.

This syntax is insanely hard to read, is non-standard, and is unclear what is server side and what is client side processed without purple and red highlighting.<p>Maybe I’ve been in Node.js land too long, but I don’t get why this is better for my productivity or my ability to create efficient web apps.