[MetaWhirledPeas]

> 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.

[tluyben2]

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.

[ashtonkem]

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.