Live data from Hacker News

Gadget: A smallish web framework for Go

redneckbeard.github.io

41–50 of 52 posts

Re: Gadget: A smallish web framework for Go

#41

As a fan of Flask/Bottle/Sinatra/Express style web frameworks I miss a Go framework that works in a similar fashion. Don't know of any better way to prototype APIs so quickly and with such a small mental effort. Edit: Just discovered [Martini]( https://github.com/codegangsta/martini ), that's exactly what I wanted.

Have you seen Martini? https://github.com/codegangsta/martini

> "Handlers are invoked via reflection"

That's where I say NO. go's reflect package is slow and a nightmare to use. Go's JSON parser, which uses reflect, is 2.5x slower than Node.js (in my own benchmarks [1]). And Go 1.1 was 3.5x worse that Node.js at parsing JSON. Again, those are my benchmarks, but they seem consistent with what other people are finding (from my Googling around).

I would not make this trade off, I would not use reflect on EVERY request, just so that my request handlers are compatible with http.HandleFunc. It almost seems silly to do that. That's why other frameworks (like Revel) are using custom Request objects.

However, I do understand why the author is emphasizing this feature. If your handlers are incompatible with http.HandleFunc (i.e. if they take a custom Request object), you need your own Router which invokes the handlers, and you need your own ServeMux, so you end up giving up on a lot of functionality from net/http. That's why Revel has a ton of custom objects that mirror what net/http has and it proxies method calls.

So you keep wondering: "why the hell am I writing so much seemingly unrelated code? I just want to add a 'user' property to each request, but now I've coded so many struct's and created so many files". It makes you feel unproductive and it bloats the code.

Again, I've made my choice, but you should be aware of such caveats and, of course, benchmark things yourself.

1) My benchmark results. For some charts, higher is better, for others, lower is better. Use your judgement. http://goo.gl/xfWFXo

Re: Gadget: A smallish web framework for Go

#42
post #36

Damn, routers and controllers are not an issue in Go, models — is. I belive, that rich middleware between rich backend and rich client does matter. It isn't manipulating with html views, it's working with data. It's a proxy layer. And unfortunately, I don't see it in the modern Go web frameworks. Anyway, it's a great job.

You could easily use something like gorp (https://github.com/coopernurse/gorp) alongside Gadget (or any other Go web framework). Like Flask, the use of SQLAlchemy isn't innately tied to the framework.

Re: Gadget: A smallish web framework for Go

#44

Earlier quoted context omitted.

But in 2013 do I really want to use server side HTML tempalating? Many people do yes. It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar before I even see the content as json is turned into html, and I'd rather all the logic was server side and a flat page was served to a web client (browser). I don't agree doing rendering server-side necessarily…

>It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar This is how bad implementations look to users, consider something like Gmail as a counter example however... >would be interesting to hear the reasons behind the string of assertions in your penultimate sentence Sure:) >are you sure all types of app would benefit equally from your approach? Of co…

> This is how bad implementations look to users, consider something like Gmail as a counter example however...

Gmail isn't a counterexample to the "loading" message thing. It manages to be slow on hardware and network connections that are incredibly fast.

Re: Gadget: A smallish web framework for Go

#45

As a fan of Flask/Bottle/Sinatra/Express style web frameworks I miss a Go framework that works in a similar fashion. Don't know of any better way to prototype APIs so quickly and with such a small mental effort. Edit: Just discovered [Martini]( https://github.com/codegangsta/martini ), that's exactly what I wanted.

Have you seen Martini? https://github.com/codegangsta/martini

It looks really slick, and I'm considering switching over a go-backed JSON API to an Ember app I'm building to use it.

How's the performance? I'm a little afraid of the "reflection" boogeyman, but I don't have any experience to say what kind of impact we're talking about here.

I'm coming from Rails day-to-day, and a very light, compiled Go web backend is a refreshing change of pace. I'm leery of giving up the simplicity of net/http, but if it stays small maybe it's the way to go. Right now I'm popping in gorilla toolkit, though, so if martini is as "light touch" as that, I'd be up for using it.

Re: Gadget: A smallish web framework for Go

#46

Earlier quoted context omitted.

But in 2013 do I really want to use server side HTML tempalating? Many people do yes. It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar before I even see the content as json is turned into html, and I'd rather all the logic was server side and a flat page was served to a web client (browser). I don't agree doing rendering server-side necessarily…

>It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar This is how bad implementations look to users, consider something like Gmail as a counter example however... >would be interesting to hear the reasons behind the string of assertions in your penultimate sentence Sure:) >are you sure all types of app would benefit equally from your approach? Of co…

[deleted]

Re: Gadget: A smallish web framework for Go

#47

Earlier quoted context omitted.

Have you seen Martini? https://github.com/codegangsta/martini

> "Handlers are invoked via reflection" That's where I say NO. go's reflect package is slow and a nightmare to use. Go's JSON parser, which uses reflect, is 2.5x slower than Node.js (in my own benchmarks [1]). And Go 1.1 was 3.5x worse that Node.js at parsing JSON. Again, those are my benchmarks, but they seem consistent with what other people are finding (from my Googling around). I would not make this trade off, I…

Do you have the source code for your benchmarks? Thank you.

Re: Gadget: A smallish web framework for Go

#48

Earlier quoted context omitted.

Have you seen Martini? https://github.com/codegangsta/martini

It looks really slick, and I'm considering switching over a go-backed JSON API to an Ember app I'm building to use it. How's the performance? I'm a little afraid of the "reflection" boogeyman, but I don't have any experience to say what kind of impact we're talking about here. I'm coming from Rails day-to-day, and a very light, compiled Go web backend is a refreshing change of pace. I'm leery of giving up the simplic…

I have not tried this yet, but https://github.com/benbjohnson/megajson

Re: Gadget: A smallish web framework for Go

#49

Earlier quoted context omitted.

Have you seen Martini? https://github.com/codegangsta/martini

> "Handlers are invoked via reflection" That's where I say NO. go's reflect package is slow and a nightmare to use. Go's JSON parser, which uses reflect, is 2.5x slower than Node.js (in my own benchmarks [1]). And Go 1.1 was 3.5x worse that Node.js at parsing JSON. Again, those are my benchmarks, but they seem consistent with what other people are finding (from my Googling around). I would not make this trade off, I…

Your benchmark results look very different from that of the web framework benchmark:

http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...

In that benchmark Go's JSON performance is almost 3x higher than that of Node.

Any reasons why there's such a big difference?

Re: Gadget: A smallish web framework for Go

#50
post #4
post #2

Looks smart! Curiously, any reason you chose not to use Revel?

Or martini? I liked the look of martini but have not delved deep enough to make an informed decision. Might pick Go for my next side project...

The only thing I really see in martini over plain gorilla mux is dependency injection which has a reflection cost. Once you peel back the Classic mode, which I advise not using except for trivial projects, your code base is about the same. I'm sticking with gorilla.
Post reply on HN