This seems like an unrelated potshot at TS. It sounds like the person you're replying to didn't have a yarn.lock or package-lock.json, so 2 years later, they're pulling in different versions of every dependency. Of course things are going to break.
Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too.
Out of the box, you get: routing with lazy loading, full TypeScript support and a TypeScript-first ecosystem, a great CLI that completely abstracts Webpack and the build process, easy and mostly automatic updates with the CLI, reactivity with RxJS baked-in and supported widely in the community, a great forms library, and, of course, a component-based approach to UI development. The uniformity is a big benefit. It's easy to ramp up on a new Angular project, and there are fewer decisions to make when starting a new one. The built-in parts of the framework are all high quality and an easy bet. There's no need to evaluate different routers, form libraries, HTTP clients, get back up to speed on configuring Webpack only to forget how until next time, etc.
It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).
As a long time React developer, I second this. Especially this part:
> There's no need to evaluate different routers, form libraries
These two things have been the bane of my React development experience ever since the days of "flux". Every new React project I start I end up using a different set of libraries, and it's not just me either -- a very experienced React dev I work with just switched our React e-commerce SPA's form library out.
Coming back to Angular after a long time (I used to work with AngularJS) has been like a breath of fresh air. The project I'm using it on is clean, simple, consistent. The code is readable, every form and component works the same way.
If I was building something with less consistent / regular UX then I would still definitely use React, but Angular has really pleasantly surprised me.
This has really been the great thing about Angular. Our team has grown from 2 to 10 and our projects have greatly expanded. We have them all in a frontend/node layer monorepo where all our front end projects feel the same. Their organized in very similar ways, the 3rd party libraries are all on the same version and are used across the apps.
I routinely have to hop between all the apps and I don't have to think about which libraries someone has used for each part, if Angular has a version of something we need we just that. One of our bigger apps hasn't made the switch to ngrx, but that's about the only difference between the feel of them all.
Everyone's experience is different here, but I've grown to hate these all-encompassing frameworks -- somehow I always run into their limits. As far as I understand, Angular has its own module system, its own dependency injection, its own test framework. If you have any special requirements for any of those, you usually can't rely on the vast JavaScript ecosystem because Angular doesn't play well with many common JavaScript techniques. React also has a precompile step with JSX, but that's simple syntactic sugar, and besides that, React is really just a well-behaved library with a surprisingly small API surface. It doesn't try to do everything and it plays well with non-React libraries, at least in my limited experience. I usually find that in any context, taking such a mix-and-match approach is a lot more flexible in the long run than using a large framework.
I'm not sure I would consider uniformity "low" standards.
It's quite useful when there are multiple smallish projects, for example your typical web agency.
Also useful when you have one or two experienced programmers and a few less experienced ones: makes it easier to review the code.
That said for a highly custom application, especially one you're betting the company on, and need full control, a lower level approach can be beneficial.
Not limited to Angular vs Vue.js, the same applies to Django and Flask for example.
<li *ngFor="let item of list"> <-- this says it all, flow logic in your template is a debugging nightmare. There is no debugger for conditional statements that are declared in HTML.
Angular is easier to get up and running. Then you also have a very solid foundation that can be picked up easily by new devs starting on the project. Whereas, React seems to work only for more experienced front-end developers since you have to make more choices. If someone is just starting out it can turn into a mess pretty quick.
I disagree. If you use create-react-app you get best practices out of the box.
React is also much less abstraction away from vanilla JS. Learning Angular is learning a new language with a whole bunch of restrictions. Learning React is like learning JS++.
(This is my personal experience based on three Angular projects and ten+ React projects.)
Yea? What about routing, forms, state, styles encapsulation, code separation to modules, http clients, etc. A lot of choices for new React project, zero choices for Angular === faster startup.
You don't need to choose the library but there's still the same amount of documentation to wade through, the amount of learning is the same.
although, code separation is native in React now and if you think http clients is still a thing you're too far into the Angular ecosystem to be helped.
Forms: use HTML5 and expand on that.
State: quick read, I'd say use context, hooks and effects if you're new.
Styles: I despise style in JS, so I go with SCSS or CSS. The encapsulation problem is made up in 90% of all apps.
Http: just use fetch. If you'd like, you can write a vanilla wrapper around it.
Code separation to modules - don't get what you're going at really. Build functional components. Keep shared logic in services, a POJO wrapping functions and exporting it all.
I mean you get best practices for the small part React is focused on. Angular is a full type of ecosystem, like your Ruby on Railses, Djangoes etc. in which you can install it and then create a full website directly without any dependencies other than what you get.
Comparing Angular to React is comparing apples to oranges. It would make more sense to compare Angular to React based frameworks such as NextJS [0]. Those are "easy to get up and running" and offer "a very solid foundation that can be picked up easily by new devs starting on the project", as well.
I cannot upvote this enough. We have long decided what to do with our painful angularjs application with thousands of beginner mistakes due to people learning a framework while using it.
In the end, we were able to partially migrate to angular 4 at the time using ngUpgrade while still using parts of the application in angularjs 1.6. luckily we started looking into typescript beforehand, making it even easier.
It took us 3 months to completely migrate with only a tiny fraction of legacy bundle of code now still running on angularjs until it's being converted
Since then I have done every major upgrade without fears. I wholeheartedly recommend it for medium-large applications (we have around 50k cloc typescript now).
Angular + Typescript keeps us and our frontend saner than before.
One thing I sorely miss is the performance of my manual webpack / angularjs build, with 15seconds initial build and 1-2 seconds incrementals... It's now at least double with the angular cli, but at least fully managed.
> get back up to speed on configuring Webpack only to forget how until next time
Is this common? Thank goodness i'm not the only one! I keep telling myself next time i'm going to remember to bookmark the billion tabs I open on StackOverflow trying to figure out Webpack configuration, but nope I forget and start from scratch every time.
EDIT: Also I've coded a project in Angular 2 and Angular 4 respectively; I have nothing bad to say about Angular but I still prefer Vue for it's ease of use and friendlier syntax.
I'm pretty sure it's more common than it should be, really. Everytime I had to create a new project I'd have to copy/paste the webpack configs left and right. Sometimes I miss the gulp days - it was way more straight forward and not so much magic involved.
> Also I've coded a project in Angular 2 and Angular 4 respectively; I have nothing bad to say about Angular but I still prefer Vue
I have used Angular 1 professionaly for more than 3 years with some big projects and when Angular 2 was released I ditched the idea of using it in a newer project. I was using Angular 2 since the alpha days and saw how some things got over complicated. And then I too chose Vue and fell in love with it.
> It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).
Huh? Hooks are just a way to use component lifecycle in absence of classes (note how React is pushing towards having components as functions as opposed to Angular's components as classes/objects). The new context api is basically just a replacement/improvement of the old context api, which has been in React for ages (React Router was built upon the old context api from get go), but has always been badly documented and considered a private interface, something you were not supposed to touch. As for embracing Typescript, the React community has extensively used static typing with Flow (since this is something that the React team itself uses) for a couple of years, which is very similar to Typescript.
Having CLI generators (such as create-react-app) is definitely something that React borrowed from other communities, but I am not sure whether Ember or Angular was the main influence.
Definitely correct me if I'm wrong, but I also thought hooks were for factoring out common logic and sharing it among functional components. I see lots of "hooks" libraries floating around.
For Context, like you said, it existed before, but everyone was told not to use it. After the new API came out, people started suggesting ditching Redux for Context, and I know a lot of people did that. Using Context in that way is very similar to creating a stateful service in Angular and injecting it into your components.
I started working with angular 7 this February and I have to admit the learning curve was steep at first but after the slow start I quickly built my first project and now fully appreciate its power. I also think I am lucky to have taken a stab at it in its current stages, 4+ as I lost my patience for too much noise and too many changes. I also have many praises for Visual Studio Code. The reasons you mentioned are very valid and thats the reason Angular got adopted by enterprises. The uniformity the framework imposes on the projects makes it easy for other devs to jump in, to pick up a project done by somebody else, etc..
For all people who resent SPAs, continue using all jquery and other libs for small or existing projects but do consider a framework like angular if you want to build a stable web application (or a suite of web applications), you will appreciate it after your initial dive.
I also recommend a youtube channel with clear non ADD turorials: search for ‘kudvenkat angular’ on youtube.
Yes, I am using Angular CLI and I love it. I'd become jaded over the years with all the Visual Studio way of creating projects, lots of dialogs, popups, template generators and in my opinion dumb boring click-click way of dealing with things where the meat is hidden from the the programmer. With the new stack I feel like I am getting a whiff of fresh air. I'm still using C#/EF to create web APIs and deal with the DB layer but on the front end i'm much happier with Angular/Node/Typescript.
This is actually something that bothers me a lot about Angular. Yes, you can extract components, but the process of doing so is a lot more... heavyweight than in React.
In React, I can trivially extract any piece of UI into a stateless functional component in the same file (and later on I can move it to another file for wider reuse if needed). It's just like extracting a method in non-web programming, it's something you do without even thinking about it.
In Angular, that component needs to live in a separate file with a bunch of boilerplate and it needs to be registered in the module. This is OK for big components, but it's enough work that it's not practical to create tiny helper components frequently.
I can agree with you there if by heavyweight you're referring to it's explicit definitions.
However, have you tried a "SharedModule"? You can throw any number of tiny components into however many shared modules (one shared module for your small-medium sized application vs n-number of lazily loaded shared modules for your large+ applications.)
I myself enjoy wrapping even helper components in modules because I then know exactly what a component needs and it's scope of dependencies.
I'm one of the people who've built apps with 1.x, and hasn't ever tried subsequent releases. The transition didn't help matters, but it wasn't the reason why I not only have refused to consider it again, I generally don't even consider working for organizations who list it as a part of their stack.
I tend to find that most libraries/frameworks have a few central notions about what the challenge of developing an application in their technical domain is. As far as I was able to tell from working on two projects, Angular's was that JavaScript applications were not written enough like Java applications, or put another way, there were not enough idioms from a static manifestly typed kingdom-of-nouns class-oriented language being used in a dynamically typed first-class-functions-from-the-start prototypes-too language.
TypeScript has its points, there's things to like about it, but its emphasis does the opposite of persuade me that central philosophy has changed. And while I get that complex applications are complex, and most need some organizing principles and Angular is one (or more) of several attempts to figure this out, this one struck me as... not one I wanted to live inside of, to keep things polite.
If I'm wrong about Angular's central philosophy at this point, I'd be interested to hear how.
I've really enjoyed Angular. Typescript is a no-brainer now, and now that I'm starting to explore RxJS a bit more, it's impressive how powerful it can be once getting over the large learning curve. Being able to subscribe to an observer, and make a web request, and make sure that only the latest request is taken, and being able to do so out of the box is really, really nice.
> I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. [...] the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back.
I share this impression and feeling. Telling me that most of the stuff I learned for 1 was now useless (or worse, misleading) because 2 was doing everything differently was the first thing that soured me. The _promise_ of regular breaking changes soured me further, and the steep learning curve and high start-up cost sealed the deal.
With Vue, I can have a small proof of concept running without even a compiler in a few minutes. With Angular, I have to comprehend and set up the entire (new) project structure and sit down for hours learning concepts to be able to do anything - all that while remembering that the last time I learned their proprietary concepts, it all changed shortly after, and that the developers _promise_ that it will continue to change under me.
It _probably_ still makes sense for big projects, but damn, they're doing everything to keep people from trying.
The dealbreaker for me is no strongly typed templates. I have built big-ish apps (10-20k loc) in both React/Redux & Angular 6+ and I feel that there is still a lot of unsoundness in Angular 6 that I don't need to worry about with React & TypeScript.
I've been using Angular for a few months now and it's mostly been a good experience. We've been using Angular 7.
My biggest gripe, and this might just be my inexperience, is fighting the change detector to try and ensure reasonable performance when displaying a large number of elements. There are certainly mechanisms to do this but it does seem to take some work.
Switch to OnPush, use async pipes and immutable data structures. Add to that some of the virtualization components that ship with @angular/cdk and you're pretty golden most of the time.
You should be using OnPush everywhere, then your struggle will change to only getting changes detected in certain scenarios. Still a pain sometimes but not as bad as the Default change detection strategy.
FWIW, the Angular team is aware that this is a pain point. There were several talks at NG-Conf a few weeks ago that referenced replacing or removing zone.js-powered change detection for increased performance and/or smaller build sizes. They're trying to avoid another Angular 2 situation though, so it may take a while for a backwards compatible solution to surface as the default.
This is precisely what I don't like about Angular. That there is all this stuff. And I have to care about what it is doing under the hood (and this is complicated and not especially well documented).
In React if I have performance issues, then it's pretty easy to work out what's causing them.
You can largely ignore what Angular is doing under the hood, tbh. If you're having performance issues, the answer is often related to change detection (aka, Zone.js).
Zone.js is optional, although it is on by default. It's considered best practice to remove it when building standalone components with Angular Elements.
There's been a huge React/TypeScript community since day one, even before Angular2 was released with TypeScript. The only difference is it's optional with React.
> creating injectable shared state (or you can call it Context)
You get stuck on one project or in one startup for 2 years and Angular has moved 6.5 whole number versions
all while the rest of the job market is confused but kind of tolerating why you jump around jobs so much
if I'm using Angular, my "side project" isn't going to be using a higher version of Angular every 6 months. Its going to be using React or something to see what I'm REALLY missing.
Angular uses semantic versioning and adheres to it very strictly. Most of the time updating between versions merely involves running "ng update --all" and if that doesn't auto update everything you just see which items it errored for and update them. There have been articles showing how very large enterprises have updated their entire codebase in under a day.
If you're on one project or startup using Angular and you haven't kept up with the versioning that's a problem with the developers. There is no reason to be using a version lower then 1 back.
Features marked for deprecation will at minimum take 2 version to be removed, so 1 year after deprecation was marked. This isn't like Angular 1 -> 2 and I hope anyone who pays attention at all to front end will realize this. Complaining about angular versioning at this point would be like complaining that react bumped a patch version.
Because angular versions are like chrome versions.
1->2 was a full rewrite, now the new major versions always have some small upgrades and even smaller amount of breaking changes, it's not a big deal at all to upgrade.
You don't really have to upgrade every time a new version is out btw.
React really hasn't changed much since React.Component was introduced. Some lifecycle methods were deprecated/replaced, and hooks were added. That's honestly about it.
I started with apollo-client on a new app, but switched to using ngrx and turning off apollo-client caching (basically using apollo-client as a fancy graphql request library - I should probably just use apollo-link directly). My main problem was that it felt like it required both developers and components to have too much knowledge of the individual queries that the app was making. Instead of writing an app that happened to use graphql, I felt like I was writing a graphql app.
An example of that is updating the state after mutations that modify lists (e.g. creates or deletes). It's up to the developer to remember all other queries that could be affected by a mutation and to update them manually after the mutation completes (more info: https://github.com/apollographql/apollo-client/issues/3505 and https://www.apollographql.com/docs/angular/features/cache-up...). If you add a new component that performs
a query that could be affected by a previous mutation, you have to remember to also go back to that mutation and update your query from it. With ngrx (or redux), the consistency is baked in, and part of the beauty of it is that if you update the state, anyone who happens to be reading that state will get updated automatically.
I can see where updating the cache in all the right places for complex architectures could get hairy. For my own personal project, I'm using GraphQL Subscriptions to listen for mutations and piping those events directly to the client, which then updates the cache accordingly. I get that's not a solution for everyone as it would largely depend on your backend architecture having support for subscriptions.
I actually think "more PRs" usually does mean "better project" in the sense that smaller PRs are easier to review and reason about than larger ones. To me, though, I think the incentive here goes the other way - I'd want to put everything in one big PR so it looks like my client is getting a lot of work for their money. Either way, it's hard to imaging tying payments to PRs not having some impact on the coding process, which seems like a negative thing to me.
I don't know why you're getting downvoted. The single member S-Corp is a very common setup for individual freelancers/consultants precisely for this reason. FICA taxes aren't paid on distributions.
To do this, the single member has to pay themselves a "reasonable salary", but there aren't strict guidelines on this. It's a gray area, and some people push it (and lose), but it's a very common setup.
I've only used TS on the frontend, but I had the same opinion as you until I dug into a couple of TS projects. I don't know if I've ever caused a JS production bug that was a type error at its core, but I've had plenty of bugs like that in development. TS lets me cut out those little dev cycles where I'll write some code, rebuild the app, then see an obvious error in the JS console when I run the app. That adds up to a lot of wasted time over a week of coding. Smart autocomplete and smart variable renaming is also really nice, and I have way more confidence refactoring a TS project than a JS one. I think using TS does result in fewer production bugs, but the big win for me has been having fewer development bugs.
I was wondering the same thing. I was surprised that it looked like he launched Android and iOS versions at the same time, which makes me think it's probably a cross platform framework. I'd definitely love to hear more about the dev stack.
