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
At first glance, this appears to be much more complex. React is a relatively simple DOM diffing library. Rails is a closer comparison, especially with whatever their live-view implementation is. This appears to be doing a lot more than React, at least, including network communication, and database change event propagation. The odds seem much higher that stuff will go wrong, especially under load, and be pretty difficult to reason about.
> 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”.
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.
loc in a node project is hard to judge due to packages and the aforementioned mono repo difference, but the preact functional build artefact is an order of magnitude smaller:
129KiB v 8.2KiB
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.
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.?
> 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.
The question is, are bugs rare in rails because of or in spite of the code size? Obviously more code is more opportunity for mistakes, but more code is also the product of more users and more contributors poring over what’s there.
So yes in a way, but here we're talking about something that synchronises state between a client and DB over http. The possibilities of weird edge cases seem endless :)
At least their system is only 2k LOC, which will presumably be well documented.