duankuang7928
2014-08-23 23:59
浏览 186
已采纳

如何集成Golang后端和Javascript(three.js)前端?

I would like to write a 3D application using Golang, my favorite programming language. However, I would prefer not to use native OpenGL directly as the graphical frontend as this would entail a larger learning curve than I'm willing to tolerate. Additionally, I don't really want to use a Golang game engine like go:ngine.

After doing some research I found out about the amazing WebGL Javascript library three.js and I was so intrigued that I completed an introductory Javascript course in a few hours. I'm not really a web developer at all, so I'm wondering how practical it would be for me to write my application primarily in Go but with a three.js frontend.

Some specific questions:

  • Is it worthwhile / practical to use Javascript/three.js as a frontend to a Golang server like this?
  • If it is worthwhile, where can I look to learn how to integrate the two cleanly?
  • If it isn't really worthwhile, which alternatives do I have?

Thanks, any response appreciated.

Edit:

Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets?

Yes, this is what I'm thinking now. I'm intending my (Golang) program to generate streams of vertices and triangles based on a few parameters from the user. Each "structure" is generated all at once after the users supply their parameters (which I see as slider bars + input boxes on a Javascript frontend).

Here's an example of something the Go program might generate, plotted in GNUPlot: pic
(source: alexozer.com)

If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.

I'd be fine with doing that, except for these reasons:

  • The core generating process fundamentally depends on Goroutines and channels
  • I know close to nothing about web development, including frontend and backend

So I suppose I'm asking about the implementation details of one of these three possibilities:

Writing most of the program, including the generator, in JS, and a minimal backend in Go Writing most of the program in Go and using JS just as a graphical frontend Something else?
  • 写回答
  • 好问题 提建议
  • 关注问题
  • 收藏
  • 邀请回答

2条回答 默认 最新

  • doufud21086 2014-08-24 13:58
    已采纳

    I recommend leaving out the whole Websocket aspect because it's only a possible optimization (and maybe not even that).

    If you need to depend on Go's concurrency model then go for it, write your component in Go, then a Webserver in Go that takes parameters coming from an HTML request, uses them to compute the result and sends back the data in a JSON format.

    On the frontend you will then only focus on sending this request when the user changed a parameter and for displaying of the JSON data you can use ThreeJS right away.

    You'll still have to learn a bit of web development and Javascript though. But hey, they say the web is the future ;-)

    I think it's the way to go for your case because your application operates in a quite strict request-result way.

    已采纳该答案
    评论
    解决 无用
    打赏 举报
  • doukongyong44772 2014-08-24 08:42

    The answer to your question depends a lot on where exactly you plan to draw the line between your Go component and the Javascript component. From the way you describe the problem I get the feeling that you want to write most of your application in Go and use JS only as a display layer? I wouldn't recommend doing that.

    To rephrase my question: Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets? If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.

    I might be able to give a more specific answer if I know what exactly you plan to do.

    评论
    解决 无用
    打赏 举报

相关推荐 更多相似问题