I always defer to frameworks when working on any project, large or small, so this looks really cool to me as we have been debating on breaking out some of our high volume components into microservices at work and Go is an option.
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.
Depending on how micro your microservice is and if it really is high volume (not sure what high volume means to you) then I would recommend just stick with the standard library to start and grabbing other libs as you need. I wrote a simple internal microservice handling ~400k req/s at peak with no framework and it works great. I can see the appeal of the framework in getting something up and running really fast with one command, but that amount of time in the beginning that it saves is insignificant compared to the long term lifecycle of the project.
I think that it depends on the size and number of your projects. The fact that Go has the equivalent of Sinatra/Flask/Express in the standard library is really cool, but that isn't always what you need.
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.
We know that standard library is enough But there is always need for a framework if you do the same thing over and over again. The consensus in the GO community seems to be that you create from scratch every-time the same handlers, utilities etc. And practically we have ended up with everyone having their own in-house framework. There is nothing wrong with not wanting to create the same helpers every time or not wanting to have your personal framework.
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.
Not really sure what you mean by that. I didn't say the standard lib is all you need I said start with the standard lib and add other libs when and as you need rather than starting with everything in the beginning. In my experience you end up fighting the framework in the long run, but if you like them use them.
That REPL is awesome and an actual differentiating factor.
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.
In the PHP space I know Laravel has an "artisan tinker" command which gives you a similar REPL where you can do at least some of the things demoed on the Buffalo site. This seems to be increasingly common to have for web frameworks from my somewhat limited experience.
Indeed, artisan tinker is quite close to what Rails and Django give. The REPL is a bit awkward when compared to ipython, though, but that is probably fixable. If they'd just do it :)
As a Laravel developer that listens frequently to Taylor Otwell on the Laravel podcast[1]: yes, it is. I heard Taylor say multiple times that one or more parts of Laravel are inspired by RoR.
Go is such an easy language as it is, these kinds of frameworks just encourage amateur developers to skirt by with minimal understanding of what they're really doing. An MVC framework sounds like a great personal hacking project for fun, but I would beware of advertising anything like it for professional use.
What's so wrong with getting productive faster. Learning takes time. It is not very hard to write Go web apps with the standard library, but it may be more convenient to use a framework for the sake of time.
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.
> with minimal understanding of what they're really doing
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.
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.
I think most devs would have the flexibility of mind to adjust to whatever framework (or whatever ad-hoc, informally-specified implementation of half a framework) you use in-house. Many of the frameworks are not very different and lean heavily on the stdlib anyway, this is not rocket science, frameworks have different uses and strong points and the community does not have to be divided in religious war between different frameworks or framework advocates and the church of the one pure stdlib.
I am sorry, I still didn't get your concern. It is easy in my opinion to identify the person writing Go code. Look at their Github profile! (I am not a recruiter, so I don't know how effective that really is, but Github profile does reflect a person's contributions to FOSS and if the person is a FOSS contributors, look at their repos or their other PRs or their projects)
I think in practice most of the time, you dont need a framework for webapps in golang. A simple http handler with json / templating etc output is very simple to write. The net/http package is very powerfull, but still has a lean api.
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.
I think the main point of Buffalo is using the common web app libraries that are used most. Yes it's still important to understand how it all works underneath the hood. Coming from a Rails background, Buffalo makes me really enjoy web development. I feel this is what Rails was to Ruby in a way.
"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).
Nothing can be omakase in Go. The language disallow it, unless you completely opt out of its type system. But then, what's the point of using a statically typed language? Go is built in a way that forbids writing abstractions. When I say forbid it really does forbid it. Even C is more expressive.
Buffalo isn't a framework, unless a router + few bells and whistles is now considered "framework".
Go is built in a way that forbids writing abstractions.
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?
Not op, but a framework vs toolkit is important to me. I like the gorilla toolkit because I can easily take parts or leave them or create them. I've not investigated buffalo, but the term framework instantly gives me a bad taste in my mouth. When I think of a framework, I think "our way or they highway" and the very moment you need to do something a bit different than what the framework expects or assumes, you are in for a world of hurt.
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.
Well structs, interfaces do allow the user to create abstractions, in quite a nice way I think - it's very bare-bones compared to say inheritance in C++, and deliberately so.
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.
It tries to install webpack globally which it can't because I'm not running it with sudo and I have it installed already anyway. I see I can skip adding webpack to the app but can I just skip the installation part?
Unfortunately I don't think your attitude is particularly constructive either. Out of the many (many many) web frameworks out there, why should parent bother with this particular one? I think asking for a mobile optimized website is reasonable in 2017.
Does it personally bother me? No. But I think the expectation is reasonable.
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.