Buffalo – MVC Web Framework for Go
gobuffalo.io
gobuffalo.io
For large projects, using a framework and writing code the way the framework wants you to means that it's much easier to get new team members up to speed, meaning they contribute sooner and with less draw on other team members to teach them the nuances of your weird custom stack.
For small projects, and side projects especially, you can't/don't want to lose steam in analysis paralysis deciding on every little library and thing you want to use. Just pick up the framework that has made most of those decisions for you and focus on the business logic.
Rails nails this. Laravel is pretty good at this. Lots of others do this too (rails and laravel are where I spend my time). Sure, they might not be "exciting" but they are productive, and that, to me, is most important.
At work we have several dozen applications in service for multiple customers, and almost every single one needs more than that: authn, authz, I8n, DB schema management, a REPL for support work (debugging and data amends), standardized layouts and components from easy switching between projects etc. etc. If we were a larger org with even more applications we would probably benefit from microservices, but actually, Rails-style monoliths are exactly the right fit for us. If we didn't have a framework we'd have to pick a set of components and maintain the glue code to stitch them together, then re-use across products: IOW, we'd end up making a framework if there wasn't one already. At my last job, that actually happened.
Saying that the standard library is all you need is like saying that you don't need the standard library either, Go's Keywords are all you need.
Saying that the standard library is all you need is
like saying that you don't need the standard library
either, Go's Keywords are all you need.
I grew to web programming with Rails and Django, and trying out PHP (where to my knowledge nothing comparable exists, or apparently even could exist) for a few years felt like I had entered the stone ages. And that feeling did not pass.
[1]: https://laravel.com/
In my opinion, this is very dangerous. It is always better to understand the inner workings and then write an app, otherwise you just feel you have accomplished something when, in reality, it was just the framework you used and you didn't learn. I am saying this out of experience, when I used to use Django, I didn't understand the difference between GET vs POST. Still, I built a small note taking app, I didn't understand how cookies worked and until I wrote this: https://github.com/thewhitetulip/Tasks, I didn't know that the cookie details were read and sent to the sever in each request.
Frameworks are powerful in cases when you want new comers to get started quickly, but in my opinion that has to be after the new comers are familiar with webdev, so they know what the underlying tech are and how they work. Plus, frameworks need to be chosen with care, because you are basically bound to the framework you choose.
Personally, I like to write apps without a framework by using various toolkits, I never felt the necessity to use any framework, because they don't provide me with any distinct feature which I can't replicate with little additional code using the stdlib and supporting toolkits like gorilla.
From my experience building the Tasks application, I wrote an introductory e-book which teaches building apps with example, so no more magic! I didn't find a resource which taught how to write web apps using an example, thus wrote one.
https://github.com/thewhitetulip/web-dev-golang-anti-textboo... and on multiple requests, recorded a screencast: https://www.youtube.com/playlist?list=PL41psiCma00wgiTKkAZwJ...
the response struck a chord with me because a few years ago, I was just like the author suggested, someone who didn't know how to build a webapp and tried Django etc. Thus, I strongly that we need to understand the basics first.
Might I ask why?
These are tools, not competing world-views.
It is an assumption that amateurs will defer learning due to the framework. It also seems as though there is another assumption that all the people using this framework are somehow amateurs. It is convenient to be able to write a quick program using a framework and then being able to scale that project as it grows.
This is a code generator. Looks very useful to me.
- Use a framework that someone else did. You will have to spend time learning the abstractions of the framework.
- Spend time building your own framework, creating your own abstractions.
- Create a massive amount of spaghetti that, at some point, no one -including you- will want to maintain.
I do use https://github.com/urfave/negroni for routing. But otherwise i just use the http package.
The main issue I ran into when trying to develop a web app with Go was debugging. Web apps are multi-tier systems, and Go doesn't give you stack traces when something goes wrong, which is something I don't have the patience for when there are plenty of good and mature languages to use that do have stack traces. I know a common response to this is, "just practice better system design," I'm not one of those people who believes that I need to define an API for every internal piece of code. I just want to be able to find an error quickly and move on. Does Buffalo have a solution to this? I really like it so far.
Buffalo isn't a framework, unless a router + few bells and whistles is now considered "framework".
There are lots of abstractions in Go - e.g. structs, interfaces, goroutines, channels. It may not have all the abstractions you're used to (e.g. inheritance, generics), and might still be lacking in areas, but your statement is extreme hyperbole and not useful.
As to whether something is a framework or not, why is this important to you?
These are not abstraction a Go developer is writing himself. You are talking about language features. Indeed, the languages cheats and does things the users is not allowed to do, like append or delete functions.
the languages cheats and does things the users is not allowed to do, like append or delete functions.
I agree and find this slightly distasteful too, but I think it was borne of pragmatism. There is definitely also a cost to language purity and parsimony, and I'm glad they're a little pragmatic, but collections are the only area I've felt the language is seriously lacking in elegance (maybe option types would be nice too).
Personally I find it quite pleasant to create abstractions in, those grips notwithstanding.
"But there's a fine line between a friendly suggestion and a belligerent diner. That line is usually exposed when the suggestion is declined: "I'm sorry, but hotdogs don't really fit our sushi menu, and while you may not care for unagi, we picked it for a reason. But thanks for the suggestions!". If only most arguments about the menu would stop there.
But they don't, do they? They usually carry on and on. BUT I REALLY DON'T LIKE UNAGI!!! IT'S OFFENDING MY TASTE BUDS THAT IT'S PART OF THE DEFAULT COURSE SETTING. TAKE IT OOOOOOFFFFF!! Okay, buddy, sit down and have a sake." http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...
Don't get me wrong, I love the language, however, I think about this everytime I read about language proposals being nuked (cough generics).
It's open source. Why don't you contribute?
Does it personally bother me? No. But I think the expectation is reasonable.