Comment by grey-area | Hacker News Reader

Comment by grey-area | Hacker News Reader

Parent Full thread

What's missing in Go/Gorilla for web dev?

Well, it covers:

Serving (great built-in server for net/http)

Routing

Sessions

Context

--

It's missing:

Authorisation

Authentication

Parameter Validation/Checking

Asset management

Migrations

Cleaner templating (I prefer mustache to the built-in go templates)

HTML Helpers/View Helpers

Form Helpers

ORM or other persistence helpers (controversial I know)

Possibly scaffolding would be nice too and a suggested project structure to encourage sharing

--

So there are a few things which you'd generally expect in a web framework which aren't there yet. Of course some of the above list is subject to debate, some is available in revel, some it not everyone would agree is even necessary, but most other platforms in other languages have a bit more to help you, even if they are minimalist. Even just having an agreed-upon set of conventions and structure for web projects (a la rails), speeds up comprehension when looking at any large code-base.

I'm quite confident Go will get there, and having tried it out am really impressed with the language and the culture, but it would be disingenuous to suggest it has everything you'd need to produce large web apps currently - at present you have to write your own code for quite a lot of the above.

The Django admin interface is indispensable, too. Plus, you have all the pluggable apps for everything you might need.

I do think this is both a strength and a weakness. Admin interfaces and plugins/apps are great to get you up and running fast (this is similar to the scaffolding point above), but they are also the part of any ecosystem which introduces subtle bugs and dependencies.

By the time you get to crud admin and plugins, you're at the point where the benefits of the framework start to come with significant additional costs (in maintenance, flexibility, comprehension etc). A pre-built app or plugin gets you up and running quickly but when you start to modify it you really need to understand the entire app/plugin before you can do so efficiently. Often people feel this is as significant a roadblock as simply writing it from scratch in the first place.

Any complex webapp is probably going to outgrow standard admin/scaffolding, and any complex usage is going to require modifications of things like plugins and gems, so while they're nice to have in an ecosystem I don't see them as essential. This is an area where django has more built-in that say rails though, and it'd be interesting to see a Golang framework trying to take the best ideas from all these other popular frameworks.

I disagree with that, they made the Django admin interface really easy to extend, and entirely pluggable. If you don't like any part of Django, you can roll your own, while using the Django-provided functionality until yours is ready.

I would agree if the components were tightly coupled, but Django is very well structured to let you substitute any component. At any rate, it's much better than writing everything yourself outright, and I'm speaking as someone who has launched more than 10 Django-based products.

That said, I really want to try out Go...

Care to contribute some of those to Revel? :)

Out of curiosity, why do you prefer Mustache to Go templates? They seem extremely similar, with Go templates being slightly more powerful due to easy-to-add template funcs. Both are essentially data-driven though.

Would love to contribute but unfortunately have just been tinkering with Go; not using it for paid work, and therefore don't have much time for it. I like the look of revel though, and will be spending more time looking at it.

Re Mustache versus go templates, I preferred the restrictions and clarity of mustache, because it forces you not to put any code in the view, all you can have are the basic constructs it provides, but it doesn't miss anything major IMHO. Here are the things I needed, which it provides:

* loops

* partials (with the neat {{> partial}} syntax

* nested contexts

* escaping by default

* clear named keys, no '.' prefix, though I guess . would be OK between keys for subkeys (not possible in mustache as yet)

* limited contexts (so that it's obvious what is being called)

The differences are not major, and frankly either is a fine choice, but I actually preferred the limited syntax of mustache, and found the go template setup needlessly complex, in particular when including partials, I didn't spend too long on the decision though so perhaps I just misunderstood...

Django's admin is brilliant if it fits your use case. I've solved so many customer problems just using the admin, it's silly. It's what's kept me on Django and off all the microframeworks du jour.

So add me to the list of people who'd like to see something comparable on Go.

Reply on news.ycombinator.com