It says right on the OP-linked page:
Revel provides routing, parameter parsing, validation, session/flash, templating, caching, job running, a testing framework, and even internationalization.
Revel provides routing, parameter parsing, validation, session/flash, templating, caching, job running, a testing framework, and even internationalization.
That said, I'd be hesitant to bring up Revel's session as a positive. It shoves everything into a cookie instead of using the cookie token as a key to a serverside data store. Not only are you limited to 4k of session-local storage, but you're sending the entire payload across the wire for every single request. This is absolutely stupid and needs to change. I'm sure Rob is boxed in by limited time, and this is not intended for production use yet, but holy god, it's by far the worst thing about the framework.
routing is best left to you to write explicitly, there's no pancea, because if you use this solution and you then need to do something even slightly more complicated, then you now have two nomenclatures, and two interacting systems.
A simple library is what is needed for parameter parsing and validation, not a framework that provides it wholesale.
There are lots of session implementations, a library might intice you with its offerins, not a frameworks im pretty sure this one size fits all solution should work in some manner
Templating was already there, they offer it again? There's also competing libraries to go's templating, use those.
Caching? You mean for templates? That's not complicated to do. For databases? There are databases that need you to cache results for them? Sheash.
job running? Oh good were cron now, why not this? http://godoc.org/github.com/robfig/cron
a testing framework? Doesn't go have one of those? Why do we need two? Go's got a good testing framework!
Internationalization is templates with file reading, right?
I know these all sound hard, they sound like you can't do them on your own, or they sound tedious. But for the love of god, down with frameworks, down with magic! Burn it all!
Go has all the built-ins you need to get a simple web server started in no time, but as you progress to real-world work, you do notice your own plumbing and boilerplate code piling up. In your second project, you extract those into a number of packages. Then if you're feeling fancy or idle, "bam, look Mom, a Web Framework!"
> For databases? There are databases that need you to cache results for them? Sheash
Yeah ever heard of Memcached? Check it out. Still something you need to bind & talk to, and perhaps you want to have a little toggle for your dev environment to have RAM caching instead of full-blown Memcached. Voila, a candidate for a utility package. Sure, this is mostly trivial to write yourself, which is why a gazillion of them exist, but hey, why not have it included in a single go-get-able package that has a lot other "needed" web-ish stuff in it too.
Personally, I'm not touching frameworks like this either. I swear by the built-ins (even for templating) and the "Gorilla" libs. But why the hate, this clearly worked for the coder and users of this framework. Maybe there comes a time and project where it will work for me.