Is the framework still actively being developed? about revel HOT 5 CLOSED

@brendensoares Yeah, I know exactly what you mean. I have been actively looking for the Rails/Django-like experience in Go for quite some time myself. Talking to clients of mine that I help bootstrap projects, I think that there is an opportunity left on the table. And no one wants to claim it. I think that a similar fate is following @markbates' Buffalo. It is still being actively developed, but it looks like the initial excitement has died down a little.

I just wanted to say the following: Not everyone wants to use Go for hyper-focused microservices. I am a perfect example of that, and so are the people and teams I work with. Most of them will pick either Rails, Django, or Laravel not because of their backing languages, but because there is an active ecosystem behind any of them. It's reassuring to know that the framework you picked has a vibrant community of helpers, and will be around for the next few years.

I have not seen that same momentum in the Go community. Most people will argue that this is because "Go does not need frameworks", or "frameworks lead to un-idiomatic Go", or "Rails style frameworks are obsolete", or other sorts of ungrounded nonsense. Go is general-purpose enough, and if a feature was added to it, it means it can be used to solve problems in any way, regardless of whether some people find it idiomatic or not. I suppose, the same was for Ruby before Rails - few people could say whether what DHH made was idiomatic or not. Did it solve a problem? Hell, yeah. Was it the best, most well-engineered piece of code out there - probably not.

All this is to say that we should work towards educating people that there are other kinds of problems that Go could solve, outside single-function lambdas, or a 100-LoC microservice. I think that this is what is missing in the Go community in general - good education outside of the scope of writing Go code. This is something you see very strongly among Rails, Django, Laravel folks - the entrepreneurial spirit, which drives curiosity, and lets them explore the boundaries of the tech, in the name of solving real human problems.

It's time to end my rant here. I think the only way to drive volunteer effort up is to show a real business need. If Revel, Buffalo, or whichever other Rails-like framework Go wants to grab the lion share, it needs to solve the non-tech problem first.

from revel.

Absolutely! It's just sad that there are so few of us that think that way. You can use pure Go from scratch, and use a kitchen-sink framework when you need to. I don't see why the majority think it should be an either-or-situation.

from revel.

@preslavrachev active development has died down, though we still have items on the roadmap we'd like to do to make Revel more future proof. Eg @notzippy did a lot of refactoring to abstract the HTTP server engine and template engine with other similar refactors on the backlog.

The big reason for the inactivity is a lack of volunteers. I took this project over in 2013 from the original author (Rob F) and actively used it and developed it. Most of my effort turned into recruiting and managing core volunteers as well as community patches and feedback.

Is it obsolete? No. I believe Revel has a real value to developers of web apps, specific Ruby on Rails like MVC apps. However, we've always had critics that Revel was going against the grain re:golang semantics. I've argued this with critics in the past.

I'd like to resume my effort on what originally attracted me to Revel: a performant and relatively simple language with a polished and familiar web framework. I'd like to keep enhancing features and performance on benchmarks to continue to attract developers as users and developers.

All that said, I have other priorities such as work and family, so my time is quite limited. This is why volunteer effort is so critical. I'm not fully confident we can secure volunteers given there are now MANY web framework options like Gin, Echo, Beego (IMO a Revel clone), etc. Not to mention node.js, PHP, etc, etc other platform options.

I'm open to feedback and advice!

from revel.

100% agreed that the focus of software should be on solving problems and NOT art for art's sake.

People in general easily get lost in stereotypes and quickly forget that life is not black in white 99.9% of the time. Purists are lost wanderers.

As a professional software engineer, we need to consider the needs/goals of each project and select the right tools for the job. Microservices/SOA have their own strengths and weaknesses and don't always benefit a product. Not all products want to manage the scale and complexity of distributes services.

That all said to emphasize that I agree, there is a niche to fill outside of whatever trend is popular in the moment.

I'd like to promote having a clear domain layer in web apps. Doing so allows the app layer to evolved eg from monolithic MVC to whatever is beneficial next (such as SOA). So there is more to explore there for Revel, too; moving fast early on while building a modular base for the future.

Thanks for sharing your perspective. If you'd like to join the core Revel team to shape the project's future, let me know ;)

from revel.

I think I'd like this guy if I met him in person lol.

"use the standard library...RTFM" lol

from revel.