

Gadget: A smallish web framework for Go - redneckbeard
http://redneckbeard.github.io/gadget/

======
bernatfp
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](https://github.com/codegangsta/martini)),
that's exactly what I wanted.

~~~
codegangsta
Have you seen Martini?

[https://github.com/codegangsta/martini](https://github.com/codegangsta/martini)

~~~
recuter
I'm kind of amazed at the SLOC, ~600 lines for the whole thing. Flask is much
bigger and depends on Werkzeug (~20K?), heck even Bottle doesn't come in under
1,000 lines. That is incredibly attractive.

~~~
codegangsta
Yup I plan to keep it that way too. I believe there is enough flexibility in
Martini to cultivate some great functionality around the martini-contrib repo.
There is already some pretty awesome things landing there
[https://github.com/codegangsta/martini-
contrib](https://github.com/codegangsta/martini-contrib)

------
keda
Unlike Revel, you don't seem to have watch setup for .go files, which make
sense since you want to keep it smallish. Curious on how other gopher trigger
app restart from their editor of choice. Anyone have insight for setting up
VIM+Tmux for Golang development that enable app restart from single key press?
Sample .vimrc will be great.

~~~
redneckbeard
Recompiling and restarting the server has yet to become a bottleneck in
development for me, or at least it hasn't caused enough friction or irritation
to compel me to add something using fsnotify or other solutions. If you told
me that you were very interested in using the framework but the lack of this
feature was a barrier to adoption, I'd definitely think harder about it.

~~~
RBerenguel
I write plain handlefuncs, but so far I have a pretty easy to remember command
to restart the server for local development (works as well in Acme, where I'm
writing most of my go code as in emacs, where I write templates and vim, where
I usually just make really quick edits.) It's Cmd-Tab C-c [up] enter.

Just trying to express the same redneckbeard said: until it is a very thin
bottleneck, this should be no problem.

------
voidlogic
I would love to hear why I would want something like this, or revel, or goweb,
over: angular.js + Go web-service (net/http + Gorilla).

~~~
redneckbeard
I just don't understand the argument that we should all just use HandlerFuncs
for everything. Python and Ruby have stdlib HTTP facilities that are pretty
good. They aren't nearly as nice as net/http, but you could totally build
websites with them. People still have written lots of web frameworks, because
it makes their lives easier. It lets them express programs in a simpler,
higher-level way. I feel like this is even more valid now in 2013 since nearly
anyone who's building websites has done so with one of those high-level
frameworks, and they expect a similar experience.

Lots of people have abandoned Rails for Sinatra, or Django for Flask. That's
totally cool, and there are good reasons to do so. There are also very good
and obvious reasons to use something that further abstractions common patterns
if the software you are building conforms reasonably well to those patterns.

~~~
voidlogic
_> feel like this is even more valid now in 2013 since nearly anyone who's
building websites has done so with one of those high-level frameworks, and
they expect a similar experience._

But in 2013 do I really want to use server side HTML tempalating? Why not just
connect a webservice to a HTML/JS presentation layer like I am suggesting? If
all you are doing is building a webservice then the abstractions beyond
net/http + Gorilla are not buying you much IMHO, but they do come at quite a
performance cost:
[http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=json&l=cn4)

My first couple Go web applications did things the html/template way and were
structured on the way I used to go JSF applications- but since I switched to
the above approach my projects have been better performing, faster to develop
, better scaling and easier to maintain. As we all know, we seldom get all
those things in one technology choice without trade-offs.

~~~
grey-area
_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 means a significant
performance cost, or is harder to maintain or slower to develop, why do you
think that is the case? Caching and a server-side framework can make things
far faster and easier, depending on what you are doing, and raw speed of
rendering is not often an issue nowadays anyway.

I'm not sure what the test you pointed to there was showing, because using Go
to output json could be done with a framework too by just bypassing the
framework, in _exactly_ the same way. It hardly seems a relevant test, and
there were other issues in those tests when I looked at them previously - like
comparing wildcard routes in one test to hard coded ones in another. Comparing
bare JSON production with go to JSON production with webgo (do people use
webgo?) is hardly very useful or a fair comparison. It would be trivial to
make those equal in speed and I suspect the diff will just be down to
different routing and/or template rendering. In addition, I don't want clients
to see JSON, so the rendering speed of that is pretty irrelevant, what matters
to most people is when html finishes rendering.

It would be interesting to hear the reasons behind the string of assertions in
your penultimate sentence, are you sure all types of app would benefit equally
from your approach? Can you describe the advantages as you see them to this
approach?

~~~
voidlogic
_> 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 course I am not, I didn't make a that claim. I _think_ most typical
applications benefit, it has worked well for me. I was asking questions to
understand the point of view I don't hold-

 _> Can you describe the advantages as you see them to this approach?_

    
    
      In this approach: 
      Performance:
        1. Most assets are (server side) static
        2. They are pre-gzipped and stored in memory using a little reusable code I wrote.
        3. They are extremely cache friendly
      Better scaling:
        1. Only a fraction of the previous work happens server side... You using your users compute power.
        2. You are transfering less data.
      Faster to develop/easier to maintain:
        1. This way you have two differnt apps that happen to talk to eachother. This makes it easy to replace one or the other.
        2. Responsibilities are clearly defined. This makes brining new people up to speed easier and makes thingse asier to test, debug, etc.

~~~
grey-area
Thanks for the comments, it'd be easier to read if they weren't styled using
pre!

 _Of course I am not, I didn 't make a that claim._

Sorry, I should have phrased that differently as something like - _perhaps not
all types of app would benefit equally?_ I wasn't trying to put words in your
mouth. I do think it's a little early to start asking why anyone would use
server-side logic any more, there is room for both approaches :)

Perhaps if you are serving data which is text-only, static and fits well into
json as you describe, and don't mind coding in Javascript, client-side is a
better fit. If you have a lot of server-side data and editing/auth
requirements (more of a CMS), and depend on heavily nested templates etc,
server-side may be a better fit, though I'm sure it's possible to handle every
type of website in theory using either system. There is also the question of
which language you prefer to work in - personally I'd rather keep JS use to a
minimum, as it's pretty gnarly.

Re the separation of concerns, yes this is a valid point and is something you
gain from serving an API if you have a complex system, though it is possible
to have a back-end behind a traditional web framework too, with one side being
the API serving json or whatever and a separate user-facing service serving
HTML.

I don't think speed or caching are a big problem with server-side frameworks
nowadays though, and I'd rather use a language like Go than JS to produce web
apps. Out of curiosity, which client-side frameworks are you using?

~~~
voidlogic
I think we agree more than we disagree. Maybe we just differ on which approach
is our default one. I dislike JS as well and will be switching to Dart on the
front end when I feel it is ready.

 _> though it is possible to have a back-end behind a traditional web
framework too._

Sure I think you get a lot of the maintainability pro's this way, but loose on
some of the performance ones.

I mostly write systems software (in Go), but when I write webapps I use
angular.js (frontend) + Go (backend) + One of many datastores (ex MySQL,
Postgre, LevelDB etc)

------
bwooceli
As a "non programmer" this excites me greatly. I learned Python by way of
Django and can't wait to stand on some Go giant shoulders.

------
re-l
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.

~~~
elithrar
You could easily use something like gorp
([https://github.com/coopernurse/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.

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

~~~
ds_
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...

~~~
saiko-chriskun
Just came back from a go meetup where I met the developer of martini actually,
I think it's a really well thought-out framework :)

------
kin
This is an irrelevant comment but I love the name. I'm assuming it's a play on
the Go-Go-Gadget line?

