At least their system is only 2k LOC, which will presumably be well documented.
At least their system is only 2k LOC, which will presumably be well documented.
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.
My two cents :)
> 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
react = 3k
react-dom = 15k
BTW: code is very easy to read/follow https://github.com/preactjs/preact/
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.?
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.
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.