3 ms·

If even in Ember-land it's an entirely separate package, then why make the comparison to React at all..? (Ember + Ember Data) is more like (React + Apollo) then

by exogen 8y ago

If even in Ember-land it's an entirely separate package, then why make the comparison to React at all..? (Ember + Ember Data) is more like (React + Apollo) then, no? But you're just comparing it to React without anything else.

EduardoBautista 8y ago
My original comment said "React ecosystem", not just "React". Apollo is part of the ecosystem.
- exogen 8y ago
  Here's what just sending a request looks like with React + Apollo: https://codesandbox.io/s/q71px7njrw https://codesandbox.io/s/q71px7njrw Which boilerplate do you take issue with? There are a couple imports you might find ugly, I suppose. Most likely though the blog post we're talking about isn't a good impression of what "just making a request" looks like. :)
  - lhorie 8y ago
    This assumes a GraphQL backend though. A lot of React shops still use a combination of redux and REST APIs, which are admittedly a tad on the verbose side
    - exogen 8y ago
      Seeing as the article under discussion is all about GraphQL, maybe the top-level comment was off-topic? Another thing to consider though, and something I've done in the past, is that you can actually embed the GraphQL resolver runtime completely on the client and easily adapt REST endpoints to it. It's pretty neat! So you can use all the benefits of Apollo without actually having a server that speaks GraphQL. This Apollo project is one such way to do that: https://github.com/apollographql/apollo-link-rest https://github.com/apollographql/apollo-link-rest (although not the strategy I used... I don't think Apollo even existed yet at the time)
      - froglegs 8y ago
        It was slightly off topic but I can understand it seeing as the example is in React/jsx and ember gets no love :) Personally jsx makes the hair on my body stand upright but that’s just me!
        exogen 8y ago
        Likewise, I feel the same way about template DSLs (why add yet another language's control flow/scoping/etc. into the mix?). I think if JSX had been around first, many more developers would find templates off-putting, seeing as they amount to writing code that builds up other code as a string. It's just that they're the way things were done for so long... I wonder what a newer dev's take would be? Would they find UI elements as values/expressions weird, or UI elements as strings weird?
        froglegs 8y ago
        I can see that argument... the same could be said about learning jsx as a layer on top of native js.. Before spa’s it was just interpolated strings rendered on the server.. people probably thought the same thing when rendering a string of html inside their python/ruby/java program. My take is if it gets the done and the team agrees, use whatever tool works! In ember-land, single file components are in the pipeline I believe, will be interesting to see if they end up supporting jsx too.
        mnutt 8y ago
        Ember’s HTMLBars is no more “building up code as a string” than jsx is.
      - np_tedious 8y ago
        I hadn't seen a client-side approach for that translation before, but I do know if a server-side one here: https://github.com/remind101/rest-graphql https://github.com/remind101/rest-graphql The amount of stars would suggest the client approach is more popular. It's that consistent with your experience or am I not comparing apples to apples?

by exogen 8y ago

EduardoBautista 8y ago

My original comment said "React ecosystem", not just "React". Apollo is part of the ecosystem.

exogen 8y ago
Here's what just sending a request looks like with React + Apollo: https://codesandbox.io/s/q71px7njrw https://codesandbox.io/s/q71px7njrw Which boilerplate do you take issue with? There are a couple imports you might find ugly, I suppose. Most likely though the blog post we're talking about isn't a good impression of what "just making a request" looks like. :)
- lhorie 8y ago
  This assumes a GraphQL backend though. A lot of React shops still use a combination of redux and REST APIs, which are admittedly a tad on the verbose side
  - exogen 8y ago
    Seeing as the article under discussion is all about GraphQL, maybe the top-level comment was off-topic? Another thing to consider though, and something I've done in the past, is that you can actually embed the GraphQL resolver runtime completely on the client and easily adapt REST endpoints to it. It's pretty neat! So you can use all the benefits of Apollo without actually having a server that speaks GraphQL. This Apollo project is one such way to do that: https://github.com/apollographql/apollo-link-rest https://github.com/apollographql/apollo-link-rest (although not the strategy I used... I don't think Apollo even existed yet at the time)
    - froglegs 8y ago
      It was slightly off topic but I can understand it seeing as the example is in React/jsx and ember gets no love :) Personally jsx makes the hair on my body stand upright but that’s just me!
      - exogen 8y ago
        Likewise, I feel the same way about template DSLs (why add yet another language's control flow/scoping/etc. into the mix?). I think if JSX had been around first, many more developers would find templates off-putting, seeing as they amount to writing code that builds up other code as a string. It's just that they're the way things were done for so long... I wonder what a newer dev's take would be? Would they find UI elements as values/expressions weird, or UI elements as strings weird?
        froglegs 8y ago
        I can see that argument... the same could be said about learning jsx as a layer on top of native js.. Before spa’s it was just interpolated strings rendered on the server.. people probably thought the same thing when rendering a string of html inside their python/ruby/java program. My take is if it gets the done and the team agrees, use whatever tool works! In ember-land, single file components are in the pipeline I believe, will be interesting to see if they end up supporting jsx too.
        mnutt 8y ago
        Ember’s HTMLBars is no more “building up code as a string” than jsx is.
    - np_tedious 8y ago
      I hadn't seen a client-side approach for that translation before, but I do know if a server-side one here: https://github.com/remind101/rest-graphql https://github.com/remind101/rest-graphql The amount of stars would suggest the client approach is more popular. It's that consistent with your experience or am I not comparing apples to apples?