And on npm it's gaining popularity: https://www.npmjs.com/package/@angular/core
React is still the clear winner in terms of market share, but Vue.js and Angular are very popular and not going anywhere. Fortunately, there's room in the world for more than one front-end framework.
Having used Angular professionally for several years, and React for the past two, I think both have clear strengths and weaknesses, but informed debate is sadly lacking, and instead we have a lot of partisanship and uninformed opinions.
Vue has a similar track over the last year https://www.npmjs.com/package/vue
React is gaining even more quickly https://www.npmjs.com/package/react
The fixed release schedule means that, at times, the "what's new" section is a bit meagre in the major releases, but e.g., the recent release of Ivy highlights that this is more of an artificial issue than a real one.
I'm personally very happy working with Angular and have chosen to use it even when provided the option of moving to React or Vue. Each of the major frameworks have their strengths and weaknesses, but I feel that we've reached the point now where their maturity is such that you cannot really make a fatal mistake in selecting either of them. Your use case and your team makeup is much more decisive.
I get why they felt like they had to do it (the Angular 1 codebase originating in 2009), but they should have gone for a much more smooth and gradual upgrade path.
If I would create a (realtime) data intensive app, I would probably use Angular for it.
a) Over-engineered and an entirely unnecessary level of abstraction and flow control for a web app
and
b) A total spaghetti mess of event handling code all over the place and no way to tell what the flow of events is and always having to hunt down difficult to debug issues as a result.
RxJS may be neat, but it's definitely architecture astronaut territory.
(I also think async generator functions are a great tool for reactivity that are underused)
Anyway, there's a huge amount of extra language that you need to develop around RxJS...at first I didn't mind because I thought I was getting multi-language benefits: "Oh! Reactive Extensions are available in a variety of different languages! Sweet!" But the specific patterns and terms learned in one implementation tend to be vastly different than in others. Sure, you're still working with the same patterns at a high level, but don't expect any of the same methods to be present or even the same basic syntax, even if the languages are similar.
Has cycle got any real-world adoption, apart from Andre writing the Manyverse client in it?
But as I wrote in the comment before, while Cycle.js is in my eye the cleaner UI framework implementation with observables (compared to Angular) it has a very small eco-system.
Is there development though? It looks like since 2018 there have been only minor updates, and major projects like [1] are still just a dream.
On the other hand, "sponsoring the development" could be a strong word. Giving a few bucks every once in a while isn't really sponsorship [2]
With comprehensive frameworks, I always think of this as the Smalltalk problem.
In real world use, aggregate framework dev-hours typically trump superior architecture. Sadly.
That’s funny, because for the exact same reason I’ve taken a strong dislike on it.
The rest of NodeJS flows on promises and constantly have to switch between that, and having to use different APIs, and no longer be able to write simple awaitable async code...
It drove me mad. Angular without RxJS would be so much better.
As far as my experience goes, promises require some extra work too.
Developers in these environments usually do not take part in these surveys.
Angular team member here. These are our observations as well. Based on metrics we collect (opt in telemetry, website traffic, language service downloads, etc), there are over 1.7m developers using Angular.
I'd say that many of them are in the enterprise, but there are also a lot of startups that bet on Angular. This is mostly due to the integrated stack where folks need to make fewer decisions and get smooth updates across versions.
Stability is another factor. We validate every commit pushed to the Angular repo with 2600+ projects inside of Google. If any of their tests break we rollout automated migrations or rethink the implementation.
All the mainstream frameworks are great tools. I'd say if you're looking at React, Vue or Angular and think "Dunno why anyone would use that, must just be the "we've always used x here"" than I'd say rethink your approach to "it's probably a good tool for their use case".
I have never witnessed an evaluation or discussion of tools for a project. Ever. Neither open-ended nor otherwise. I’ve worked on diverse projects for various clients (since Angular 2 arrived) and Angular was either an explicit requirement by the client or a team decision. There were no arguments, ever.
The people I worked with were never particularly knowledgeable. In fact, for non-trivial use cases, I feel that Angular is actually hostile to young professionals. RxJS in particular is a topic I’ve seen people struggle with a lot.
Can you achieve success with Angular? Absolutely. I don’t feel it’s any easier than with React or even AngularJS though. (No experience with Vue.)
I am not sure about that, it is more that the full stack of technologies for current SPA is daunting for new developers.
When learning react one just go to one part at a time, first rendering, then props, now learn to use the router library. When using angular one can feel overwhelmed because all the panel of tools is presented in one repo.
Anecdotal: when Angular (1.0) first came out, it felt professional and mature; you could clearly define your components and write a complete unit test on top of that. It fits well in an enterprise environment where developers are taught to do the same with (usually) Java classes.
I've consulted for a company once where they wanted to rewrite their UI in web technology; we did a POC for React, Angular, Vue and Ember. In the end, they went with Angular because they felt the most comfortable with it.
You could be right, I can see how arguing with component instances etc. can be easier when you come from object-oriented GUI platforms.
React only gets used when FE devs overweight the full stack ones. At least on the projects I have been involved with.
This is why I liked Elm as well because it bakes in a particular structure and adds static typing.
The other advantage is if you're hiring freelancing. From personal experience, anything that was custom and less opinionated cost more billable hours. Dealing with a framework like Laravel, Django, Rails cut costs in a noticeable way and the remaining work was actual hard problems to solve.
But if it's about having the font directly in the bundle encoded in base64 to save a http request, you can do that with webpack for example. But from what I understood, base64 encoded content is often slower to load than the same content served over http 2.
I don't know if others are automatically downloading the fonts to include them in the build. It's a nice feature but you can also install many Google fonts from Npm.
I guess the "innovation" here is that they also support the download step?
Either way, fonts are bulky binaries that don't gzip well but do cache well in browsers when combined with central CDNs so this seems an anti-feature for reasons other commenters point out. Most common fonts are going to be faster to paint from the cached CDN than letting it bloat your bundle sizes.
Look at awareness vs. interest. Lots of people know about it but most of them don't want to use it.