Not in the post: the go-start framework https://github.com/ungerik/go-start
Not in the post: beego https://github.com/astaxie/beego
On Go’s Web Application Ecosystem
21–30 of 50 posts
Re: On Go’s Web Application Ecosystem
#22I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…
Because Go is a general purpose programming language and why not web-layer? There is even a tutorial on creating wiki site on golang.org.
Re: On Go’s Web Application Ecosystem
#23I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…
Many other tools are good for web dev too, but having played around with it I'd say in principle Go is well suited to it, if you don't mind the lack of mature frameworks/libraries. I don't see why the syntax gets in the way of it being web friendly, which bit did you think would be a problem?
Deployment is far simpler with no libraries/gems/packages - single binary
Memory usage is an order of magnitude smaller than languages like Ruby or Java.
It's pretty fast (much faster than Ruby for example)
String manipulation isn't too painful - all the tools are there for manipulating unicode text and producing html.
Why not?
Re: On Go’s Web Application Ecosystem
#24Not in the post: the go-start framework https://github.com/ungerik/go-start
I guess there's a good reason for that...
view := Views{
DIV("myclass",
H1("Example HTML structure"),
Re: On Go’s Web Application Ecosystem
#25What I find interesting about Go[1] and the web application community is that people constantly point to speed as a huge selling point. Speed in the sense of latency and request volume per server.
I still feel like for the majority of cases, this type of speed difference is not going to matter. The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular Python framework at 18,945[2] (3.1 ms) is trivial when you look at the bigger picture.
If you are receiving enough traffic for that to make a fundamental difference, you'll likely have enough potential or realized revenue to pay for a few more [Flask, Rails, "slow" framework] servers, or have enough developer time to warrant building it in Go.
The upside to using a "slow" framework is massive. Try writing an app like Ticketee[3] in Go, even with Gorilla et al and you'll realize the productivity gains you're missing out on.
For a small API, backend services, command line apps Go makes sense. But the big selling point there isn't speed, it's likely deployability.
I love Go. It's good for teams, deploys well, is enjoyable to program in, does things quickly. But if a client comes to me wanting a web application with forms, view logic, payments, 3rd party integrations – I'll take my Rails, thanks.
> Given all this, frameworks (and ecosystems) like Flask, Sinatra, Django and Rails still have an advantage for when you want to get something done today: they’re very useful toolboxes, handle a lot of the boilerplate and have a lot of examples and packages to leverage.
The author clearly recognizes this opinion – but there seems to be an idea that you can just "use Go" in place of existing web frameworks. That's not the case (yet!). I think this is largely driven by the myth of performance requirement.
[1]: Things like Node.js probably fit into this argument too
Re: On Go’s Web Application Ecosystem
#26All this talk about HTML templating (html/template, etc) & Go web applications, is missing any discussion of what IMHO is a better way to write Go web apps:
1. Write a backend webservice in Go's net/http + Gorilla
2. Use something like angular JS to interact with those webservices. (From the server's perspective this means static HTML/CSS/JS assets that can again be served by Go, from memory if desired).
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.
Re: On Go’s Web Application Ecosystem
#27I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…
For me: • I prefer to find my errors at compile time. Consider the time to find and fix a missing method in a go compile (one 'make' and all the info is still in the developer's brain cache) versus eventually having a user drive the website into that method and having a mystery occur on a duck typed language. (hope you have good stack trace logging on the back end) • I prefer a language that doesn't repeatedly break…
Cool. All valid points. I have a question, do you think builds in Go for a large web app will remain fast? I ask from the experience of working in Java with several minute build/deploy times...
Re: On Go’s Web Application Ecosystem
#28I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…
Because it's fast, a pleasure to code in, and simple to distribute.
The distribution story is definitely appealing. I think it was only the other day a post showed up here with someone making command-line tools with it. I find this appealing.
Re: On Go’s Web Application Ecosystem
#29I think Go is still missing its killer-web-app-framework. But maybe it's better that way. Keeps out the people who don't like think before they code.
This article seems to be pushing Martini, which at first glance looks interesting (though it doesn't appear to have been mentioned on the mailing list even once, so there may be some boosting involved). There is Revel, but it seems to be getting a bad rap ("non-idiomatic" label used as a stick).
Martini author here. Weird how it didn't show up in the golang-nuts search, here is a link to the announcement topic:
https://groups.google.com/forum/#!topic/golang-nuts/LubMauy6...
Martini is still young (less than a week) but the core is pretty fleshed out.
No boosting here (I don't even have that many twitter followers). I just put together a framework that doesn't step on your toes and people ate it up :)
Re: On Go’s Web Application Ecosystem
#30I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…
Web servers aren't back end service-type-of-stuff?
I don't classify them the same. It's easier to have many web developers (in fact most I've worked with) who work on web app layer (working with the templates, javascript, depending on complexity of app the data-access-layer) than it is to have them working with messaging services, more complex data access logic, complex document rendering services, databased, our emailing management system, etc.
So, yes, I look at web server of an application as a pretty distinct part of the back-end, separated from many other complexities in the system. I also view it as the beginner (can't think of a better term [1] ) part of the back-end-system where there's a lot of devs who can conceptualize this layer who can't the other stuff. It's these devs whether I question they'll conceptualize GO in general.
[1] EDIT: I just thought of a better way to describe "beginner" with more clarity: non-computer-science-types who are competent at working in the web layer.