Skip to content

Instantly share code, notes, and snippets.

@yorickpeterse
Last active September 10, 2015 13:44
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save yorickpeterse/9926d9fe3e9d5388c1c6 to your computer and use it in GitHub Desktop.
Save yorickpeterse/9926d9fe3e9d5388c1c6 to your computer and use it in GitHub Desktop.
Lotus
As an alternative I (Michael) started looking into Lotus and Volt. Volt is immediately rejected due to its sole support for MongoDB.
Modular framework, in contrast to Rails, we don't have to load all modules while not using them.
It uses as much classes as possible, which improves testing capabilities for the controllers.
Custom database adapter support, which allows the usage of Sequel.
Well maintained
Faster than Sinatra (and Rails)
Whitelisting of parameters
Been around for three years.
Link helpers are at least on par with Rails' link helpers.
Option to use custom template engine.
Some downsides:
Custom templates need to be converted by hand, no alternate generators available yet.
No support yet for multiple models in a single form.
Pry issue (working when removing a single hook, but then the function 'whereami' is not available).
My conclusion thus far is that Lotus is a suitable replacement for Rails, which still keeps the structure for a bigger application without losing performance.
== Yorick
Thinking of it, Lotus does seem interesting but there are a few issues that I have with it:
It's still relatively young, especially compared to Rails (which has been around for over 10 years)
The development team is small and to the best of my knowledge nobody is paid to work on it, this means development could cease in the short term
It hasn't reached 1.0 stable just yet, meaning the API could change at any given time and break things (as allowed per semantic versioning)
Compared to Rails the ecosystem is pretty much non existing
It's an entirely different beast compared to Rails, and with just 2 developers left that might not be the best choice
Using Rails engines instead would mitigate these drawbacks. Also, plugging an engine in Junction means we can just re-use Junction's authentication system (already the case for OAT).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment