It had me at the title "You don't need a web framework, you need a web language" but then it immediately dived into arbitrary syntax instead of exploring in abstract what a modern web language would entail.
Reactive Clojure: A web language
21–30 of 185 posts
Re: Reactive Clojure: A web language
#22Finally 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? Do we build the client-side on the sever, and render? Why no, that would be PHP. Let'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. I thi…
There's theoretically some performance benefit to rendering client side over ajax because the pages can be trivially cached, though you then run into the issue of pages being placeholders for a moment while the subsequent request(s!) run. Hence the UX anti-pattern of skeleton screens.
Re: Reactive Clojure: A web language
#23Finally 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? Do we build the client-side on the sever, and render? Why no, that would be PHP. Let'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. I thi…
Claiming "this is PHP" misses the point entirely, which is turning PHP-like templates into apps that can react to user input
Re: Reactive Clojure: A web language
#24Re: Reactive Clojure: A web language
#25Can someone translate this for a relative web dev noob? or can anyone? which may be a better question
This lets you write a function where some of the code runs on the client, some of the code runs on the server, and the compiler figures out which and emits the network RPC calls for you.
Re: Reactive Clojure: A web language
#26Re: Reactive Clojure: A web language
#27If I understand it correctly, it allows you to achieve reactive data flow in a single page app without any boilerplate.
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.
This would require a ton of PHP and Javascript dealing with networking, websockets, routing, serializing data and so on.
Haven't tried it yet, but very curious to see if it works.
Re: Reactive Clojure: A web language
#28There are concrete similarities to PHP, which is effectively what this server/client macro setup gives you at a superficial level. However, from what I'm seeing, this will behave more like a LiveView or Hotwire, with the focus being on optimizing network requests in an automated manner.
My big question with the tool is this: if you'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?
Re: Reactive Clojure: A web language
#29Finally 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? Do we build the client-side on the sever, and render? Why no, that would be PHP. Let'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. I thi…
Claiming "this is PHP" misses the point entirely, which is turning PHP-like templates into apps that can react to user input
Re: Reactive Clojure: A web language
#30I'm a bit confused, is this a product or a project?
Yes.
I think more and more the lines are blurred between open source projects, and products. This is good and bad.
It's good because people making money out of open source projects probably means more open source projects, more support available, and a healthier tech industry.
It's bad because as someone with no intention of turning a few open source libraries into a full time job, there's still an expectation of a certain level of polish to them that makes more sense for products. Open source projects with clever names, logos, mission statements, a domain name and marketing site/landing page, marketing copy, flashy documentation, a live preview environment, etc. These are all a lot of work for an open source project, but the stakes are raised to this level by the productised open source projects that can afford to fund this sort of thing.