Author here, to provide a bit of context. Initially, this was just a fun project to see if I could replicate the magical Play! 1.x experience in much-less-magi

Author here, to provide a bit of context. Initially, this was just a fun project to see if I could replicate the magical Play! 1.x experience in much-less-magical Go. (Spoiler alert: yes) Along the way, I started thinking more seriously about the right way to put together web applications and did more research into how Rails and Play 2.x are structured. Although Play 1.x was amazing, I think that there are some obvious areas for improvement -- the design of 2.x seems to be much better (although I'm personally allergic to Scala). So the goal posts have shifted. I see this ending up as two things, conceptually: 1. A framework like Rack, in the sense of being a straightforward interface for writing and composing aspects of web applications. (Revel calls them Filters). Some components (Router, TemplateLoader) have defined interfaces so that other components can use them (but most components do not). 2. A default stack of components that work well together out of the box. No size fits all, but the two concrete use cases I have in mind are writing large business applications and REST APIs. The goal is that the revel package shrinks to encompass just the "Rack"-like framework, and the revel command line tool can generate a project with the default components set up. This appears to be achievable; it just requires a bit of work, and I have been quite busy with the day job. More people are using it than I anticipated, so I would like to complete the core design so that it can be properly released. ===== APPENDIX (EDIT) FAQ: "Why not just use vanilla Go, since it already provides X, Y, and Z": Go certainly ships with more components in place than any language I'm aware of, but I still think there is a lot of value in providing a default stack of stuff with a fixed, conventional app organization in terms of lowering the cognitive load bar. If you are making a single endpoint and are a Golang whiz, then Revel is not for you. But for many things it's about the concepts more than the code. For example, the code dealing with the flash cookie is not many lines; most of the value there is having it integrated, documented, and exampled. Empirically, I believe that Rails unlocked a latent desire for web development by lower the bar -- I think Revel can lower the bar for web development with Go in the same way. Lastly, there is something to be said for having an integrated web framework instead of a franken-app composed of various libraries. Take parsing parameters as an example. With a library, how can you get close to the ease that Revel provides? [1] You may think it's dumb, but I find it so much nicer to simply accept parameters as the type that I want them in, and let Revel figure it out instead of me having to figure out the right strconv / etc function to call. The goal is for Revel to take care of all that stuff and let me focus on the higher level stuff. [1] http://robfig.github.io/revel/manual/binding.html#action_arguments http://robfig.github.io/revel/manual/binding.html#action_arg...