<p>Hey guys, what do you think of this snippet?</p>
<p><a href="https://play.golang.org/p/pdvAao9B1j">https://play.golang.org/p/pdvAao9B1j</a></p>
<p>I usually do something like this <a href="https://github.com/golang/example/tree/master/template">https://github.com/golang/example/tree/master/template</a></p>
<p>but I often find myself having to wrap my "body" model objects in a "template" object to have information for the master template,</p>
<p>for example I like to have an array of links in my header rather then hard coding them in the template, and I dont like having that burden in my "body" template</p>
<p>Not sure if I am making any sense, anyways, apart from not caching the templates what do you think of this strategy?</p>
<hr/>**评论：**<br/><br/>tmornini: <pre><p>I'd recommend using Go for an API, and leaving CSS/HTML/JS concerns to static file servers and web browsers. :-)</p></pre>twek: <pre><p>Im a big fan of web 1.0 form post back and as little js as possible when I can help it ha. Saves you from having to-do things like validation twice in two diff languages. </p></pre>twek: <pre><p>Plus isnt less dependencies the most idiomatic golang thing you can do :P</p></pre>tmornini: <pre><p>Only do validation in the API then.</p>
<p>Problem solved?</p></pre>earthboundkid: <pre><p>This is not idiomatic. If you need an array of menu links, just make an array, pass it into the template as a context, then loop through it. If you need a base template, make blocks and extend them in separate files. </p></pre>twek: <pre><p>Thats the point I was trying to make, you can (using this strategy) pass an object to the header and the "body" template is only concerned with the "body" model</p></pre>nesigma: <pre><p>When I work on personal, small-ish, Go web projects, where I have to make all the choices, I am constantly torn between using server-side Go templates or use client-side templates with a JS framework (Angular, React, Ember etc).</p>
<p>I think there's no clear winner. As with everything in programming each approach has it's trade-offs.</p>
<p>I've found that on truly small projects I enjoy the "simplicity" of Go server-side templates. Even better, now with the new block element we can do pseudo template inheritance in a less hacky way.</p>
<p>However as soon as I need to do more elaborate things and my Go template number increases, I find that it gets harder and harder to maintain them. That's when I usually start wondering if life would be better if I had used a client-side JS framework from the very start and just keep Go for the API.</p>
<p>And that's just thinking my personal "pain" as a developer, which usually means choices that favor maintainability. But there's a tons of other things one has to consider before deciding between server-side and client-side techniques. For example if you are developing a production-level web app with a huge portion of it's visitors being mobile from countries with poor net, then client-side might not be the best choice.</p></pre>twek: <pre><p>This is the best post I have read in a long time! It highlights internal struggles that have every-time I make all the decisions. I too love the simplicity of server-side templates, I love loading a model from the DB, overlaying properties with form post values and providing that to the template as the model, so I have have buttons that can post back to the serverside and manipulate the model, and only on an postback where action=save do I persist back to the DB... If that made any sense... </p>
<p>My main stigma with the JS frameworks is of all the ones I've used I like AngularJS the best, and It irks me that Angular2 (which has alot of features and ideas I really like) Is pushing TypeScript or some other trans-piled language so hard. </p>
<p>I hate the idea of compiling from one interpreted language to another,</p>
<p>And I really dislike the idea of running any node software on my development machine...</p></pre>
