4 ms·
Was a firm believer in Angular when it was version 2, made the switch to React before Angular version 4. Best choice I've done for productivity.
by antonkm 8y ago
Was a firm believer in Angular when it was version 2, made the switch to React before Angular version 4. Best choice I've done for productivity.
- noir_lord 8y agoSame, they handled the transition terribly, I really wanted to use angular but I stuck with knockout and then ended up going to VueJs instead.
- tarellel 8y agoI've gone to using VueJS full-time as well and it's been absolutely amazing at increasing my productivity.
- noir_lord 8y agoWhat I really like with SFC's is that with some thought you get genuinely scoped components meaning you can build your UI much like something like XAML/WPF which for the kind of interfaces I build is fantastic. Combined with QuickType, C# and TypeScript it's productive as hell.
- stupidcar 8y agoI'd offer the opposite perspective: I started a recent app in React, and I wish I'd stuck with Angular. The core of the React render model is beautiful. It's far quicker to start writing and using a new component in React than in Angular, and the functional nature of React components feels good and highly productive. At first. But the problem is, around that beautiful core, the React community has built a mass of libraries, meta-frameworks, techniques and practices that are decidedly less beautiful. After a while, I really found myself missing features from Angular, and struggling to replicate them by wiring together a hodge-podge React++ framework. Instead of being productive, I was wasting an inordinate amount of time trying to discover what the current micro-framework de-jour was for handling a particular problem in React. For example, Angular supports view encapsulation. So you can write CSS targeting a component, and the framework will ensure that the style rules you write apply only to the HTML rendered by that components, without leaking to other parts of the app. This really is a godsend for properly isolating components in a reusable way. With React, there's a myriad of libraries for doing CSS, but most seem to be abandoned, and none seem to offer as straightforward or as easy style encapsulation as what Angular provides out of the box. It was a similar story with forms. Which are a rich, reactive API in Angular, but seem to be an afterthought in React. And with dependency injection, both of singleton services and components elsewhere in the hierarchy. I expect if you go all in on Redux, you can eventually build up a reasonable facsimile of what Angular provides. But from a standing start I think Angular is a much more productive framework, just because it's actually trying to be a framework, whereas React seems to be stuck somewhere between being a UI library and a framework, leaving the community to somewhat badly fill in the gaps.
- chrisco255 8y agoReact's functional components and JSX abstraction lend to it's ability to render to any target, which is powerful in and of itself. Furthermore since they are all-in-one functions or classes, they are composible and flexible in a way that Angular components are not. The component is the core of a complex UI program. Worth the up front cost of researching the top one or two solutions for forms or CSS management, and gaining all the benefits of the massive React ecosystem, in my opinion, as well as having the flexibility to evolve more easily when things change (as they always do), than buy all in on a framework. Especially for long lived applications, flexibility and adaptiveness is paramount.
- jontro 8y agoFor view encapsulation I really recommend using https://github.com/styled-components/styled-components https://github.com/styled-components/styled-components We use this in all our react projects and we haven't had any problems since with leakage
- smuemd 8y agoCheck out this pattern http://meiosis.js.org http://meiosis.js.org Works great along w react
- PunchTornado 8y agoyour comment proves his point exactly.
- pygy_ 8y agoThe Meiosis pattern cristalizes the essential complexity of centralized state management (flux/redux), with no boiler plate, and little to no extra library code... How does that prove his point?
- 11235813213455 8y agoIt seems they don't want to have to choose a user-land library, but expect everything to be provided by the framework
- kreck 8y agoWe started with Angular.js (1) and then migrated all our projects to 2+ as soon as it left beta. At this point we also evaluated react and later took a look at vue. The main reason why we stick with Angular are the baked-in best practices and the tooling (angular-cli). Especially if you work on larger projects and have several people working on them, (opinionated) Angular simply makes your life a lot easier. With react (and vue) you have to make so many small decisions when setting up your project, that especially less experienced developers are tempted to make potentially "bad" design decisions (e.g. testing framework, bundling, routing, state management, ... you name it).
- chrisco255 8y agoAt this point in React's lifecycle, there are one or two top choices for each category you mention (ie MobX vs Redux, Jest vs Jasmine, etc) for folks worried about making "bad choices" well I would ask, what makes a choice bad? Is it that a particular state management library is a bad fit for your application? In that case, where it's possible that a library is a bad fit, then how can it be that a one-size-fits-all framework is going to not equally have potential to be a "bad" choice, except with a lot more buy in and difficulty to change down the road?
- smrtinsert 8y agoJust left an angular job. Got lots of calls about it. Told them i wanted nothing to do with it. Very happy with that decision.
- Griever 8y agoWhat were your main issues with Angular? I've been using it over the last year or so (coming from a React background) and I must say I'm quite pleased with how well it works for the team and I.