<p>I've recently been tasked at my workplace with building some software in golang from scratch to replace an older, poorly-modeled program written in java.
However, I'm reaching the point where the backend is complete and approaching the part I dread - the GUI, as I've zero experience with HTML and javascript.
I've been asked to use <a href="https://docs.atlassian.com/aui/">Atlassian User Interface</a> when setting up the GUI. I've taken a look at their documentation - naturally it seems like gibberish right now since I don't know a thing about HTML or JavaScript. I do have access to the old program's source, there might be some hints there, too...</p>
<p>I do <em>not</em>, however, know where to start, so I turn to you, dear reader.
What are the Go tricks I'd like or need when approaching this? Or is there, perhaps, a way to build the UI entirely in Golang, without the use of HTML?</p>
<p><strong>EDIT</strong>: It was clarified to me that using the Atlassian User Interface is not required, merely recommended, and that if I am able to come up with something better (such as a pure golang solution), that would be good too.</p>
<hr/>**评论：**<br/><br/>fury_io: <pre><p>This is a problem that we've recently solved for <a href="https://github.com/rykov/paperboy">Paperboy</a> by exposing an API in Go and then creating a separate Javascript single page app in Ember.js. Would that work for you?</p></pre>jfarlow: <pre><p>We did the same. Exposed API with go, and wrote front end in Ember. Actually really like what we've set up.</p>
<p>We toyed a bit with using Go's own templates, and there are some interesting possibilities, but the process of reconnecting actions back to the Go API still seems pretty immature - especially when compared with Ember.</p></pre>Bobbelface: <pre><p>Sorry, I'm not familiar with Ember.js (or any .js) yet. Would that take long to learn?</p></pre>fury_io: <pre><p>For lack of a better analogy, it's like Ruby on Rails for Javascript apps. It comes with all the pieces wired together to build a JS app, and has great tools and ecosystem around it. I'd say it's easier to learn than another Javascript framework and scales nicely as your app grows.</p></pre>twisted1919: <pre><p>EmberJS is a terrible choice for someone that never worked with javascript, heck, it's difficult for people with JS experience. Something like VueJS is much simpler to learn.</p></pre>jfarlow: <pre><p>Ember.js was the first (and only?) JS I've learned after needing a front end for my Go API. I actually really like it as it's very similar in process and nature to programming in Objective-C.</p>
<p>Though getting the API hooks into proper Ember shape took a bit of massaging with various adapters and serializers, once it was set up it's a really great separation of duties with two really powerful technologies assisting each other.</p>
<p>Ember takes care of a lot of 'stupid javascript' stuff, if it does force a bit of convention on you. But (because?) I didn't know much Javascript, that was fine by me - fewer old traps for me to fall into because someone more knowledgable about javascript than I already laid out a safe path for me.</p></pre>shif: <pre><p>you should read on react or vue, compared to ember they are much easier to work with.</p></pre>fury_io: <pre><p>Let's not start a JS flame war on a Go subreddit. The main reason I would recommend Ember.js in this particular case is because it is targeted at creating single-page-apps, which makes it easy to work with APIs. OP would be able to separate his Go server code from the JS app.</p>
<blockquote>
<p>it's difficult for people with JS experience</p>
</blockquote>
<p>OP seems to be coming from Java world which is more framework oriented than someone coming from HTML/JS world where progressive enhancement is still the status quo.</p></pre>titpetric: <pre><p>Actually I find the opinion interesting. I was just about to ask you how VueJS would compare in complexity to EmberJS for a novice, if there are any differences that would come to mind. For someone that's into VueJS and did a lot of things before with js/jquery/etc, it would be also interesting to know in which areas you think that EmberJS is a better implementation (if you have an opinion). You can send me a DM if you think this discussion is fame-y (I don't think it is).</p></pre>fury_io: <pre><p>I think it's a bit unfair to judge these frameworks head-to-head because they're built for different purposes. The libraries you've mentioned and many others (jQuery, VueJS, Backbone, React, Angular) come from the progressive enhancement world, so they're easy to add on top of your existing server-rendered HTML. When it comes to single-page apps, these frameworks promote a pick-and-choose approach to wiring things together. And although it may be more flexible, I found it to be more fragile and harder to maintain in the long run.</p>
<p>EmberJS, on the other hand, originates from a history of "desktop app in a browser" frameworks (Sproutcore, Cappucino, etc) So it isn't as easy to just add it to existing HTML. But it is great at writing complex single-page apps with little configuration (more convention). And in my opinion, EmberJS has consistently been a bit ahead with the quality of their tooling (ember-cli), integration, and even performance when it comes to building single-page-apps. The other bonus is their community: the RFC and deprecation processes, as well as commitment to compatibility cannot be overlooked - stuff rarely breaks unexpectedly for me on upgrades, even with major versions.</p></pre>titpetric: <pre><p>Ah so it's the same argument as Go vs. PHP :)</p></pre>madman2233: <pre><p>I've started doing all my frontend coding in Go, and use gopherjs to compile it to a javascript file. Makes everything easier since you only need one language, and you can copy-paste all your data structures. Gopherjs has a bunch of helper libraries for things like ajax and jquery. I still use a standard framework like bootstrap, uikit, or materialize, but all the functionality is programmed in Go instead of javascript.</p></pre>arthurwhit3: <pre><p>+1 for GopherJS.<br/>
But instead of copy-pasting all your data structures, it's cleaner to keep the shared code in a sub-package.</p></pre>arthurwhit3: <pre><p>"Building a <strong>web</strong> GUI with Golang" = Building a website with a Go backend<br/>
Pro tip: common web browsers only interpret HTML, CSS and JS... Astonishing.<br/>
It's not like you have the choice.</p>
<p>But JS can be avoided if you keep your app very simple (and old-school) or if you stick with the built-in components of your UI library (Atlassian, UIkit, ZURB Foundation, Bootstrap...).</p>
<p>You can mix the frontend with your current backend (using Go <a href="https://golang.org/pkg/html/template/">html/template</a>) and serve your web pages from this same piece of software.</p>
<p>The day you'll have issues with scalability or code organization:</p>
<ol>
<li>Make your backend a JSON REST API.</li>
<li>Put the frontend on its own server.</li>
<li>Connect to your API from the frontend server.</li>
</ol>
<p>The day you'll have crazy issues with scalability or code organization:</p>
<ol>
<li>Ask your boss for a pay rise. Politely.</li>
<li>Split your backend into micro-services that communicate efficiently (with Protocol Buffers by example). AWS Lambda is a good platform for this.</li>
<li>Make your frontend an SPA (single page application, with React, Vue, Aurelia...) made of static files (served from a CDN if it's public).</li>
<li>Connect to your API directly from the browser, with AJAX and WebSockets.</li>
</ol>
<hr/>
<p>OP says he may never have written an "hello world" in JS or even an HTML page and some advise looking at Ember.js or Elm... Be serious.<br/>
If his frontend is so complex, he will need to understand browser APIs first of all, which are documented in HTML and vanilla JS.</p></pre>microo8: <pre><p>I've started to create an library, (<a href="https://github.com/microo8/golymer" rel="nofollow">https://github.com/microo8/golymer</a>) which will enable to easily create custom html elements. It has declarative data bindings. It yet isn't complete, and will run only under chrome.
Maybe in an non-distant future I'll complete it and start to build some reusable gui components (buttons, tables, lists, ...)
Then I'll be able to create the frontend entirely in go and also use the html platform directly.</p></pre>arthurwhit3: <pre><p>Is there a reason for you to not contribute to <a href="https://github.com/gopherjs/vecty" rel="nofollow">github.com/gopherjs/vecty</a> which is actually more advanced and usable?</p></pre>fmpwizard: <pre><p>What will the web UI have to do? If it just needs to display data, don't use any js library, no matter how easy they say it is, if tiu are new, it will take a while to get right. Instead use html/template </p></pre>coderjz: <pre><p>I'm still fairly novice at Go but currently I'm working on Go backends with HTML/JS front-ends. A few things:</p>
<p>1) If you're doing REST with separate HTML/JS code*, highly recommend to take a look at GRPC and GRPC Gateway. We've been very satisfied by it.
<a href="https://github.com/grpc-ecosystem/grpc-gateway" rel="nofollow">https://github.com/grpc-ecosystem/grpc-gateway</a></p>
<p>2) For front-end I'm not sure how complex your things are. I recently picked up Vue JS but if you know absolutely nothing I definitely recommend starting off with some basic pages and getting comfortable with it.</p>
<p>Also someone above said Ajax and JQuery, my understanding is that this is the current recommendation - <a href="https://github.com/mzabriskie/axios" rel="nofollow">https://github.com/mzabriskie/axios</a></p>
<p>*You can do your HTML rendering in Go. Personally, this feels a bit less comfortable to me for reasons I can't articulate well. For example, I'd feel like debugging would be more difficult as you'd have to make sure your template is working.
<a href="https://golang.org/pkg/html/template/" rel="nofollow">https://golang.org/pkg/html/template/</a></p></pre>i-dontevenseethecode: <pre><p>I can't believe some of the recommendations on here. I've been a web developer for 3 years. I know thats not very long in the industry but In that time I've worked on java struts, angular 4 and node, angularjs, dot net mvc, jquery. You absolutely should not be doing a web gui in go. Not professionally. IMO not ever. You basically have these choices, Simple HTML and jquery, angular 4, Vue JS, or react. You should stay away from Ember, and angular 1. Those are old. If you are just learning front end development, a jquery app is the easiest but the most dated. </p></pre>Killing_Spark: <pre><p>I took a short glimpse and it looks not too complicated. Id recommend to start building a simple page with html. If you got the principles of html down (its really not that much) you can then fiddle a bit with the javascript getElementById/Class etc and change properties on them. After that you should be ready to go and learn this framework. </p>
<p>What you will probably need too are ajax calls (id recommend jquery for that if you are allowed to use it) to communicate with your Servers api. Also id recommend to serialize data in json, because javascript makes it really easy to Parse it into an object. </p></pre>Bobbelface: <pre><p>Thanks for the advice.
Since the backend is already built and it can get all the data it needs already, I probably won't need ajax yet.
And yeah, because the backend has REST calls I've had the chance to mess around with golang's JSON package - the logic of marshal/unmarshal still confuses me a bit, but hey, the code works as intended when running go test, so I'll assume I'm doing it right...</p></pre>Killing_Spark: <pre><p>Well the thing is, your gui will be running in the Browser of the Client, so if your gui is supposed to make any changes to the data of your server you will most likely need ajax. </p></pre>Bobbelface: <pre><p>I see! Right now the server doesn't store any data - it simply manages and forwards requests to other servers, but I'll keep that in mind for when we add a local database (and we are planning to).</p></pre>sethammons: <pre><p>Your backend server (the one that routes requests), you need to communicate with it from your HTML + JavaScript side. This is how you can display information it gives you and how your request information from it or tell it to do what it needs to do. How do you plan on doing that? The typical answer for that is "make ajax requests from the js."</p></pre>jtdaad: <pre><p>If you are more comfortable with backend programming, you might take a look at Elm. It has a very Haskell look and feel, but compiles to javascript to run in the browser. Take a look at /elm or the docs on their website, the elm community is pretty awesome and helpful, I am on their Slack channel quite a bit also.</p></pre>daveddev: <pre><p>While I concur with you, Elm may not be a good choice if the impact of a notable learning curve cannot be absorbed. It is worth saying, though, I'm glad I took (am taking) the time.</p></pre>
