6 ms·

Kind of interesting to think about the two projects and how they diverge based on the core developers. Ember is made by folks who work on / for small and mediu

by ctvo 10y ago

Kind of interesting to think about the two projects and how they diverge based on the core developers. Ember is made by folks who work on / for small and medium companies[1]. They don't have the build infrastructure Facebook does and are able to create an anointed solution in Ember-CLI because they'll use it daily. React is stuck in a place where the environment it's developed in is unique from what any other user will see. It's difficult to solve a problem when you're not in the space. EDIT: This leads to things beyond CLIs too. React is still billed as just a view library instead of a solution for building an entire app. There's no official path from view layer -> complete app (no guidance for data flow, how to communicate with the server, server side rendering, routing on the client). I think the React team needs to take a little more responsibility for the eco-system it created. You can't call it just a view library when most use cases use it to develop entire applications. You have to provide more guidance, you can't fallback to Facebook not using it that way as the default response. In my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users trying to fill in the blanks left by the React team and producing one solution after another (and quickly abandoning ship as something iteratively better was released). 1 - Tom, Yehuda at tilde.io

danabramov 10y ago
This is a very accurate description of the problem. We’re optimistic though. I’m sure that the community will help make Create React App even better.
- ctvo 10y ago
  Sorry I edited in a WHOLE bunch more that you probably wouldn't agree with after your reply. Apologies!
  - danabramov 10y ago
    Lol. No, I still fully agree. We think React is a tool to create great UIs, and UIs definitely include concerns like data fetching, etc. So some of this might make it into React in some form in the future.
    - shaneos 10y ago
      In the meantime, you can also try out the official Flux library from Facebook (https://github.com/facebook/flux https://github.com/facebook/flux), or Redux (https://github.com/reactjs/redux https://github.com/reactjs/redux), which offer great solutions for data manipulation and storage
      - coldtea 10y ago
        I think he knows about those two options. (The guy you're responding to is the creator of Redux) :-)
        vmasto 10y ago
        And now working for Facebook, one of the most active members of the react team at that.
        vinceguidry 10y ago
        Facebook created React.
        coldtea 10y ago
        Parent did not say Facebook itself is one of the most active members of the React team. They know Facebook created React. They say that Dan, at Facebook, is one the most active members of the React team.
      - rickhanlonii 10y ago
        Who wants to tell him Dan wrote Redux?
continuational 10y ago
I like React the way it is. It does one thing and does it well.
orf 10y ago
> In my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users trying to fill in the blanks left by the React team and producing one solution after another (and quickly abandoning ship as something iteratively better was released). I agree wholeheartedly with this. And it's also why I love Ember, you get templates, routing, data access all working together with minimal configuration. I love Django and part of the reason why is that it's opinionated, and Ember is the same.
- k__ 10y ago
  I found Ember was much harder to get started with than React. More concepts, it's own CLI and build system, outdated docs. (I used it 2 years ago)
  - mcardleliam 10y ago
    2 years ago is decades in the front-end world. If we make decisions today based on the state of things years ago, we'd be screwed.
    - coldtea 10y ago
      And yet nothing much changed in the needs of webapps or in the Javascript language in the past two years. And if we CAN'T "make decisions today based on the state of things years ago", then we're really screwed.
      - mintplant 10y ago
        > And yet nothing much changed in the needs of webapps or in the Javascript language in the past two years. But Ember has likely come a long way in that time - I think this is mcardleliam's point.
        k__ 10y ago
        For me the creation of ember cli was like admiting their framework didn't work as good as they intended.
trentmwillis 10y ago
The idea that Ember is made by/for small and medium sized companies is a bit dated. Several Ember and Ember-CLI core contributors have and continue to work at larger companies like LinkedIn and Yahoo. In particular, LinkedIn has been using Ember (with Ember-CLI) for over a year now and has found a lot of benefits from its adoption. Having a build system and conventions that a community maintains lets us focus on building applications instead of tooling (though we still have our share of internal tools). We also can give back to the community for things which matter more for applications "at scale". LI, for instance, funded a good portion of the FastBoot work and has been a key driver in the Ember Engines effort recently. All that to say, Ember (and Ember-CLI) can serve the needs of the whole spectrum of company/team sizes. While it still has some issues to sort out for larger applications, to say it isn't being influenced by large companies isn't really accurate any more.
- iamleppert 10y ago
  Having worked at LinkedIn in the past, and seeing the state (stagnation) of their products both current and past, that's certainly not a ringing endorsement.
- mintplant 10y ago
  For anyone else curious about Ember Engines, I found the RFC provided a good explantion of the what and why: https://github.com/tomdale/rfcs/blob/master/active/0000-engines.md https://github.com/tomdale/rfcs/blob/master/active/0000-engi...
skybrian 10y ago
Google has similar issues: if you're working on open source software, some tools have to be written twice, for internal and external developers.
_____s 10y ago
Another great thing about ember-cli is that it has very quickly build around it a great community [1]. There are a lot of high quality, well tested addons that are easy to install and use, and it's easy to create your own as well. [1]: https://emberobserver.com/ https://emberobserver.com/
- sotojuan 10y ago
  The best part about ember-cli is that everyone in the Ember community uses it. No one builds Ember apps without it. The opposite is true of any community/third party React CLI and it's a very powerful difference.
  - insin 10y ago
    I'd say Webpack plays that role in the React community, just without a blessed and shared way to configure it.
freyr 10y ago
> I think the React team needs to take a little more responsibility for the eco-system it created. You can't call it just a view library when most use cases use it to develop entire applications. This is the reason I've embraced React. No, Facebook doesn't dictate how React fits into the rest of your app, and yes, it requires more effort up front to fit the pieces together. But judging by the popularity of React vs. kitchen-sink frameworks like Ember/React/etc., many developers seem willing to invest this effort. Another comment here mentions Django; clearly some developers prefer the batteries included approach, but others don't. Is one preference right and the other wrong? Is any developer that doesn't adhere to your preference not taking "responsibility"?
- quaunaut 10y ago
  It's a matter of encouraging health in a community. A lack of proper resources(which can be everything from documentation, tutorials, guides, libraries, to tools like Ember-CLI) can lead to mistakes in design and part of your community going off on a tangent, which leads to dead branches of development trees. For example: While React still works for a lot of people who did things in ways advocated early on, the rise of Redux and functional reactive programming has caused the community to move in a direction many library authors weren't aware of when they began. Is it anyone's fault? No, not really- but taking advantage of stewardship in a community can lead to better tools and resources that help newbies, take some of the work out of your hands, and keep quality for everyone as high as possible.
- smrtinsert 10y ago
  Absolutely agree. Innovation also is much easier when not boxed into one approach. It's like people are blaming react for the revolution it created on the client side.
mason55 10y ago
> There's no official path from view layer -> complete app (no guidance for data flow, how to communicate with the server, server side rendering, routing on the client). Every time I've decided to take an afternoon to poke at React this is where I've given up. I totally understand the model and appreciate how useful it can be but I've never been clear about how to actually hook it up to a backend that isn't just the generated demo scenario and what the requirements for my backend would be.
- scarlac 10y ago
  I think this is common. For me the front page and JSX threw me off. React was so un-opinionated that it can loose its appeal when it presents itself. Once I took an opinionated tutorial it became much clearer to me. Since then I've used React in conjunction with Django, PHP/Laravel, converted large jQuery codebases to React and created frontend-only sites. I've not yet gone full-on with a NodeJS back-end and isomophic and that's fine for now. Pass your data into a root component via props. Or use XHR requests to load data from your backend into your root component and manipulate them in your state. Let the data changes in the root component trickle down via props. Keep it simple with React loaded via a <script> tag and work from there.
  - k3liutZu 10y ago
    No, that becomes a nightmare to maintain. Use Redux and connect any component that needs data to the store and get the data needed directly.
    - tptacek 10y ago
      Not much more to say about this than that I do not agree, that I think flux-alikes are overused, and that it's just as easy to go too far the other direction, where nothing has any state even for trivial UI state concerns.
      - danabramov 10y ago
        Agreed.
xirdstl 10y ago
I suppose that's the price people will pay for needing the latest shiny (React) instead of the now old and boring Ember or AngularJs. And also thinking that the solution that works for Facebook is the one that is the best fit for a small startup, because someday they will reach Facebook's size. To clarify, I like old and boring because it generates less JavaScript fatigue.
- treehau5 10y ago
  You don't think a legacy AngularJS project is full of "fatigue"? I shudder at the thought. Angular 1 is so awful, even the creator himself, Misko said it really wasn't intended to be used in this way. I know the cool thing amongst us older folk are to say "Oh there goes them darn ole kids chasing their new toys again" but this is a case where very clearly one is much more suited for the job than the other. There's nothing wrong with a winner emerging. All of the "problems" people gripe about here about React can be avoided. I have posted this before, but I'll post it here again -- You wouldn't go to learn how to program Java by first learning how to configure maven, download dependencies, set up your project in an IDE, and then build and deploy your WAR through Jenkins into a J2EE container for "Hello World" React has all the goodies provided by the community, but React IS just a library. If you want to learn React -- copy and paste the latest CDN, use the in-browser transformer, and freaking learn react. The tutorials are great, and so is the article "Thinking in react" In any case, I haven't looked at this CLI, but if it's anything like the ember-cli I am sure it will help with the artificial gripes.
  - xirdstl 10y ago
    I don't think a legacy AngularJS project is necessarily full of any more fatigue than a React project will be in a few years time. That's not really fair, though. It will be a React + x + y + z project, because as you said, React is just a library, and it needs other pieces to fill the gaps provided by some of these other frameworks. I could be wrong, but it will take a couple years to tell. By then, React will be old news also.

by ctvo 10y ago

danabramov 10y ago

This is a very accurate description of the problem. We’re optimistic though. I’m sure that the community will help make Create React App even better.

ctvo 10y ago
Sorry I edited in a WHOLE bunch more that you probably wouldn't agree with after your reply. Apologies!
- danabramov 10y ago
  Lol. No, I still fully agree. We think React is a tool to create great UIs, and UIs definitely include concerns like data fetching, etc. So some of this might make it into React in some form in the future.
  - shaneos 10y ago
    In the meantime, you can also try out the official Flux library from Facebook (https://github.com/facebook/flux https://github.com/facebook/flux), or Redux (https://github.com/reactjs/redux https://github.com/reactjs/redux), which offer great solutions for data manipulation and storage
    - coldtea 10y ago
      I think he knows about those two options. (The guy you're responding to is the creator of Redux) :-)
      - vmasto 10y ago
        And now working for Facebook, one of the most active members of the react team at that.
        vinceguidry 10y ago
        Facebook created React.
        coldtea 10y ago
        Parent did not say Facebook itself is one of the most active members of the React team. They know Facebook created React. They say that Dan, at Facebook, is one the most active members of the React team.
    - rickhanlonii 10y ago
      Who wants to tell him Dan wrote Redux?

continuational 10y ago

I like React the way it is. It does one thing and does it well.

orf 10y ago

> In my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users trying to fill in the blanks left by the React team and producing one solution after another (and quickly abandoning ship as something iteratively better was released). I agree wholeheartedly with this. And it's also why I love Ember, you get templates, routing, data access all working together with minimal configuration. I love Django and part of the reason why is that it's opinionated, and Ember is the same.

k__ 10y ago
I found Ember was much harder to get started with than React. More concepts, it's own CLI and build system, outdated docs. (I used it 2 years ago)
- mcardleliam 10y ago
  2 years ago is decades in the front-end world. If we make decisions today based on the state of things years ago, we'd be screwed.
  - coldtea 10y ago
    And yet nothing much changed in the needs of webapps or in the Javascript language in the past two years. And if we CAN'T "make decisions today based on the state of things years ago", then we're really screwed.
    - mintplant 10y ago
      > And yet nothing much changed in the needs of webapps or in the Javascript language in the past two years. But Ember has likely come a long way in that time - I think this is mcardleliam's point.
      - k__ 10y ago
        For me the creation of ember cli was like admiting their framework didn't work as good as they intended.

trentmwillis 10y ago

The idea that Ember is made by/for small and medium sized companies is a bit dated. Several Ember and Ember-CLI core contributors have and continue to work at larger companies like LinkedIn and Yahoo. In particular, LinkedIn has been using Ember (with Ember-CLI) for over a year now and has found a lot of benefits from its adoption. Having a build system and conventions that a community maintains lets us focus on building applications instead of tooling (though we still have our share of internal tools). We also can give back to the community for things which matter more for applications "at scale". LI, for instance, funded a good portion of the FastBoot work and has been a key driver in the Ember Engines effort recently. All that to say, Ember (and Ember-CLI) can serve the needs of the whole spectrum of company/team sizes. While it still has some issues to sort out for larger applications, to say it isn't being influenced by large companies isn't really accurate any more.

iamleppert 10y ago
Having worked at LinkedIn in the past, and seeing the state (stagnation) of their products both current and past, that's certainly not a ringing endorsement.
mintplant 10y ago
For anyone else curious about Ember Engines, I found the RFC provided a good explantion of the what and why: https://github.com/tomdale/rfcs/blob/master/active/0000-engines.md https://github.com/tomdale/rfcs/blob/master/active/0000-engi...

skybrian 10y ago

Google has similar issues: if you're working on open source software, some tools have to be written twice, for internal and external developers.

_____s 10y ago

Another great thing about ember-cli is that it has very quickly build around it a great community [1]. There are a lot of high quality, well tested addons that are easy to install and use, and it's easy to create your own as well. [1]: https://emberobserver.com/ https://emberobserver.com/

sotojuan 10y ago
The best part about ember-cli is that everyone in the Ember community uses it. No one builds Ember apps without it. The opposite is true of any community/third party React CLI and it's a very powerful difference.
- insin 10y ago
  I'd say Webpack plays that role in the React community, just without a blessed and shared way to configure it.

freyr 10y ago

> I think the React team needs to take a little more responsibility for the eco-system it created. You can't call it just a view library when most use cases use it to develop entire applications. This is the reason I've embraced React. No, Facebook doesn't dictate how React fits into the rest of your app, and yes, it requires more effort up front to fit the pieces together. But judging by the popularity of React vs. kitchen-sink frameworks like Ember/React/etc., many developers seem willing to invest this effort. Another comment here mentions Django; clearly some developers prefer the batteries included approach, but others don't. Is one preference right and the other wrong? Is any developer that doesn't adhere to your preference not taking "responsibility"?

quaunaut 10y ago
It's a matter of encouraging health in a community. A lack of proper resources(which can be everything from documentation, tutorials, guides, libraries, to tools like Ember-CLI) can lead to mistakes in design and part of your community going off on a tangent, which leads to dead branches of development trees. For example: While React still works for a lot of people who did things in ways advocated early on, the rise of Redux and functional reactive programming has caused the community to move in a direction many library authors weren't aware of when they began. Is it anyone's fault? No, not really- but taking advantage of stewardship in a community can lead to better tools and resources that help newbies, take some of the work out of your hands, and keep quality for everyone as high as possible.
smrtinsert 10y ago
Absolutely agree. Innovation also is much easier when not boxed into one approach. It's like people are blaming react for the revolution it created on the client side.

mason55 10y ago

> There's no official path from view layer -> complete app (no guidance for data flow, how to communicate with the server, server side rendering, routing on the client). Every time I've decided to take an afternoon to poke at React this is where I've given up. I totally understand the model and appreciate how useful it can be but I've never been clear about how to actually hook it up to a backend that isn't just the generated demo scenario and what the requirements for my backend would be.

scarlac 10y ago
I think this is common. For me the front page and JSX threw me off. React was so un-opinionated that it can loose its appeal when it presents itself. Once I took an opinionated tutorial it became much clearer to me. Since then I've used React in conjunction with Django, PHP/Laravel, converted large jQuery codebases to React and created frontend-only sites. I've not yet gone full-on with a NodeJS back-end and isomophic and that's fine for now. Pass your data into a root component via props. Or use XHR requests to load data from your backend into your root component and manipulate them in your state. Let the data changes in the root component trickle down via props. Keep it simple with React loaded via a <script> tag and work from there.
- k3liutZu 10y ago
  No, that becomes a nightmare to maintain. Use Redux and connect any component that needs data to the store and get the data needed directly.
  - tptacek 10y ago
    Not much more to say about this than that I do not agree, that I think flux-alikes are overused, and that it's just as easy to go too far the other direction, where nothing has any state even for trivial UI state concerns.
    - danabramov 10y ago
      Agreed.

xirdstl 10y ago

I suppose that's the price people will pay for needing the latest shiny (React) instead of the now old and boring Ember or AngularJs. And also thinking that the solution that works for Facebook is the one that is the best fit for a small startup, because someday they will reach Facebook's size. To clarify, I like old and boring because it generates less JavaScript fatigue.

treehau5 10y ago
You don't think a legacy AngularJS project is full of "fatigue"? I shudder at the thought. Angular 1 is so awful, even the creator himself, Misko said it really wasn't intended to be used in this way. I know the cool thing amongst us older folk are to say "Oh there goes them darn ole kids chasing their new toys again" but this is a case where very clearly one is much more suited for the job than the other. There's nothing wrong with a winner emerging. All of the "problems" people gripe about here about React can be avoided. I have posted this before, but I'll post it here again -- You wouldn't go to learn how to program Java by first learning how to configure maven, download dependencies, set up your project in an IDE, and then build and deploy your WAR through Jenkins into a J2EE container for "Hello World" React has all the goodies provided by the community, but React IS just a library. If you want to learn React -- copy and paste the latest CDN, use the in-browser transformer, and freaking learn react. The tutorials are great, and so is the article "Thinking in react" In any case, I haven't looked at this CLI, but if it's anything like the ember-cli I am sure it will help with the artificial gripes.
- xirdstl 10y ago
  I don't think a legacy AngularJS project is necessarily full of any more fatigue than a React project will be in a few years time. That's not really fair, though. It will be a React + x + y + z project, because as you said, React is just a library, and it needs other pieces to fill the gaps provided by some of these other frameworks. I could be wrong, but it will take a couple years to tell. By then, React will be old news also.