Re: Unmaintained Turbo, some personal thoughts:
- Turbo works great. We have used it successfully for several new products since it was extracted out of HEY. We have used every bit the library has to offer extensively in Fizzy (upcoming product), and I can't think of a current bug on my list to fix. In my experience, Turbo, and the rest of the Hotwire libraries, are incredibly robust.
- Turbo is maintained. We merged 42 PRs into Turbo this year and released 4 versions, the last one as recent as 3 weeks ago. And there are several more commits already merged pending to be released. Shoutout to Sean Doyle and Bruno Prieto for helping to review many of the changes we have merged this year 🙏.
- I don't believe that ever-expanding software results in better software. Not for products, not for libraries. Turbo is already a pretty big and complex library with a large API surface. If anything, I would be interested in shrinking, cleaning, and simplifying rather than adding new stuff.
- In the frontend world, everyone has opinions and preferences about how to build interfaces. Current Turbo reflects 37signals’. It is very easy to consider a new feature desirable when observed in isolation. And it is very easy to end up with a mess when you try to satisfy everyone. Unless it is a terrific idea that works for most people most of the time, I would advise against accommodating new APIs in the current version of Turbo. Future major versions are a different story.
- Because it is an intricate library with a big API surface, and because it is used by MANY, it is easy to introduce regressions when changing code. Just check the recent commit history and you will find some examples. We need to move carefully before merging changes, regardless of whether those are small bug fixes or configuration options.
- The big backlog in the repo is not great. We should do something about it, but I don't think that necessarily implies merging a ton more of changes per week. To me, the real concern would be if the library was buggy or… unmaintained.
- Everyone is as free to complain and grumble as to press the fork button and show the rest of the world how it is done. But please, don't just threaten with the latter. Go for it! Because it is the option that actually requires putting in work and effort, I am sure it will be enlightening.
My two cents.
- Turbo works great. We have used it successfully for several new products since it was extracted out of HEY. We have used every bit the library has to offer extensively in Fizzy (upcoming product), and I can't think of a current bug on my list to fix. In my experience, Turbo, and the rest of the Hotwire libraries, are incredibly robust.
- Turbo is maintained. We merged 42 PRs into Turbo this year and released 4 versions, the last one as recent as 3 weeks ago. And there are several more commits already merged pending to be released. Shoutout to Sean Doyle and Bruno Prieto for helping to review many of the changes we have merged this year 🙏.
- I don't believe that ever-expanding software results in better software. Not for products, not for libraries. Turbo is already a pretty big and complex library with a large API surface. If anything, I would be interested in shrinking, cleaning, and simplifying rather than adding new stuff.
- In the frontend world, everyone has opinions and preferences about how to build interfaces. Current Turbo reflects 37signals’. It is very easy to consider a new feature desirable when observed in isolation. And it is very easy to end up with a mess when you try to satisfy everyone. Unless it is a terrific idea that works for most people most of the time, I would advise against accommodating new APIs in the current version of Turbo. Future major versions are a different story.
- Because it is an intricate library with a big API surface, and because it is used by MANY, it is easy to introduce regressions when changing code. Just check the recent commit history and you will find some examples. We need to move carefully before merging changes, regardless of whether those are small bug fixes or configuration options.
- The big backlog in the repo is not great. We should do something about it, but I don't think that necessarily implies merging a ton more of changes per week. To me, the real concern would be if the library was buggy or… unmaintained.
- Everyone is as free to complain and grumble as to press the fork button and show the rest of the world how it is done. But please, don't just threaten with the latter. Go for it! Because it is the option that actually requires putting in work and effort, I am sure it will be enlightening.
My two cents.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
