The Case for Go Web Frameworks

[horrido...@gmail.com]

The Case for Go Web Frameworks

It's been posted at Reddit, too.

This is sure to ignite a firestorm of controversy. Will the issue ever be settled??

[Ibrahim M. Ghazal]

I already use a minimalist web framework, it's called http.Handler[1]. And I consider any third party library that implements it (such as gorrila/mux[2]) a plugin for this "framework".

[1] http://golang.org/pkg/net/http/#Handler

[2] http://www.gorillatoolkit.org/pkg/mux

[tomwilde]

The only difference between "a bunch of libraries" and "a framework" is that in the latter the libraries in question build upon each other and hence depend on being shipped in a bundle.

Because types in Go can implement interfaces without saying so, the need to ship libraries together arises seldomly and it is easier to just provide "a bunch of libraries".

This is what we've been doing and it works.

[Kamil Kisiel]

Re: "Business Reality"

I've written several Go web applications using nothing but net/http (and occasionally a package or two from gorilla). At no point in the development of any of them was the lack of a framework a hinderance. Any minor bits of HTTP support code that needed to be written were trivial in comparison to the actual application business logic, and in most cases just creating what we needed was less work than it would have been to shoehorn the whole application in to someone else's framework. Some of those bits have been included in the github.com/gorilla/handlers package where they exist as types which easily compose through the http.Handler interface.

You also talk about frameworks being convenient for newcomers. That may be true in some cases, but it has not been my experience in the past with Python and Ruby frameworks. A newcomer often needs to spend as much time learning the framework's special ways of doing things as they do the language itself. Keeping things simple means fewer things to learn, and with Go you just need to know the language and a few functions from the net/http package to get started.

In my experience I've had people join the team I was working on with no prior Go knowledge and be able to work on the http components of our applications pretty much immediately. I think that says a lot about how well designed the standard library http package is, and I don't really see the need to throw on huge external dependancies on top of that.

[Andy Bonventre]

“A framework provides higher-level abstractions that hide the more complex details underneath. This is how you achieve greater simplicity and safety;”

Hiding complexity is not a path towards simplicity.

Rich Hickey has a good talk on the difference between easy and simple — https://www.youtube.com/watch?v=rI8tNMsozo0

As he argues for the “business reality” of the situation, most businesses I know that use Go in prod for mission critical paths (Square, Timehop, Poptip, Spring...) all use net/http. The idea that it’s low-level seems like a silly argument to me.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Henrik Johansson]

The arguments are based on a number of false premises I think.

Don't get me wrong, if you like frameworks then by all means use them.

I think however that they rarely save time and they add overhead. Not the overhead mentioned in the article but cognitive overhead.

The library approach can of course do that as well but the benefit of not having to understand (yes just using a framework is never a good idea) a potentially large and all encompassing framework should not be underestimated. Hiding complexity does not mean the complexity is gone.

The assumption that framework code ages with grace in the same way as custom code is not just true. Have you worked on a Struts 1 (old java web framework)? Well thatnkfully I have not in quite a while but I did once and it was way past its retirement time. Horrible. We had to patch and fix issues and getting general help online was difficult at best. No frameworks age worse in general I would say.

Sure, the barrier to entry can be lower but the assumption here is that the barrier is high. It is not.

Then there is the assumption that companies must standardize everything in detail. Ok, assuming it is right then I say the stdlib is the standard. When you find good patterns sure create or find a library that fits. Up front tool selection across the board generally feel desperate reeks of distrust. End rant.

[Shawn Milochik]

As a Web developer for about 15 years who has done things with and without frameworks, I'll throw in my opinion.

I agree with Henrick. My past 5+ years with Django has soured me on "robust" frameworks and ORMs. There's obviously an excellent middle ground. In Python I like Flask (and some of the other small/micro frameworks are probably just as good). I like Go's standard library and was able to make a Web app with no problem or pain using just the standard library. I did use some additional projects for other functionality, but all the HTTP-related stuff was all Go.

In Go, the "middle ground" between a framework you have to learn and doing it "by hand" is just in the standard library. I think this statement is fair because the standard library is written in Go, so it's still possible to do it "by hand." The standard library is just better-suited to modern that those of other languages because of when Go was created.

In short, people need to stop thinking that "only using the standard library" is a limitation or somehow hard or manual. It's that way in most other languages for Web development, but Go's is just more modern.

[Ian Davis]

I suppose since Go has taken away brace positioning and single line if statements as objects of contention we are reduced to bikeshedding about frameworks vs libraries.

 

Seriously, just use whatever makes your code clearer to the next person and gives you the performance you need.

 

Ian

 

[Klaus Post]

I think frameworks has their place, but it is important to see if it matches your need.

I use Revel for a big project, and I think we actually benefited from it. the really good part about revel is that most parts can be modified fairly easy, and it uses only a small amount of "magic" for route function generation. Magic makes things seem easy, but you have to understand it anyway if you are seriously going to work with it (Martini comes to mind).

Features we use:
* Autorebuild server when any go file has changed since last request. Revel has a nice feature where it puts a reverse proxy in front that stalls the request while the server is being recompiled. Nice thing we didn't have to write that ourselves.
* Package feature. It can package up itself and resources for deployment. That made it rather trivial to create a deb package for deployment.
* Autoreload templates on changes in dev mode. Trivial to write, but nice to have.
* Simple i18n features - we've had to change/extend them a bit, but works fairly well.
* Can fire up Grunt for compiling JS/SASS - again requests are being stalled so you don't get "partial files".
* Routing and parameter passing. We've written our own REST api wrapper, but again revel seem pretty flexible, but that lives nicely along.
* Server configuration files.

So most of the stuff is convenience that makes development easier. If we had started with a net/http + gorilla mux I think a lot of these features would have been on the "nice-to-have" list, but we actually didn't have the time to implement. Also Revel provided a structure for me to work in, and since this was my first big go project that meant I didn't have to "invent" these thing myself. As time moves on, of course you find that things could be tweaked.

I also like that Revel is 'bring-your-own-ORM' - that way we can have a much cleaner model interface, where we use the type safety of Go much better, and the awesome mgo interface for easy interfacing with the DB and implement consistent caching and search without having to "battle" a ORM - at least for this project.

So, a "no big regrets" from someone working about 6 months on the same project in a web framework, albeit one of less "flashy"/"magic" ones.

[Andrew Gerrand]

On 22 October 2014 01:51, <horrido...@gmail.com> wrote:

This is sure to ignite a firestorm of controversy. Will the issue ever be settled??

Really? There are people who prefer frameworks, and people who don't. Does this preference need to be a source of controversy?

The divide exists not just in the Go world. There are similar debates in the Python and Ruby worlds, too.

In general, Go philosophically prefers small, simple pieces, so naturally the Go community leans away from frameworks.

But it'll never be "settled" because ultimately it's a matter of taste.

And that's just fine.

Andrew

[Rick]

Andrew Gerrand for President!

[Jesse McNelis]

net/http is a webframework for any reasonable definition of 'webframework'.

[horrido...@gmail.com]

I've been using web frameworks for over 8 years. My first foray was with Smalltalk/Seaside. A few years later, I used Python/web2py. And this year, I migrated to Go/Beego. In every instance, I read just enough documentation to get started, and then I proceeded to write a non-trivial application in record time. I did NOT need to know everything about the framework upfront. The time I spent was minimal, compared to having to evaluate a large number of third-party libraries, and subsequently integrating them into an application. Using a framework saved me a great deal of time and energy. This is absolutely indisputable.

Later, as my application needs grew, I delved into the frameworks' documentation in greater depth. Neither Seaside nor web2py constrained me in any way as a web developer. I expect the same to hold true with Beego.

The key, I think, is choosing your frameworks well. Not all frameworks are alike. Seaside and web2py are well-designed to be easily approachable, highly productive, and flexible. I would recommend them unreservedly. So far, Beego looks very good. I may recommend it once I get more experience with it.

[horrido...@gmail.com]

I agree with Rich Hickey. But what I mean by simplicity is rather different. Web development is complex. In order to make it approachable for newcomers, you need to present a simplified environment that lets the user get to his first application quickly and easily, without a heavy cognitive load.

If you've ever tried Seaside or web2py, you appreciate how enormously productive you can be. These frameworks are easy to use, and yet, they are very powerful. (A well-designed framework need not limit the kinds of applications you want to write.) They saved me a lot of time!

That's what I mean by simplicity.

[horrido...@gmail.com]

For me, at least, using a well-designed framework has dramatically lessened my cognitive load. Reading just enough of the docs to get started (you don't need to know the entire framework all at once), I wrote a non-trivial application astonishingly quickly. If I had to cobble together a bunch of libraries (either in Smalltalk or Python) in order to get a working app, it would've cost me a great deal more time and energy. Of this, I have no doubt.

I can't speak for all frameworks (and neither can you), but frameworks such as Seaside and web2py are extremely well-supported. Moreover, their user communities are immensely helpful. I can only hope the communities for Beego and Revel match this level of quality (so far, I'm not terribly impressed, based on what I've seen on their user forums).

Writing a web app using Go's stdlib may not be arduous. But depending on what kind of app you're writing, you may need to integrate a number of libraries (including third-party) by building the appropriate scaffolding. This is time-consuming. It may also be error-prone (who among us can write bug-free software?). This is where the barrier to entry may be higher than using a framework.

[ca...@doxsey.net]

From the post:

 

This happens whether you use a framework or not. The minimalist, “mix-and-match” approach that many Gophers advocate will not avoid the eventual software attrition.

I disagree with this. Most Go libraries make very few assumptions about the context in which they are run. They don't assume you are in a web framework with sessions, cookies, ... But rather rely on fairly common Go patterns. (Readers, Writers, ...)

Libraries like that can survive a rewrite.

The problem with frameworks is they often introduce dependencies into libraries which make it very hard to pull them out later. You see this with rails, django, node.js, ... Just speaking from experience, it's not at all uncommon to find a useful ruby library that you can't use outside of rails, so you end up with forks: rack-coffee vs sinatra-coffee vs coffee-rails,. ...

By definition, mix-and-match exposes you to different libraries with different APIs, which in turn require you to write different glue software for every mix-and-match combination. So basically, a newcomer has to be thrown into the deep end and fend for himself.

There's definitely room for better documentation and examples, but this is what programming is. You glue together libraries. If a newcomer doesn't learn these skills they can't write robust, reliable and maintainable software. Quality is just as much a business concern as speed. 

We shouldn't pretend like it's possible to build web applications by copying and pasting a bunch of examples from stack overflow. I've inherited those projects, been through the pain of the rewrites, and even seen a company ultimately wiped out by the inability to move forward on an application.

If - merely as an accident - Go keeps us from that delusion, maybe we're better for it.

[will]

Hey Andrew,

Is there a possibility that we might get visitors statistics in the net/http package such as number of visitors per day etc etc?

Will

[Qian Qiao]

On Tue Nov 04 2014 at 9:06:02 AM will <wma...@gmail.com> wrote:

Hey Andrew,

Is there a possibility that we might get visitors statistics in the net/http package such as number of visitors per day etc etc?

Will

Can you not just log and then run it through some log processor?

This requirement seem highly specific to your own use case.

-- Joe

 

On Wednesday, 22 October 2014 02:03:47 UTC+2, Andrew Gerrand wrote:

On 22 October 2014 01:51, <horrido...@gmail.com> wrote:

This is sure to ignite a firestorm of controversy. Will the issue ever be settled??

Really? There are people who prefer frameworks, and people who don't. Does this preference need to be a source of controversy?

The divide exists not just in the Go world. There are similar debates in the Python and Ruby worlds, too.

In general, Go philosophically prefers small, simple pieces, so naturally the Go community leans away from frameworks.

But it'll never be "settled" because ultimately it's a matter of taste.

And that's just fine.

Andrew

--