Hacker News new | past | comments | ask | show | jobs | submit login

Totally agree. It's because of stuff like this that I find Go to be fairly tedious for full stack web. JSON microservice that's blazing fast is great. High concurrency workload, great.

Full stack website that reuses template parts with live data, manages sessions and logins, images, JavaScript and CSS...not so much.




Just curious, what were the worst gaps in functionality and have you looked at it recently? I'm pretty happy with Go for full stack web apps, but it did take a little while to get up to speed and a few years ago there were fewer solutions for common problems available. A few areas where it required some more work:

Authentication - there are a few good examples out there, I think gorilla secure cookie is good, CSRF protection too.

Authorisation - had to write my own version of the ruby lib cancan, am now happy with the solution

Images - stdlib is pretty good but it'd be nice if it handled resizing images and exif orientation tags.

Javascript and CSS - there are some ports of minifiers in go so an asset pipeline is pretty easy.

ORM - I use a query builder and use the map columns->fields in code, not keen on the orms using reflection and/or struct tags to do so. This doesn't have to be complex though.

Migrations - there are a few libraries out there now, so this isn't bad, I prefer sql migrations.

Templates - love the context-sensitive escaping, would be nice if it handled layout/partial but this is doable with some tweaks.

Forms - generation of views with text/template is pretty handy to handle things like CRUD forms for models.

This is where frameworks are useful - they present best-practices for the above details and more that you have to handle in a full-scale webapp.

I think those are the areas I'd like to see more tutorials on for beginners coming to Go, but there are solutions out there nowadays (far more than even a few years ago).Most of the things you mention are not in the std library so I guess people feel a little lost when they first arrive in Go land, but there are a few libraries out there like gorilla which cover most of this stuff or you can write your own, and once you have it's a really pleasant language to write traditional server-side apps with.

So with the above caveats I'm really happy with it for full stack web development.


I'd love to see some blog posts about this. The lack of any good resources on full-stack web frameworks is what has kept me from really diving deep into Go. I still believe (pretty strongly) in traditional, server-rendered, low JS overhead websites / app.


My biggest issue was with server rendered applications. I think it's a good fit for SPA's where each piece is rendered to the browser independently.

Just as an example, my go to test for most programming languages is to rebuild my personal site with it (http://brightball.com/). Just provides me with a good exercise in running through a simple project that I've done in multiple languages and provides a good basis for comparison without getting too fancy.

If you'll look at the page layout, you'll see the main content area with a list of articles, some sidebar elements that are loaded from the database and a list of primary tags in the footer (also pulled from the database).

The biggest pain point was the reusable elements (sidebar and footer) with the template system. In most other template systems it's pretty trivial to write parts that have code attached to them and tell a layout to call those pieces with some arguments. With Go, that was a bit of a pain requiring all of the data that that would appear on the page to be retrieved before starting the rendering process. That led to a lot of repetition to pull in that data on every path to the layout.

So the layout/partial system would be my biggest pain point. My first instinct was to go and reach for a framework but so much stuff that I read on Go boards gave the impression that the community seemed to have a very negative impression there.

Additionally, there wasn't a clear winner among frameworks which made me hesitate. That's a problem you see in languages that have so much stuff for the web built in like PHP and Javascript. It becomes so easy to do-it-yourself on the framework front that there are a million different flavors and no clear path.

With Ruby, Python, Elixir, Groovy, etc there are clear and dominant frameworks for the language. If you learn this language, you should know framework "X". When there isn't that clear winner, it's hard to justify investing in developing around it.

To try to get around that issue and the sense that with Go you were supposed to sort of assemble your own parts, not commit to a framework, etc I tried https://github.com/runemadsen/ok-go since it's basically a framework of assembled and replaceable parts.

After a while I just gave up on it and started looking at porting to Hugo before I found out about Elixir and gave it a shot. Ultimately, that was exactly what I was looking for (http://brightball.com/articles/insanity-with-elixir-phoenix-...).

Most of the issues I describe are non-issues if Go is backing a React/Angular app instead. I just found it to be a huge pain for entirely server side applications.


My biggest issue was with server rendered applications.

Thanks, this is what I'm talking about too (server-side web apps), I've found it a good fit, but do understand the initial difficulties with html/template - it is not very user friendly and was not designed for the sort of layout/partial arrangement that almost every web framework uses, however it can be used in that way with a little tweaking. That data has to be retrieved somehow though for the sidebar say, so I don't mind having to pass it in explicitly - it at least makes all the work being done explicit.

Agreed on the frameworks issue, frankly I find the hostility to frameworks on places like /r/golang tiresome and cultish - there is the kernel of a good idea in rejecting frameworks (they can after all straightjacket your code and invert control), but there can be many benefits to them and they provide essential pointers for those new to the language. I think for Go to grow it does need people to start to coalesce around solutions so that beginners don't have to reinvent rails again for every app or (worse IMO) start using JS for frontend and Go for backend - then you have two problems (or 400,000 if you use npm). I prefer server-side only and am happy with Go for that.

Elixir is on my list to check out, thanks for the link.


The templating is fast and safe but a pain to use. For example, an HTML Select needs a 3-value list: id,text,selected bool. You can't evaluate a comparison (if...) or call a function in the template. It's unpleasant.


You can call functions and methods in templates, and you can use if else, they actually have all the tools you need to do things like provide helper functions and produce a full html select with something like:

    {{ select "Order" "form_name" .value .options }}
Granted those helper functions don't exist in the base templates, but the tools are there to build them.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: