6 ms·

> With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more. Curious, does that ap

> With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more. Curious, does that apply to Angular/Ember?

Nextgrid 6y ago
Agreed. As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure. I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. In the majority of cases the structure and "batteries included" approach of Ember (and maybe Angular) would be beneficial. I see a similar problem with server-side Javascript. You can use Express for the HTTP side of things, but then you need to bolt on an ORM (from a dozen competing options), configure it, etc. There is no "batteries included" framework equivalent to Django, Rails or Laravel.
- ng12 6y ago
  I hear this a lot and it's really missing the forest for the trees. Picking a routing library (if you need one) requires 10 minutes of googling. Picking Ember/Angular will haunt you for the lifetime of your project.
  - Nextgrid 6y ago
    Picking a routing library out of 10 competitors might mean that it becomes unmaintained (in favor of some other competitor) or will have bugs integrating with your other libraries. With a batteries-included framework, as long as the framework itself is maintained I can be fairly certain that parts of it just won't stop working as long as I follow the release notes when upgrading (there might be minor changes here and there, but nowhere near the amount of work of switching to a totally different library because the first one stops being maintained).
- nicoburns 6y ago
  > I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. I think that might depend on what you're trying to do. I'm guessing as you say you are unfamiliar with the JS ecosystem, that you were trying to do something relatively simple. As a full-stack developer who does a lot of front-end dev, my experience has been that hitting against the limitations of Angular/Ember* is exceedingly common. Not "every feature I try to implement common". But "every project has 2 or 3 features that need the flexibility" common. This is enough to make avoiding that pain very appealing. I haven't had the same problems with Laravel or Django (haven't used Rails). And I think a key part of that is that Laravel/Django are still "just PHP/Python". Angular tries to put the proprietary string templating language in charge of everything. Which is painful. Also: Picking libraries is a skill you can develop. You learn to google for the N most popular libraries for a given task. Then search for blog posts comparing advantages and disadvantages. And check for recent activity / outstanding issues. It only takes a couple of hours, and you get a library which is more tailored to your use case. * I haven't actually use Ember. Only Angular.
  - andyjohnson0 6y ago
    > Picking libraries is a skill you can develop. You learn to google for the N most popular libraries for a given task. I'm not a js developer, but picking libraries based on popularity seems a dubious idea if a sufficient number of other people are doing the same.
  - Nextgrid 6y ago
    > my experience has been that hitting against the limitations of Angular/Ember* is exceedingly common In this case, it seems to be a problem with the framework if certain parts can't easily be overridden and implemented with custom code. But this is a problem with one particular framework and not with the whole idea of a "batteries-included" framework. > Angular tries to put the proprietary string templating language in charge of everything. Which is painful. Probably yes. I have not used Angular, only skimmed the Ember documentation, and what I'm talking about is mostly its MVC structure and the basics it provides like URL routing, models (which is just a REST API client in the background), templates, etc. I'm assuming most of this can be overridden with custom JS for the areas that don't map to its structure well enough. > Picking libraries is a skill you can develop. True but my point is less about the complexity of picking libraries and more that these libraries are at its core still framework-agnostic. They are designed by different people, with different goals, skills and opinions, which means there's potential for interoperability bugs if you are unlucky enough to be using the wrong combination of libraries. In comparison, with a batteries-included framework I am more or less guaranteed that all the "batteries" will play nice together and will have a consistent API. The Javascript ecosystem also moves very fast so even if you pick your libraries at the beginning you might realize 6 months down the line that some became unmaintained or no longer interoperate as well as they used to.
- whycombagator 6y ago
  > There is no "batteries included" framework equivalent to Django, Rails or Laravel. The closest to those for JavaScript is Nest[0] [0] https://docs.nestjs.com/ https://docs.nestjs.com/
  - rhlsthrm 6y ago
    We use Nest. It's great, but it doesn't actually include things like ORM. It has good recipes for TypeORM, but nothing is really included.
- harrygeez 6y ago
  Like everything else, start simple. React by itself can do everything you need it to do on the front end.
- bobthepanda 6y ago
  > local state management, API calls, forms, URL routing, etc for all of these examples, React offers a vanilla way to do this, or you could use React + ECMAScript & polyfills to do this. there are definitely bolt-on libraries that do more with those but you can be fine with minimal dependencies on other things. I feel like a lot of pain with React development is self-inflicted.
  - notJim 6y ago
    Agree with this. On a recent React side-project, I decided to try avoiding dependencies as much as practical, and building my own stuff. I've found the libraries often don't do as much as you think, and you'll spend more time customizing them than you would rolling your own. I think often I reach for a library because I don't understand how to solve a problem in react. It's better to first figure out how to solve the problem, then decide if you still want a library for it. The only libraries I used aside from React itself were react-router (scars from dealing with the history API in a past life) and material-ui (not a designer.) react-router was a breeze, and I did end up spending a lot of time figuring out how to customize material-ui, but I still think it was worth not having to write my own components. One thing that's key to this approach though is understanding the patterns your would-be dependencies use. For example, I did implement unidirectional state flow like in Redux. I just didn't use Redux. I also considered using a form library, but ended up just stealing some of its ideas. Now where I do think libraries shine is on larger teams. Once you have a larger team, having documented ways of doing things, and the possibility of hiring people that already know them outweighs a lot of the costs of using libraries.
- lucassen 6y ago
  > everything (local state management, API calls, forms, URL routing, etc) hooks, axios, html, reach-router. my point is that if you start with the assumption that browser APIs are sufficient, there is a natural progression to your project and «taste» in supporting libraries to react
  - bobthepanda 6y ago
    just curious, what does axios provide over basic browser "fetch"?
    - jasongi 6y ago
      Browser compatibility
ridicter 6y ago
My experience with react with different: you have to spend a large amount of time upfront in order to get the basic features of a single page app. You burn a lot of mental energy figuring out which forms library, router library, etc to use. When it's time to upgrade, you have no guarantees that your libraries will continue to play together nicely. And quality and standards between libraries can vary dramatically. I prefer the Angular approach. The initial learning curve is steep, but once you get over that, it becomes a rapid development framework, as all the pieces work together cohesively. The Angular CLI makes creating components, services, updating, etc a breeze, and helps maintain structure as your scale your app up. The core libraries (like routing, forms) are developed and maintained by Google, so you can expect a solid level of quality. The typescript-first approach means that your IDE can help you explore APIs, auto import, and work with third party libraries just as well. And the strong foundation provided by the core framework means that third party libraries have a better starting point upon which to supplement/extend.
- zdragnar 6y ago
  I dont know how much has changed in the two years since I last touched it, but Angular's blessed packages and ecosystem were more of a time sink than anything else- the flex layout package in particular was substantially buggier than simply using postcss with what was at the time css-next (I think it is preset-env now?) Additionally, baking in rx-js felt like a serious mistake- not only was there the roller coaster ramp up of learning angular, but helping others on the team learn rx-js on top of it while trying to be productive probably cut our output in half. It didnt help that we had a mix of junior developers and experienced .net devs all learning at the same time- half the battle was explaining which feature came from ES2015, typescript, angular or rx-js. Hindsight may be 20/20, but I am reasonably confident that we could have been significantly better off with react. Ember was never an option because they are only just now getting features react and angular developers have been taking for granted for years.
  - mattlondon 6y ago
    Yeah when I first started learning Angular I had similar thoughts "Why did they make this so hard?!?!?!" regarding RxJS. To be fair regarding Typescript & ES2015, you'd get that with React too (since in my mind you;d be insane to start something new in raw Javascript these days when Typescript has made our lives so much so much so much better). Now though I find RxJS to be a really elegant mental model for dealing with asynchronous stuff. I wish there was more Reactive/Rx* stuff around in the things I work with. Its really nice.

> With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more. Curious, does that apply to Angular/Ember?

Nextgrid 6y ago

Agreed. As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure. I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. In the majority of cases the structure and "batteries included" approach of Ember (and maybe Angular) would be beneficial. I see a similar problem with server-side Javascript. You can use Express for the HTTP side of things, but then you need to bolt on an ORM (from a dozen competing options), configure it, etc. There is no "batteries included" framework equivalent to Django, Rails or Laravel.

ng12 6y ago
I hear this a lot and it's really missing the forest for the trees. Picking a routing library (if you need one) requires 10 minutes of googling. Picking Ember/Angular will haunt you for the lifetime of your project.
- Nextgrid 6y ago
  Picking a routing library out of 10 competitors might mean that it becomes unmaintained (in favor of some other competitor) or will have bugs integrating with your other libraries. With a batteries-included framework, as long as the framework itself is maintained I can be fairly certain that parts of it just won't stop working as long as I follow the release notes when upgrading (there might be minor changes here and there, but nowhere near the amount of work of switching to a totally different library because the first one stops being maintained).
nicoburns 6y ago
> I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. I think that might depend on what you're trying to do. I'm guessing as you say you are unfamiliar with the JS ecosystem, that you were trying to do something relatively simple. As a full-stack developer who does a lot of front-end dev, my experience has been that hitting against the limitations of Angular/Ember* is exceedingly common. Not "every feature I try to implement common". But "every project has 2 or 3 features that need the flexibility" common. This is enough to make avoiding that pain very appealing. I haven't had the same problems with Laravel or Django (haven't used Rails). And I think a key part of that is that Laravel/Django are still "just PHP/Python". Angular tries to put the proprietary string templating language in charge of everything. Which is painful. Also: Picking libraries is a skill you can develop. You learn to google for the N most popular libraries for a given task. Then search for blog posts comparing advantages and disadvantages. And check for recent activity / outstanding issues. It only takes a couple of hours, and you get a library which is more tailored to your use case. * I haven't actually use Ember. Only Angular.
- andyjohnson0 6y ago
  > Picking libraries is a skill you can develop. You learn to google for the N most popular libraries for a given task. I'm not a js developer, but picking libraries based on popularity seems a dubious idea if a sufficient number of other people are doing the same.
- Nextgrid 6y ago
  > my experience has been that hitting against the limitations of Angular/Ember* is exceedingly common In this case, it seems to be a problem with the framework if certain parts can't easily be overridden and implemented with custom code. But this is a problem with one particular framework and not with the whole idea of a "batteries-included" framework. > Angular tries to put the proprietary string templating language in charge of everything. Which is painful. Probably yes. I have not used Angular, only skimmed the Ember documentation, and what I'm talking about is mostly its MVC structure and the basics it provides like URL routing, models (which is just a REST API client in the background), templates, etc. I'm assuming most of this can be overridden with custom JS for the areas that don't map to its structure well enough. > Picking libraries is a skill you can develop. True but my point is less about the complexity of picking libraries and more that these libraries are at its core still framework-agnostic. They are designed by different people, with different goals, skills and opinions, which means there's potential for interoperability bugs if you are unlucky enough to be using the wrong combination of libraries. In comparison, with a batteries-included framework I am more or less guaranteed that all the "batteries" will play nice together and will have a consistent API. The Javascript ecosystem also moves very fast so even if you pick your libraries at the beginning you might realize 6 months down the line that some became unmaintained or no longer interoperate as well as they used to.
whycombagator 6y ago
> There is no "batteries included" framework equivalent to Django, Rails or Laravel. The closest to those for JavaScript is Nest[0] [0] https://docs.nestjs.com/ https://docs.nestjs.com/
- rhlsthrm 6y ago
  We use Nest. It's great, but it doesn't actually include things like ORM. It has good recipes for TypeORM, but nothing is really included.
harrygeez 6y ago
Like everything else, start simple. React by itself can do everything you need it to do on the front end.
bobthepanda 6y ago
> local state management, API calls, forms, URL routing, etc for all of these examples, React offers a vanilla way to do this, or you could use React + ECMAScript & polyfills to do this. there are definitely bolt-on libraries that do more with those but you can be fine with minimal dependencies on other things. I feel like a lot of pain with React development is self-inflicted.
- notJim 6y ago
  Agree with this. On a recent React side-project, I decided to try avoiding dependencies as much as practical, and building my own stuff. I've found the libraries often don't do as much as you think, and you'll spend more time customizing them than you would rolling your own. I think often I reach for a library because I don't understand how to solve a problem in react. It's better to first figure out how to solve the problem, then decide if you still want a library for it. The only libraries I used aside from React itself were react-router (scars from dealing with the history API in a past life) and material-ui (not a designer.) react-router was a breeze, and I did end up spending a lot of time figuring out how to customize material-ui, but I still think it was worth not having to write my own components. One thing that's key to this approach though is understanding the patterns your would-be dependencies use. For example, I did implement unidirectional state flow like in Redux. I just didn't use Redux. I also considered using a form library, but ended up just stealing some of its ideas. Now where I do think libraries shine is on larger teams. Once you have a larger team, having documented ways of doing things, and the possibility of hiring people that already know them outweighs a lot of the costs of using libraries.
lucassen 6y ago
> everything (local state management, API calls, forms, URL routing, etc) hooks, axios, html, reach-router. my point is that if you start with the assumption that browser APIs are sufficient, there is a natural progression to your project and «taste» in supporting libraries to react
- bobthepanda 6y ago
  just curious, what does axios provide over basic browser "fetch"?
  - jasongi 6y ago
    Browser compatibility

ridicter 6y ago

My experience with react with different: you have to spend a large amount of time upfront in order to get the basic features of a single page app. You burn a lot of mental energy figuring out which forms library, router library, etc to use. When it's time to upgrade, you have no guarantees that your libraries will continue to play together nicely. And quality and standards between libraries can vary dramatically. I prefer the Angular approach. The initial learning curve is steep, but once you get over that, it becomes a rapid development framework, as all the pieces work together cohesively. The Angular CLI makes creating components, services, updating, etc a breeze, and helps maintain structure as your scale your app up. The core libraries (like routing, forms) are developed and maintained by Google, so you can expect a solid level of quality. The typescript-first approach means that your IDE can help you explore APIs, auto import, and work with third party libraries just as well. And the strong foundation provided by the core framework means that third party libraries have a better starting point upon which to supplement/extend.

zdragnar 6y ago
I dont know how much has changed in the two years since I last touched it, but Angular's blessed packages and ecosystem were more of a time sink than anything else- the flex layout package in particular was substantially buggier than simply using postcss with what was at the time css-next (I think it is preset-env now?) Additionally, baking in rx-js felt like a serious mistake- not only was there the roller coaster ramp up of learning angular, but helping others on the team learn rx-js on top of it while trying to be productive probably cut our output in half. It didnt help that we had a mix of junior developers and experienced .net devs all learning at the same time- half the battle was explaining which feature came from ES2015, typescript, angular or rx-js. Hindsight may be 20/20, but I am reasonably confident that we could have been significantly better off with react. Ember was never an option because they are only just now getting features react and angular developers have been taking for granted for years.
- mattlondon 6y ago
  Yeah when I first started learning Angular I had similar thoughts "Why did they make this so hard?!?!?!" regarding RxJS. To be fair regarding Typescript & ES2015, you'd get that with React too (since in my mind you;d be insane to start something new in raw Javascript these days when Typescript has made our lives so much so much so much better). Now though I find RxJS to be a really elegant mental model for dealing with asynchronous stuff. I wish there was more Reactive/Rx* stuff around in the things I work with. Its really nice.