5 ms·

Yeah for me JS is the new Java :-). How is react experience couple with Go for you ?

oelmekki 9y ago
> How is react experience couple with Go for you ? It just makes sense. Which is funny, because I got in both of them in a separate way. I didn't use angular because I didn't want to replace rails router with angular one. React allowed me to let it take control of just a part of the page, which was cool. My react components got bigger and bigger from there. I first started go because I wanted to parallelize huge background jobs. Then I started writing dev tools with it. Then small APIs. At one point, I realized that my main objection about SPAs (I say "webclients", nowadays), which was that they could not be properly indexed by search engines, was irrelevant : all apps I wrote where behind auth, and landing pages didn't need a framework, static pages were perfectly good enough. So I started using react-router, and it made a lot of sense to use go : adding a few endpoints was small a task enough, and then I could write background jobs by just prefixing method calls with `go`, not needing complex process management (I still use queues, because I don't want to discard a job when I deploy and restart app). The biggest challenge with go has been to "think simple", which is quite a shock when you thought it was already what you were doing with ruby. Initially, I used custom types a lot, and embedded types, and interfaces. And then I realized I was doing OOP all over again - and as with OOP, I didn't know where the methods I called were coming from (since then, I adopted a more FP-like style). The biggest challenge with react has clearly been flux and redux. I started with big root components containing all business logic and passing callbacks around, which became a problem when frontend apps started to get big. So I tried flux and redux, but... They just introduce a lot of concepts and rigid structure that I felt were too much. So I just wrote my own flux lib, trying to keep it as conceptually simple as possible. I still write redux apps from time to time, because it's good for big teams and I have to be fluent with it to work with them. But this was worth it. Today, I feel like rails is becoming what we initially were boo-ing java for : a lot of overcomplicated architectures that solve no real problems. It's not even rails fault, it's rails users fault. I know when I work on a rails project with other people that it will be overcomplicated (so, the controller is calling a service object which calls five other ones which call decorators calling models and then passing them to adapters which call serializers...). Rails itself tends to go that path too, since it's what their users are asking for (actioncable? No way. And I'm a big fan of websockets, so I'm sad to say that). With go, I get that feeling we had with early ruby and early rails : just get the job done. Of course, I don't expect that to last :)

> How is react experience couple with Go for you ? It just makes sense. Which is funny, because I got in both of them in a separate way. I didn't use angular because I didn't want to replace rails router with angular one. React allowed me to let it take control of just a part of the page, which was cool. My react components got bigger and bigger from there. I first started go because I wanted to parallelize huge background jobs. Then I started writing dev tools with it. Then small APIs. At one point, I realized that my main objection about SPAs (I say "webclients", nowadays), which was that they could not be properly indexed by search engines, was irrelevant : all apps I wrote where behind auth, and landing pages didn't need a framework, static pages were perfectly good enough. So I started using react-router, and it made a lot of sense to use go : adding a few endpoints was small a task enough, and then I could write background jobs by just prefixing method calls with `go`, not needing complex process management (I still use queues, because I don't want to discard a job when I deploy and restart app). The biggest challenge with go has been to "think simple", which is quite a shock when you thought it was already what you were doing with ruby. Initially, I used custom types a lot, and embedded types, and interfaces. And then I realized I was doing OOP all over again - and as with OOP, I didn't know where the methods I called were coming from (since then, I adopted a more FP-like style). The biggest challenge with react has clearly been flux and redux. I started with big root components containing all business logic and passing callbacks around, which became a problem when frontend apps started to get big. So I tried flux and redux, but... They just introduce a lot of concepts and rigid structure that I felt were too much. So I just wrote my own flux lib, trying to keep it as conceptually simple as possible. I still write redux apps from time to time, because it's good for big teams and I have to be fluent with it to work with them. But this was worth it. Today, I feel like rails is becoming what we initially were boo-ing java for : a lot of overcomplicated architectures that solve no real problems. It's not even rails fault, it's rails users fault. I know when I work on a rails project with other people that it will be overcomplicated (so, the controller is calling a service object which calls five other ones which call decorators calling models and then passing them to adapters which call serializers...). Rails itself tends to go that path too, since it's what their users are asking for (actioncable? No way. And I'm a big fan of websockets, so I'm sad to say that). With go, I get that feeling we had with early ruby and early rails : just get the job done. Of course, I don't expect that to last :)