5 ms·

On the subject of Go web development, I'll plug one of my favorite libraries: https://goji.io https://goji.io. It's a super-fast HTTP router that supports middl

by conroy 10y ago

On the subject of Go web development, I'll plug one of my favorite libraries: https://goji.io https://goji.io. It's a super-fast HTTP router that supports middleware and pattern matching.

petepete 10y ago
Vestigo is another very good choice https://github.com/husobee/vestigo https://github.com/husobee/vestigo
- weinr0ck 10y ago
  I used to use http://goji.io/ http://goji.io/, but once 1.8 hit and context was part of the request object there was little use for this library. Also, maybe it was just me, but I couldn't do very advance routing with goji. So I switched back to gorilla mux
brightball 10y ago
This is, IMHO, the PHP/Javascript problem showing up in Go. All 3 languages have so much bundled in for web development out of the box that it's too easy to create frameworks...so there are lots of them without any type of rallying standard. That's one of the reasons that I'm really averse to Go for web development that isn't just API based because you gain a lot from a complete, primary framework for web projects. It's one of the things that makes Elixir so appealing because you've got a clear next-gen-web winner in Phoenix with a language that brings you so much of what's good about Go due to it's Erlang/BEAM underpinnings.
- JetJaguar 10y ago
  This +100. I'm not sure who, other than fanboys, would argue that Go is on par with other languages when it comes to building a standard web app. Just take html templating as an example. Go feels like a kludge when it comes to this.
  - grey-area 10y ago
    What problems did you run into with templating in Go?
- always_good 10y ago
  You're just looking at one set of trade-offs and mistaking it for the best. Since people do not unanimously use large batteries-included frameworks, you must realize that some people prefer some batteries a la carte. Rails and Phoenix may win the large framework space, but they certainly don't win the web space.
  - JetJaguar 10y ago
    And Go does? What does "win" mean in this case? Productivity....market share??? 'cause, um no.
  - brightball 10y ago
    Never said it was the best, just that there are a lot of pain points that come from trying to use Go for a full stack development experience. Command line, workers, network and api layers are GREAT. If you have something that needs a custom solution...great. But the experience around managing a polished view layer, assets, routing, middleware, sessions, routing, redirects, migrations, database access, etc can get fragmented and tedious when roll-your-own becomes the defacto mode of operation. When a language doesn't have all of the web-native stuff built in by default (like PHP, JS and Go) the community around the language tends to organize around a framework experience that will eventually lead to a common development experience that people can further develop tooling around. It's not a knock on Go itself, it's just something that creates a noticeable side effect in the community in terms of fragmentation. People clearly WANT frameworks, because they keep rebuilding them. Doesn't mean you always need one, but it does mean that having a "winner" could be good for the community.

by conroy 10y ago

On the subject of Go web development, I'll plug one of my favorite libraries: https://goji.io https://goji.io. It's a super-fast HTTP router that supports middleware and pattern matching.

petepete 10y ago

Vestigo is another very good choice https://github.com/husobee/vestigo https://github.com/husobee/vestigo

weinr0ck 10y ago
I used to use http://goji.io/ http://goji.io/, but once 1.8 hit and context was part of the request object there was little use for this library. Also, maybe it was just me, but I couldn't do very advance routing with goji. So I switched back to gorilla mux

brightball 10y ago

This is, IMHO, the PHP/Javascript problem showing up in Go. All 3 languages have so much bundled in for web development out of the box that it's too easy to create frameworks...so there are lots of them without any type of rallying standard. That's one of the reasons that I'm really averse to Go for web development that isn't just API based because you gain a lot from a complete, primary framework for web projects. It's one of the things that makes Elixir so appealing because you've got a clear next-gen-web winner in Phoenix with a language that brings you so much of what's good about Go due to it's Erlang/BEAM underpinnings.

JetJaguar 10y ago
This +100. I'm not sure who, other than fanboys, would argue that Go is on par with other languages when it comes to building a standard web app. Just take html templating as an example. Go feels like a kludge when it comes to this.
- grey-area 10y ago
  What problems did you run into with templating in Go?
always_good 10y ago
You're just looking at one set of trade-offs and mistaking it for the best. Since people do not unanimously use large batteries-included frameworks, you must realize that some people prefer some batteries a la carte. Rails and Phoenix may win the large framework space, but they certainly don't win the web space.
- JetJaguar 10y ago
  And Go does? What does "win" mean in this case? Productivity....market share??? 'cause, um no.
- brightball 10y ago
  Never said it was the best, just that there are a lot of pain points that come from trying to use Go for a full stack development experience. Command line, workers, network and api layers are GREAT. If you have something that needs a custom solution...great. But the experience around managing a polished view layer, assets, routing, middleware, sessions, routing, redirects, migrations, database access, etc can get fragmented and tedious when roll-your-own becomes the defacto mode of operation. When a language doesn't have all of the web-native stuff built in by default (like PHP, JS and Go) the community around the language tends to organize around a framework experience that will eventually lead to a common development experience that people can further develop tooling around. It's not a knock on Go itself, it's just something that creates a noticeable side effect in the community in terms of fragmentation. People clearly WANT frameworks, because they keep rebuilding them. Doesn't mean you always need one, but it does mean that having a "winner" could be good for the community.