On Wed, Apr 28, 2021 at 12:28 AM Joseph Jones <jos...@yakkertech.com> wrote:
> Hi Everyone, > > I am trying to decide what front-end to use with a Go backend. It seems > natural to use a Go frontend framework as well but I have not found a lot > of them. > > A couple of haphazard thoughts: The most important one is that of an ecosystem. The key point of front-end work is to be able to hook into other people's libraries somewhat easily, because chances are you are going to need it sooner or later. You might also want to think a bit about "hook into other people's brains" in that almost any front-end dev understands the lingua franca of the web: JavaScript / TypeScript. That said, it is alluring to treat Javascript as a compilation target, which is done by many different programming languages. The main reasons for doing this is cohesion and familiarity, but also because you can get access to libraries in the source language (with appropriate emulation layers). A go version of this is gopherjs: https://github.com/gopherjs/gopherjs . Usually what should be studied is how well the FFI is made toward Javascript, and one complication here is that Javascript is an untyped language, and to cope TypeScript has to embody a quite advanced type system. Another approach is to target webassembly, if you have browser support in your use case. The idea here is that you write most of your system in e.g. JavaScript, but you have a crucial part you want to share between your front and back end. Usually this part is some specific code which is hard to replicate on the other side, due to development cost and maintenance cost in keeping the things alike. The Go compiler can produce webassembly as output. The flip side, though, is that the web is built on DOM, CSS, HTML, and JavaScript. You need this knowledge in addition to the Go front-end you are going to use because at times the problem will occur in these layers. It isn't much different from the case where you need assembly or kernel knowledge when programming in the back-end, but you need to know what pillars/giants you are standing on. The decision should usually be guided by which people are on the development team, and what knowledge they possess. That, and how much uncertainty your project has in the first place. Going with the flow lowers the uncertainty because most problems have been seen before. But if that means you have to replicate the whole application again in the front-end, the prospect doesn't look too good. Finally, one has to think about a world in which you might have multiple front-ends for multiple ecosystems and devices. In particular this should form the design decisions for a backend-API moreso than a single given target. In particular, it is worth considering that mobile devices tend to use typed languages, which is a major difference from the web. And usually, typed languages allow for better interaction ergonomics if you design around it. -- J. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiUx3JGgiyRqx1DgQzA-MGxTHk8N2uTnvC0FVdiMtP3mWQ%40mail.gmail.com.
