I think that several of the fallacies of distributed computing are being ignored here. https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
Which ones? And ignored (and potentially irreconcilable) or deferred?
Reactive Clojure: A web language
131–140 of 185 posts
Re: Reactive Clojure: A web language
#132Earlier quoted context omitted.
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…
I‘d still rather read 2k loc in _any_ language, and undocumented, than 350k loc, perfectly documented.
Sure. But I’d question two things:
1) How often do you actually need to read your framework. I used rails for years and read probably less than 2KLOC out of it, ditto with Java and Spring. Good documentation beats out small code bases.
2) How much of the size difference between these two is down to age and uses? Is React so big because it’s unfocused or poorly written, or is that a consequence of it being used by so many people and projects? If it’s the latter, shouldn’t we expect that this project will end up growing if it got popular, eroding the benefit of its small size.?
Re: Reactive Clojure: A web language
#133As 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.
Hats off to the lispers, they do some cool stuff. I think treating code as data they just have a different view of what computation means to the rest of us (or to me at least!)
Re: Reactive Clojure: A web language
#134Earlier quoted context omitted.
I‘d still rather read 2k loc in _any_ language, and undocumented, than 350k loc, perfectly documented.
Sure. But I’d question two things: 1) How often do you actually need to read your framework. I used rails for years and read probably less than 2KLOC out of it, ditto with Java and Spring. Good documentation beats out small code bases. 2) How much of the size difference between these two is down to age and uses? Is React so big because it’s unfocused or poorly written, or is that a consequence of it being used by so…
> How often do you actually need to read your framework.
This brings us full circle to the question that started this conversation branch:
> 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
With React and Rails, "hitting a bug" is apparently rare. Maybe we should wait before assuming it will be any different with this Reactive Clojure framework.
Re: Reactive Clojure: A web language
#135Earlier quoted context omitted.
> 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. I really don't like that idea. It seems to me inefficient and error prone. Let's say you're updating a database. You add some records to one table, and you update some records to some other tables. If the program automagically updates the UI, the…
nothing forbids the system to give mechanisms defining rapid sequences of changes, kinda like debounce in js
I think the main risk for this kind of framework is that you spend as much time ironing out these kinds of "edge cases" (debounce, transition states, error states, transactions, authorization, url bar state, scroll bar position, paging, efficient re-renders, etc. etc.), which in practice are crucial to most non-trivial software, as you would have just writing the usual boilerplate and retaining fine-grained control.
It's great that people are innovating and creating new abstractions, and I'm sure there are apps where the tradeoff is worth it (internal CRUD-focused enterprise stuff comes to mind), but my knee-jerk reaction for a large app is that it will make easy things easier and hard things much harder.
Re: Reactive Clojure: A web language
#136Earlier 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 :)
It absolutely has a strong correlation with complexity.
Re: Reactive Clojure: A web language
#137Earlier quoted context omitted.
nothing forbids the system to give mechanisms defining rapid sequences of changes, kinda like debounce in js
I think the main risk for this kind of framework is that you spend as much time ironing out these kinds of "edge cases" (debounce, transition states, error states, transactions, authorization, url bar state, scroll bar position, paging, efficient re-renders, etc. etc.), which in practice are crucial to most non-trivial software, as you would have just writing the usual boilerplate and retaining fine-grained control.…
I appreciate and have created software that needed to be complex with the associated complex underpinning.
I also have long been looking for a framework that makes easy things easier.
Re: Reactive Clojure: A web language
#138Earlier quoted context omitted.
Sure. But I’d question two things: 1) How often do you actually need to read your framework. I used rails for years and read probably less than 2KLOC out of it, ditto with Java and Spring. Good documentation beats out small code bases. 2) How much of the size difference between these two is down to age and uses? Is React so big because it’s unfocused or poorly written, or is that a consequence of it being used by so…
> How often do you actually need to read your framework. This brings us full circle to the question that started this conversation branch: > 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 With React and Rails, "hitting a bug" is apparently rare. Maybe we should wait before assuming it will be any different with this Reactive Clojure framework.
In my (quite extensive) experience hitting a bug or another issue with react and rails and when/if the error message and trace are absolute drivel (which happens a lot during normal projects), you usually can find fix by pasting it in Google. In react it usually goes something like: throw everything away yarn/yarn build again and pray for the best by the way.
So I think many people don't need to read anything but just pop into Google read what it is + get the fix.
In smaller frameworks and libraries I am more tempted to just check what the issue is in the source and report a bug if it was not just me being stupid again, but that is also because pasting it in Google might get no results at all.
I remember when just starting out with Rails, my rails colleagues all read the source of everything when there were issues or lack of docs; this was very early on (first public version); now I know no one who does that anymore.
I really would like something that stays small and is around in 10 years and my experience with Clojure is good in that respect. And Haskel projects. Those things that keep growing and keep adding dependencies are nightmares but what can I do.
Re: Reactive Clojure: A web language
#139This 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…
If there was one and only one thing I could tell myself from 15 years to do sooner it's LEARN SCHEME. Man I wish I'd stated a decade ago.
Re: Reactive Clojure: A web language
#140One 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. 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 bui…
It's a very impressive project, and something I would definitely try in a greenfield app. I wish there was somewhere to follow updates that wasn't Twitter though.
Especially for people without Twitter accounts