<p>Hello gophers,</p>
<p>I've been working on a side project of sorts for a while now, specifically creating an API http server written in Go that I hope to use to power a user-facing webapp.</p>
<p>The base of backend API is for all practical purposes written to consume the native net/http pkg's as close to possible with some basic 3rd party pkgs sprinkled here & there for simplicity / not reinventing the wheel (i.e. routing, middleware, CORS etc.) as to avoid committing/consuming to one of the many more prescriptive web frameworks out there. The API outputs all requests in JSON as I decided to build with an API-first approach to solidify that foundation and then leverage it on a view component of my choice, e.g. webapp, mobile etc.</p>
<p>I'm now at the point that my backend is decent enough (basic models, db interaction, user + token creation) that I want to start rendering some of the view components as the API is handling the MC pieces of the MVC model, and I've chosen to focus on a webapp over committing to a mobile app as that's just too much to handle at the moment for where I'm at with the project.</p>
<p>The issue though that I'm stuck on is how to best proceed with implementing the frontend pieces. I've looked into the Go templating language and that just feels clunky / lacking especially when my experience comes from the Django style of doing things - not the same stack, I know - but thats what I'm kind of hoping to get close to. I've also looked into ReactJS (as well as react-router + webpack) but the reality is that I'm in way over my head and iterating with ReactJS, which consumes the API, is not as intuitive for me as I tend to have a more backend frame of thinking.</p>
<p>I've considered introducing Django into the mix strictly for the View piece of the MVC model, which would also be consuming my API, but I feel like i'm going about it all wrong and potentially creating technical debt.</p>
<p>What I'm looking for in my frontend approach is the following:</p>
<ul>
<li>Reusability of code - think of a base HTML file with header / footer that I can extend for different pages (ala Django)</li>
<li>Does not require its own server to serve the HTML content as I'd really like to get to a static set of templates to then render with data (ala ReactJS w/o the steep learning curve)</li>
<li>Insight into whether I should be leveraging a tool that does server-side rendering or client-side - I've seen both sides of the discussion and though I lean towards client-side I'm worried that concepts like the lacking of SEO content because everything is rendered by the client, as well as fully committing to a 100% javascript approach scares me a bit in terms of the webapp not being rendered at all if the user disables it in their browser</li>
<li>Is fairly quick to pick up / learn</li>
<li>Can be built-upon w/o having to scrap it all-together for something later on</li>
</ul>
<p>As I read this I'm really thinking ReactJS + react-router is going to be my best bet long-term, but I just wanted to throw it out there to see what other options are at my disposal.</p>
<p>Thanks!</p>
<hr/>**评论：**<br/><br/>grounded042: <pre><p>IMHO, ReactJS is your best bet. You could use AngularJS, but then you can't do server side rendering (yet). With React, you can always implement the server side rendering down the road whereas transitioning from something like a straight server side MVC is a little bit harder. Step out and learn something new. You might feel a little bit out of your comfort zone, but once you start getting pieces working you'll feel great and will have picked up a new JS framework too. Plus, with React you can also potentially use React Native down the road for a mobile app.</p></pre>bamboogopher: <pre><p>This is great advice, thank you! React native is certainly a feature that has caught my attention.</p></pre>PaulCapestany: <pre><p>Personally I don't like how heavyweight React/Angular/etc are... I feel like I have a similar situation to you and I've liked working with <a href="http://vuejs.org" rel="nofollow">http://vuejs.org</a> the most so far.</p></pre>bamboogopher: <pre><p>Interesting, I had never heard of Vue.js. What do you find easier about Vue compared to React/Angular etc.? Does it have a similar learning curve compared to React/Angular?</p></pre>PaulCapestany: <pre><p><em>Way</em> lower learning curve IMO. </p>
<p>The Vuejs faq does a pretty good job explaining the differences and pros/cons between the other, more well-known frameworks: <a href="http://vuejs.org/guide/faq.html" rel="nofollow">http://vuejs.org/guide/faq.html</a></p></pre>grounded042: <pre><p>I'd not seen vue before, but it does look like a good alternative to React and Angular - I'll be looking into it some.</p></pre>Ainar-G: <pre><p>I've read your entire post and I still don't understand what your question is. Hell, there isn't even a single question mark! You seem to have troubles with choosing a front-end but I just can't see how this is Go-related.</p>
<p>If you add an actual <em>question</em> to your post, people could try and answer that. Otherwise, people will just click "expand", see a wall of text without a single "?", maybe push an upvote button (meaning, "I ain't reading all that but here's some to you for the effort"), and go on with their day.</p></pre>bamboogopher: <pre><p>My apologies if my lack of punctuation and improper phrasing did not make my asks very clear - I rushed to create the post, but, I was simply trying to provide context to my situation rather than just plainly ask "What frontend should I choose?" I now see how this can be taken as just a "wall of text" and how it may or may not be considered relevant in this subreddit - I will keep this in mind for future posts.</p>
<p>Though you're correct in stating that my decision for a frontend is not directly related to Go, it is a common situation that others are facing. Folks are looking to the language to facilitate the creation of more modular, concurrent, decoupled architectures, specifically, for the use of HTTP servers, and the lack of any formal direction from a frontend perspective still very much varies depending on who you ask.</p>
<p>So with that said, given the perceived nature that the native template package does not seem to be as widely adopted amongst Golang developers compared to other non-Go options (Angular, ReactJS etc.), what frontend technologies & approaches are you integrating into your stack if it is not Go templating? If I've misinterpreted the stance on Go templating being used for substantially sized webapps, would you recommend they be a viable option to choose long-term?</p></pre>Ainar-G: <pre><p>Much clearer, thanks. First of all, I personally find Go's <code>html/template</code> good enough for almost anything related to server-side rendering. It's fairly simple, stable, not an external dependency, and since it's in the std, it'll stay that way as long as Go 1 exists.</p>
<p>As for the front-end, I worked with Angular (on RoR projects though, not Go). It actually works fine, as long as you understand its logic, idioms, and set strict coding standards. The elephant in the room is Angular 2.0 that's going to basically break everything and switch to another language altogether (TypeScript), so good-bye to not scraping everything.</p>
<p>I don't have a lot of experience with React (I'm planning on playing with it on a side project). From what I saw and heard from others, it's pretty good as the "V" of "MVC", but you still need to create (and sustain) "M" and "C" part of the architecture for yourself. React hasn't yet hit 1.0 though, so can't really say anything about its stability and future either.</p>
<p>I've also played with "no-dependency" approaches to front-end, like rendering everything on the server (a so-so idea, I just needed something working and quick) or using XML -> XSLT -> XHMTL chain (which actually worked well for a small-scale app), but I don't think I would recommend these for a modern web app, so it seems that React is the way to go these days.</p></pre>jasonrichardsmith: <pre><p>Please checkout my project <a href="http://mongolar.org" rel="nofollow">http://mongolar.org</a></p>
<p>I am currently rewriting the backend to use etcd and vulcand.</p></pre>bamboogopher: <pre><p>Thanks! I'll definitely check Mongolar out</p></pre>
