Live data from Hacker News

Reactive Clojure: A web language

hyperfiddle.notion.site

111–120 of 185 posts

Re: Reactive Clojure: A web language

#111

If you are trying to allure front end devs, maybe don't use tables in you example. To my taste, all of that is way too overcomplicated. I don'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.

What would you use to represent tabular data like a list of T-shirt orders as in the example? That should be an HTML table. Using tables for positioning is bad in front end. Using HTML tables/sections/headers for document data structure is exactly what HTML is for.

Unless it's two columnns only, tables don't work well on mobile. You end up having to undo in CSS a lot of properties that TD, TH bring by default.

Re: Reactive Clojure: A web language

#112
post #58

This is not reinvention of PHP as some are commenting. In fact I think this is extremely cool. If 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 to…

> Imagine a programming language runtime whose runtime state (i.e. lexical scope) is partially broadcast over network as it happens, kind of like a remote debugger. This sounds absolutely terrifying from a security perspective... What's to stop a malicious client from broadcasting code that deletes my entire database?

any sort of networking sounds terrifying from a security perspective...

Unfortunately (or fortunately) it's also a corner-stone of computing in general

Re: Reactive Clojure: A web language

#113
post #106

Earlier quoted context omitted.

Or Calva for VS Code. It's the best dev environment I've used for any language. It's brilliant.

Calva always exploded on me when I tried to set it up on Windows 10. Is it better on a *NIX system?

Never tried it on Windows, but it works pretty well on mac in my experience

Re: Reactive Clojure: A web language

#115
post #6

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.

More work and learning basically in "front end" land, before you can do anything practical -- as usual.

does nothing practical happen on the front end?

Re: Reactive Clojure: A web language

#116
post #104

Earlier quoted context omitted.

> At first glance, this appears to be much more complex. React is a relatively simple DOM diffing library. Their implementation is 2k lines of code. The React repo has 350k lines of code. The Rails repo has 336k lines of code (both of those according to tokei). Of course this includes tests, lots of other stuff, etc. But still, that's two orders of magnitude.

LoC != Complexity. React has one job, and it does it really well, part of that 350k lines of code is a LOT of tests. Just because it has those tests doesn’t mean it’s “much more complex”. My two cents :)

After a naive removal of the tests (every folder and files that contains tests was deleted), React still has 190k lines of code.

> React has one job, and it does it really well

I'm not sure I agree. It's hard to compare without a minimal copy of React to see how small it can get, but I'm guessing it could be an order of magnitude smaller. For example, React supports different ways of doing things (class components, function compenents, hooks). Backwards compatibility is a great thing, but it's not the same as "having one job and doing it well", it's a different tradeoff. The React team has lots of people that depends on their code, and thus choose stability over being small and nimble. I think that's a responsible choice. But this leads to complexity, and losing the "having one job and doing it well".

As a more general remark, there's a cycle in software. React starts small and nimble, especially compared to the "jQuery behemots of the past". It gets really popular. So people start depending on it. So it grows, and grows, and grows. And then someone else comes out, maybe Photon, maybe Svelte, maybe something else. Compared to React, it's small and nimble. Maybe in 10 years, Photon will be really popular, will be 200k lines of code, and someone will build an alternative because it's too big and complex.

Edit: as a more meta-remark: My message is way longer than yours because I was trying to steelman my argument, and you didn't do the same with yours. Considering you made a small message "defending" React and I did a long one "defending" Photon, I think we already agree about the tradeoffs involved here.

Re: Reactive Clojure: A web language

#117

This is not reinvention of PHP as some are commenting. In fact I think this is extremely cool. If 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 to…

In this sense it's same as what microsoft is trying to do with Blazor - except they are skipping whole javascript crap and compile to wasm.

Which sounds great until you experience the loading times. Last time I tried it out, the loading times for all the DLLs that a typical application requires was pretty bad. But once it loaded, things were snappy.

Re: Reactive Clojure: A web language

#118

Earlier quoted context omitted.

Calva always exploded on me when I tried to set it up on Windows 10. Is it better on a *NIX system?

Never tried it on Windows, but it works pretty well on mac in my experience

I'll try it out on a Linux device, thanks!

Re: Reactive Clojure: A web language

#119

This is exactly what I've been thinking of lately. I started web development in 1998 and in 2000 I got searching for some way to store data. 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't what I was…

Clojure (and Lisps in general) really aren't hard to learn. It just takes those of us that come from C-influenced languages like PHP a little longer to be able to read them at a glance because the syntax is slightly different and usually simpler.

Once that lightbulb of the power of a Lisp goes off, there's no turning back. As Eric S. Raymond said, "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."

Re: Reactive Clojure: A web language

#120
post #85
post #75

Earlier quoted context omitted.

The problem with this type of system in my experience is that it’s great until you hit a bug, and then you realize you have no idea what’s going on under all the automagical stuff and you go crazy

How is this different from any other framework? Try fixing a React or Rails bug. At least their system is only 2k LOC, which will presumably be well documented.

Clojure tends to be a bit more terse than other languages. 2K of Clojure is a lot of code. Especially if macros get involved. As for the comparisons to React elsewhere; I wonder how much of that is the result of React being battle tested for a long time and expanded, would this still be so short if Facebook was written in it?

I also wouldn’t presume good documentation as a general rule. That’s something that must be proven, not presumed.

Post reply on HN