<p>Hey gophers, I have been using Go mostly for REST API's and CLI Apps for about six months and have been loving it so far, but as my next step i want to build a dynamic website, I'm very comfortable with Laravel and have build a couple of those with it so naturally I'm looking for a framework with a MVC design pattern in mind (maybe <a href="https://github.com/gobuffalo/buffalo" rel="nofollow">Buffalo</a> is a good option) but i feel like by doing it I'm going against how a Go program is supposed to be, clear, simple and concise.</p>
<p>I have been exploring other options for this, for example having a front-end written in Vue/React/Angular and doing api calls to a Go server, but I'm not sure if it is the best option for a project like this, what I'm trying to ask is what is the most solid way of writing a dynamic website in Go and why?</p>
<hr/>**评论：**<br/><br/>hutilicious: <pre><p>I think noone can give you THE solution to your question. For me, building a Vue site making api calls to your go server and host your site on your go server (static file server), seems just right and should be more than powerful</p></pre>zevdg: <pre><p>For now, I'm inclined to agree that your instinct to look outside of Go to do front end development is the most straightforward path. Here are the options as I see them.</p>
<h2>Simple sites</h2>
<p>If the dynamic functionality you need can mostly be done on the back-end (aka server-side), then <a href="https://golang.org/pkg/html/template/" rel="nofollow">https://golang.org/pkg/html/template/</a> is all you need. You can have a few lines of vanilla javascript in your template for minimal front end execution without requiring a whole framework.</p>
<h2>Complex sites</h2>
<p>When you will need a lot of front-end (aka client-side) execution, using Vue/React/Angular/etc. for the front-end and relegating Go to the back-end is the most common approach.</p>
<p>This approach is a great solution for polyglots who value choosing "the right tool for the job". Just like how, IMO, Go is a much more natural fit for a backend than javascript/node, the javascript community has done way more experimenting in the web MVC space, and as a result, their solutions are much richer than what Go currently offers.</p>
<h2>Transpilation</h2>
<p>That said, there are advantages to having your front end and back end in the same language. Isomorphic patterns, less cognitive context switching, and faster training all make a single language solution compelling. To that end, Go does have a few projects that transpile Go code into client-side javascript, namely <a href="https://github.com/matthewmueller/joy" rel="nofollow">joy</a> and <a href="https://github.com/gopherjs/gopherjs" rel="nofollow">gopherjs</a>/<a href="https://github.com/gopherjs/vecty" rel="nofollow">vecty</a>. </p>
<p>Gopherjs has been around longer, and joy doesn't have a companion framework like vecty, at least <a href="https://github.com/matthewmueller/joy/issues/80" rel="nofollow">not yet</a>, so if you want a Go web MVC framework today, vecty looks like the best (only) option.</p>
<p>Maturity aside, the bigger difference between the two projects are their goals.</p>
<p>GopherJS was created to run arbitrary Go code in the browser. While the quality of the generated javascript is important, it isn't as important to the gopherjs project as supporting the full Go language. </p>
<p>Joy was created more as an alternative to typescript. The quality and size of the generated javascript are more important than supporting the full Go language. Go features that are not supported by the joy transpiler will result in a compile error.</p>
<p>More info in the <a href="https://mat.tm/joy/#faq-gopherjs" rel="nofollow">joy FAQ</a> and <a href="https://github.com/matthewmueller/joy/issues/56" rel="nofollow">this github issue</a>.</p>
<p>Lastly, as much as I love Go, I'd argue that javascript currently has a better story on the server-side (node) than Go has on the client-side. If you need to start a single-language, full stack project today, javascript will serve you better than Go will. Hopefully, that will change once <a href="https://github.com/golang/go/issues/18892" rel="nofollow">WASM support</a> lands in the Go compiler and WASM evolves to <a href="https://github.com/WebAssembly/design/issues/1079" rel="nofollow">support DOM and other Web APIs</a>. Until those two things happen, Javascript is a necessary evil of client-side development. Your only choice is whether you want to write it yourself or let a tool generate it for you.</p></pre>darklumt: <pre><p>Hey, thanks a lot for the detailed information about the choices for this project, I think I'm mostly interested in using templating with HTML/basic css or using a js framework, even though I don't have any experience with one, but how do you know when what you are building is complex enough to the point that a framework like Vue is actually helpful? When does using html/css is just not enough?</p></pre>zevdg: <pre><p>So I'm currently writing a progressive web app using Vue for my front-end and firebase for my back-end. I'd argue that if you think you <em>might</em> want a framework eventually, it's safer to just start with one now. Vue and (p)react are both simple enough to not be massive overkill for small sites, and then you wont have to rewrite the whole thing if/when it gets complex enough to need a framework.</p>
<p>I wouldn't use a framework if I had a go service and I just wanted to expose a simple admin webpage. Something to view the service's health and maybe change the log level. Same with a blog site or something else with a lot of purely static content.</p>
<p>Almost anything you'd call a "web app" I'd reach for a framework.</p>
<p>Finally, if you want something with most of the benefits of a framework, but without a big fat js layer between you and the native web platform, I'd check out polymer and <a href="https://github.com/Polymer/pwa-starter-kit" rel="nofollow">their new starter kit</a>. It's still early days, but polymer3 + lit-html feels much saner and more go-like than the direction the rest of the web community is going.</p></pre>darklumt: <pre><p>Thanks a lot for the advice and recommendations, will check out polymer!</p></pre>SeerUD: <pre><p>I'd personally go with the approach you've outlined. Use front-end tech like React, with server-side rendering, making calls to your Go-based HTTP web service(s).</p>
<p>You could use something like PHP for it, but I'd personally prefer to use a more modern stack that provides a richer front-end experience. Of course, if you're planning on making a stupidly simple site then you won't need it however.</p></pre>darklumt: <pre><p>The project itself is nothing too big, but nothing too simple either just enough complexity to really learn and achieve what I'm trying to do, displaying a lot of data from the db, accepting queries, updating data that sort of stuff, so I think it's enough with the template package.</p></pre>
