cjbrooks12
commented
4 years ago Auto-enabling features is definitely something I've been asked for before, and I'm not quite sure if it's something that Orchid should support. It would complicate a lot of stuff if I were to do this, as I would need to find a way for plugins to know about each other so they know how to register themselves. In addition, I'd have to deal with potential conflicts among plugins (which I've already noticed between the Prism and Kotlin Playground features), and add ways to disable features as well as configure them. But these are just details that I could deal with as the maintainer and wouldn't ever be noticed by the end-users, so I completely understand the desire to have this kind of complexity hidden from the end-user.
But the main reason I'm not sure if this is something that Orchid should support is that it makes it very opaque what's actually in your site. While this might be good for new users who are still just trying to figure out how it works, it can be very painful to fix problems that arise from auto-registered plugins when you aren't even aware of what's running in your site and don't know where to even start looking to fix problems. This is a big problem I've seen with older frameworks like Spring Boot and WordPress, while many of the more modern frameworks I've used seem to avoid auto-registration, like Laravel, Gatsby, and Ktor.
I tend to think of Orchid along the lines of the Kotlin language philosophy, where it's best to be explicit and declarative with your intentions. Adding a dependency to your build isn't very explicit as it's hard to know what's actually happening when it's added. But adding an extra couple of lines to your config.yml is more explicit, and also gives you the power of knowing exactly why your site is displaying the way it is, while also making it easier to tweak to your specific needs.
I definitely don't want to close the door on this idea yet, but for the time being, I am trying to be more conservative and prefer that users add the minimal configuration they need to get stuff set up as they want. But I'll keep this issue open because I'd love to get some more opinions from the community about this!
I have to admit, over the years I've come to fear software where the author talks about their plugin architecture. Usually such software is a pain in the butt to use because basic features need magic incantations to enable, and the docs are usually structured such that you have to figure it out yourself (because the "core" docs aren't supposed to talk about or link to "plugin" docs).
Plugins can make sense as a way to engineer a system but from a user's perspective they can just be confusing. For instance I discovered that in an out of the box Kotlin project with Orchid, Kotlin code isn't syntax highlighted. The regular tutorials/user guide didn't seem to mention this so I looked for a plugin, but it's half way down a list with huge pieces of stock artwork that are unrelated to the plugins themselves so it took a bit of hunting. Then I discovered there are two different ways to do syntax highlighting and I have no idea which is better. I picked PrismJS because that way I don't have to modify each page and it works. But - it would have been nice to save the five minutes and have this be configured out of the box when by context the Maven plugin can know it's in a Kotlin project!
Or maybe you could switch to enabling all plugins by default and then let the user disable the ones they don't want, if they want to optimise the HTML download time (probably most people don't care).