Go Template Engines or JS FrameWorks on the Frontend?

<p>I&#39;m sort of new to golang, used to code with node js and react for most of the time. Now that I&#39;ve join the gophers army, I&#39;m looking to find out what other devs here use for coding on front end. From my researches there&#39;s two ways: frameworks like react/inferno/vue2.0 or a template engine. I&#39;m in doubt if I shoud stick with a js framework or switch to a template like <a href="https://github.com/valyala/quicktemplate">https://github.com/valyala/quicktemplate</a> . What I&#39;m really looking for is the fastest I could get, templating seems to be done on server side which might be better than serving static files, but of course wanna here other&#39;s devs experience ;). If it helps, I&#39;m looking to work with pagination and api fetching, looking to build a store website.</p> <hr/>**评论：**<br/><br/>66a4: <pre><p>I personally prefer to do rendering on client side. I never experienced any performance issues with this approach. In case of any performance issues of course you can do prefetch. My personal choice: React + REST API in Go.</p></pre>chmikes: <pre><p>With go we can do server or client rendering. The choice depends on the type of app and round trip time (rtt). The rtt is ~ the ping time delay value that is so important in games. If the RTT is high, you should favor rendering in the client. The user will have a more responsive application. Also, the more processing can be pushed on the client side, the less servers you&#39;ll need to run your service. Usually, you pay for the servers. </p> <p>If you want to support really weak clients like old smartphones, than you should keep some work on the server obviously.</p> <p>So my rule of thumb is to favor client rendering and fallback to server rendering only when required. This is why I have big hopes on go support of web assembly. </p> <p>When implementing a server I also consider the app size and transmission time. Those JS frameworks are not free. So while I favor client rendering I also keep some parts on the server. </p></pre>danhardman: <pre><p>Golang has it&#39;s own standard lib <a href="https://golang.org/pkg/html/template/" rel="nofollow">html/template</a> library which works perfectly. I&#39;ve built e-commerce sites using golang and standard HTMl templating.</p> <p>If you just want to build one project, go for all golang. Static HTML and standard web server.</p> <p>If you want the system to work across multiple platforms, build the API in go and then build SPAs/Mobile apps that tie in with it.</p></pre>robvdl: <pre><p>Agreed on using html/template, I see absolutely no need for libraries that diverge from the stdlib like quicktemplate, fasthttp, etc. It&#39;s this obsession about speed I often see in the Go community, when it isn&#39;t really needed because when it comes to the bigger picture very little time will actually be spent rendering templates or in the router.</p> <p>The html/template library does all I need and it has the added feature of safety.</p> <p>The other gripe I have with quicktemplate itself (and Mako which it models after), is that I have never liked these type of template libraries because they put too much logic/code in the template layer, it&#39;s why I prefer Jinja2 when it comes to Python instead of Mako. Saying that, even Jinja2 allows you to jam too much logic into the template layer too, but I do try to avoid it.</p></pre>bigbootyhoes9: <pre><p>Node has jade/express views or you could do server side rendering with React (e.g isomorphic javascript). Or you could do nodejs server/apis and then angular/auerlia/vue/react+redux/ember/backbone/polymer client </p> <p>Go has templates similar to jade/express views. I don&#39;t know of anything similar to server side rendering in Go (there are some packages out there but not sure id recommend it). Id personally recommend go server + api with a frontend client. any of the above frontends are good..each has its ups and downs</p></pre>