7 Matching Annotations
- Apr 2025
-
-
Why not a library? We've found it extremely hard to develop a library that: Supports the many database libraries, ORMs, frameworks, runtimes, and deployment options available in the ecosystem. Provides enough flexibility for the majority of use cases. Does not add significant complexity to projects.
-
- Mar 2025
-
github.com github.com
-
The goal of Lucia v3 was to be the easiest and cleanest way to implement database-backed sessions in your projects. It didn't have to be a library. I just assumed that a library will be the answer. But I ultimately came to conclusion that my assumption was wrong. I don't see this change as me abandoning the project. In fact, I think it's a step forward. If implementing sessions wasn't easy, I wouldn't be deprecating the package. But why wouldn't a library be the answer? It seems like a such an obvious answer. One word - database. I talked about how database adapters were a significant complexity tax to the library. I think a lot of people interpreted that as maintenance burden on myself. That's not wrong, but the bigger issue is how the adapters limit the API. Adapters always felt like a black box to me as both an end user and a maintainer. It's very hard to design something clean around it and makes everything clunky and fragile, especially when you need to deal with TypeScript shenanigans.
Tags
- when not to create a library: too hard to support/maintain the many ways it would need to be flexible
- when not to create a library
- too easy/simple/trivial for end-developers to write from scratch to expect (don't need library to do it for them; don't need to provide feature)
- creating/using library vs. copying code
Annotators
URL
-
- Nov 2021
-
www.reddit.com www.reddit.com
-
packaging is difficult to maintain on linux with so many different distros that software companies to support.Flatpak, snap, and appimage makes it easier to ship once for a lot of distros that support them.
-
- Sep 2021
-
-
Webpacker used to configure Webpack indirectly, which lead to a complicated secondary configuration process. This was done in order to provide default configurations for the most popular frameworks, but ended up creating more complexity than it cured. So now Webpacker delegates all configuration directly to Webpack's default configuration setup.
more trouble than it's worth
- creating more complexity than it cured
Tags
- removing feature that is more trouble than it's worth (not worth the effort to continue to maintain / fix bugs caused by keeping it)
- too hard/complicated/non-trivial
- newer/better ways of doing things
- complicated
- modern javascript development is complicated
- Why can't this be easier/simpler? Why does it have to be so hard/complicated?
- too complicated
- changed their mind/opinion
- more trouble than it's worth
- doing more harm than good
Annotators
URL
-
- Feb 2021
-
-
I apologize for the slow development of Reform after the "explosion" when I released it initially. The reason for this is I changed jobs and didn't use Reform (yet).
-
- Dec 2020
-
hacks.mozilla.org hacks.mozilla.org
-
Less developer maintenance burden: The existing (Kuma) platform is complex and hard to maintain. Adding new features is very difficult. The update will vastly simplify the platform code — we estimate that we can remove a significant chunk of the existing codebase, meaning easier maintenance and contributions.
-
- Oct 2020
-
tech.ebayinc.com tech.ebayinc.com
-
Writing a logic-less template requires a bloated view model with comprehensive getters for the raw data. As a result, a messy and difficult-to-maintain view model usually accompanies logic-less templates.
-