
Echo – Golang micro web framework - vishr
https://labstack.com/echo
======
dudus
Go already has a few microframeworks. What I think it needs is a fat one. It
seems the idea of fat frameworks doesn't resonate well with go developers but
I don't understand why.

Django is the only reason I stick with python today for anything that will
have more than five pages. I want form handling, security features such as
XSS, CSRF baked in, debug tools such as debug-toolbar and I want to have a
basic login feature done for me.

Admin would be a plus but is not required.

Someone needs to write a good rails/django clone for go.

~~~
goldbrick
Go doesn't need a fat framework. If you need a fat framework, use Rails or
Django.

You don't have to (re)write everything in Go, you know.

~~~
rantanplan
Um why? Maybe you mean _you_ don't need one?

So if my language of choice is Go, you can somehow guarantee that I won't need
a fat framework? How?

~~~
konart
>So if my language of choice is Go

It seems like you are trying to fit everything onto this one choice. This is
never a good choice. One should chose technology or stack correcponding to the
porblem needed to be solved. Not vice versa.

If you need a tool such as Django - you should use one and use Go (both here
are for sake of example) for some small tasks, where it can give the most.

Building a new "fat" framework just because you like the langauge is kind of
strange approach.

~~~
rantanplan
So in your opinion I should switch to a whole different language/stack?

Who said building a fat framework since I liked the language? That's your
words no one else's.

Sometimes a fat framework is _needed_.. period. And if you need a fat
framework it doesn't mean that you should switch to Ruby or Python, because in
_your_ opinion these are languages for building fat frameworks.

BTW: python programmer for more than a decade. I've been in need for both
micro and fat framework in my career. I still don't get your argument.

~~~
konart
>So in your opinion I should switch to a whole different language/stack?

In my opinion one should use appropriate tools when building a solution. Using
a number of languages or tools that are appropriate for the task is not only
normal, but actually gives you better results anytime of the day, not to
mention freedom of choice, compared to when you are stuck with "one big thing"

>Who said building a fat framework since I liked the language? That's your
words no one else's.

>Sometimes a fat framework is needed

Okay, so name some of the reasons, otherwise mine assumption is only logical.
I, personally, can't see any reasons why would you _need_ a fat framework that
has to be written in Go and not in Python/Ruby/Java or something else.
Seriously, why?

>BTW: python programmer for more than a decade. I've been in need for both
micro and fat framework in my career. I still don't get your argument.

My argument is that if you need a fat framework - this does not mean it has to
be in some specific language. You have something like a counter argument?
Please share.

~~~
rantanplan
> My argument is that if you need a fat framework - this does not mean it has
> to be in some specific language. You have something like a counter argument?
> Please share.

I can't fathom how you can't think of counter arguments.

\- Because a company invested in Go?

\- Because they wouldn't want to have to maintain a lot of different
technologies/languages, _unless_ it's really necessary?

\- Because a fat framework in Go is going to be lighter than a fat framework
in python/ruby? (memory reqs, cpu, servers, etc)

\- Because Go is easier to reason with/maintain in large codebases?

And still, right now I'd choose python, but I can't understand how someone
would hold such strong opinions in such matters. Maybe I've seen too little in
my career? Or have I seen too much, so as to not jump in such strong positions
so easily? Genuinely curious and that's why I started this thread.

~~~
konart
>Because a company invested in Go?

I hardly can imagine a company that had invested _only_ in Go and will _need_
fat Go gramework. Seriously.

>Because they wouldn't want to have to maintain a lot of different
technologies/languages, unless it's really necessary?

Not a _lot_ of, but a number - once again, pretty hard to imagine something
serious going on here. And startups will hardly chose Go as their starting
point for obvious reasons.

>Because a fat framework in Go is going to be lighter than a fat framework in
python/ruby? (memory reqs, cpu, servers, etc)

Absolutely not necessary. You can build framework in C and had results that
will make you sad compared to that of Python. But even if it is - most likely
it will be more expensive and you will have to make a choice. But okay, let's
say it has some point.

>Because Go is easier to reason with/maintain in large codebases?

How so? In comparison to Python, for example.

>I can't understand how someone would hold such strong opinions in such
matters

Hey, I'm not saying people shouldn't write fat Go framework, or stop doing if
they've started already. If stars are lit - it means there is someone who
needs it. I just don't get why would you use something like Go for this.

~~~
rantanplan
>I hardly can imagine a company that had invested only in Go and will need fat
Go gramework. Seriously.

I don't know how to reply to this because I really don't see what's hard to
imagine, but ok.

> And startups will hardly chose Go as their starting point for obvious
> reasons.

Well that's obviously false, or you haven't been paying attention to HN, or
job listings :P

> How so? In comparison to Python, for example.

Static typing. In the case where you'd like to counter that point, I'm
_sincerely_ sorry, I'm tired of arguing over that point. I'd prefer if we left
it at that and say "we agree to disagree".

> Hey, I'm not saying people shouldn't write fat Go framework, or stop doing
> if they've started already. If stars are lit - it means there is someone who
> needs it. I just don't get why would you use something like Go for this.

Fair enough. Sometimes I just like to elicit responses in order to gain new
perspective/POV etc.

Cheers

------
njpatel
Have been using this for quite some time - it has a nice API and is solid in
production. I love the simplicity and it's small enough a codebase to quickly
read and start hacking around.

~~~
melle
Do you have any experience with gin?

If so, why do you prefer echo over gin?

Thanks

~~~
zeemonkee3
Personally I prefer two specific things:

1) echo is more middleware compatible - it's a PITA to use a lot of "standard"
Go middleware (e.g. nosurf) with Gin, but echo has no problems with these.

2) the function signature for handlers always returns an error - so you have
_func(Context) error_ rather than _func(Context)_. This feels a bit more like
idiomatic Go, and makes it easier to write generic error middleware for your
app.

In terms of performance, for all intents and purposes they're about the same
in real-world cases (the Go community for some odd reason loves bikeshedding
over router benchmarks, but in the real world this is probably the least of
your concerns).

~~~
njpatel
Agreed - those two points, and the general simplicity of the Echo codebase,
were why I ended up using it over the (many) other options for Go. Honestly
haven't had the desire to check anything else out since, it's just always
worked very well.

------
softinio
Personally I don't think golang needs a web framework. What comes with the
standard library is all that you need.

~~~
pram
Absurd statement. For starters: the mux/router included with the standard http
library isn't particularly good or performant, which is why most of these
projects like gin and httprouter were started in the first place. You'd also
have to roll your own middleware implementation, which means you'll end up
with your own framework at some point regardless.

~~~
sargas
Story of my life right there. The standard library will take you a long ways
in web dev (specially in prototyping), but ultimately needs a lot of
improvement that the community made in the form of 3rd party packages.

------
bigdubs
This is cool!

I'm actually kind of shocked it performs better than gin (which is based on
httprouter). Are you using a specialized prefix tree for the routes?

~~~
melle
I'm not sure this is the case, at least not according to the benchmarks in the
gin-gonic/gin repo.

This framework was submitted to HN
before:[https://news.ycombinator.com/item?id=9296524](https://news.ycombinator.com/item?id=9296524)

In that discussion the author of gin mentions gin has a zero allocation router
as well [https://github.com/gin-gonic/gin/issues/249](https://github.com/gin-
gonic/gin/issues/249)

On mobile right now, will look at the gin/echo benchmarks later (especially if
the gin benchmarks compare the fasthttp engine of echo)

~~~
melle
Looking at [https://github.com/gin-gonic/go-http-routing-
benchmark/blob/...](https://github.com/gin-gonic/go-http-routing-
benchmark/blob/master/bench_test.go)

All echo benches have been commented out, last change about a year ago.

Tests do not use echo's fasthttp engine.

------
zappo2938
I use express / node. It looks like I can map what I know to this framework
quite quickly. Is it worth the investment?

~~~
sargas
Here's one way to find you my friend: prototyping. Go is simple enough that
could give you a good idea of what your life will be like using a package in a
"short" amount of time.

------
vishr
Sorry for the confusion guys but now I don't have an option to edit.

------
debarshri
Does it support templates like handlerbar or jade?

~~~
nkozyra
Well, it supports returning a string from a handler, so ... yes. :)

------
zxv
Are there any compatible CSRF and XSS packages?

------
visarga
I thought it was going to be about the Amazon Echo.

~~~
atrudeau
Forget Rick rollin, Go Rollin is the new kid on the block.

------
InvisibleCities
Can a moderator add "Golang Web Framework" or something to the title of this
article? I would imagine that most readers would assume this is about a new
version of the Amazon Echo, and the current title seems almost engineered to
create that confusion.

~~~
BinaryIdiot
Yeah same thought. Honestly Amazon announced the Echo about 4 months before
this framework even became a thing. Personally think they should think about a
different name, even though they're not in the same space, to make search,
discovery and recognition easier.

~~~
hacym
Ecgo.

------
HeadlessChild
Terrible name.

~~~
dang
Please don't post snarky dismissals.

