olebedev / go-starter-kit

[abandoned] Golang isomorphic react/hot reloadable/redux/css-modules/SSR starter kit
Other
2.82k stars 357 forks source link

[little poll needs your upvote] Use goja instead of go-duktape? #68

Closed olebedev closed 7 years ago

olebedev commented 7 years ago

Hey, reactive gophers!

This PR migrates the project to use on promising javascript engine, written right in Golang. So, what do you think, will it be good to have a Golang-only native implementation with less performance(≈ 2 times less) than having problems with CGO(call overhead, loss of cross-compilation, unmanaged behavior).

Regarding the issue of performance, I need to say that all existing react application are slow. They slower than simple flat server side templating even at node.js. Seems anyway we have to solve this issue in some different way(caching at server side, as an option). Switching between js engines will never totally solve it. And the last thing which should be mentioned - this project will definitely much more performant than prerender.io.

I personally think it's a good change. And I will definitely use this one for the next project.

If you what to merge it, give 👍 or 👎 if you don't want to.

rtuin commented 7 years ago

You have my vote @olebedev!

I didn't experience any issues with the duktape bindings myself, and I don't care too much about the default performance levels. What I like about this starter kit is that it's great for getting started quickly, while you're still able to tweak and/or replace certain parts of it.

Great idea!

JulesAU commented 7 years ago

To make debugging easier and reduce likelihood of incompatibilities; I switched to Node for server-side rendering. It did lead me to wonder: what's the purpose of using duktape/goja to execute the JS when Node exists and does a good job of it?

I'm still building a project using Golang for the backend (and am enjoying your starter kit for this); but using a non-Node engine to exec the JS just seems to add a lot of complexity for no obvious benefit.

olebedev commented 7 years ago

@JulesAU, an obvious benefit is to reduce a complexity of the system by reducing tech stack. It's good to have all-in-one solution for so complicated things as server-side rendering for SPAs. If your project is growing you will have to customize it, up to even refactoring some part of the system. This is quite usual. It's just a good point to start with minimum efforts.

joelnb commented 7 years ago

I support this for the reasons above - the current stack is already probably not the absolute best performance you can get but it's an excellent way for someone to get started . Reducing the overall complexity and removing the cgo parts would help make that even easier.

olebedev commented 7 years ago

If anyone wants to use duktape, use duktape branch. Note it will not be updated.

iKonrad commented 7 years ago

Sorry to dig out an old thread, but @JulesAU would you mind sharing how did you manage to get nodejs and golang communicate? Did you use express to serve static files via HTTP, or doing it via file system?