8 ms·

I feel like Angular is now where jQuery was a few years ago - used to be huge but no-one is starting new projects in it unless they have to, and they keep relea

by llimos 6y ago

I feel like Angular is now where jQuery was a few years ago - used to be huge but no-one is starting new projects in it unless they have to, and they keep releasing new versions for the large existing base. The actual updates here are a bit meh tbh.

__ryan__ 6y ago
Citation needed.
- DJBunnies 6y ago
  They clearly said feel, not fact.
- llimos 6y ago
  https://2019.stateofjs.com/front-end-frameworks/ https://2019.stateofjs.com/front-end-frameworks/ Look at awareness vs. interest. Lots of people know about it but most of them don't want to use it.
k__ 6y ago
While I personally prefer React 90% of the time, I would say with its deep RxJS integration Angular has its merits. Sure, it's miles away from Cycle.js, but Angular has a much bigger eco-system. If I would create a (realtime) data intensive app, I would probably use Angular for it.
- josteink 6y ago
  > I would say with its deep RxJS integration Angular has its merits 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.
  - k__ 6y ago
    Doesn't Node.js mainly flow on callbacks? As far as my experience goes, promises require some extra work too.
  - tashoecraft 6y ago
    Strongly disagree. Rxjs is such a better async pattern than anything else in the javascript ecosystem. The front end shouldn't care what node is doing, especially since not everyone's front end uses node. What I don't like about async await is it changes the pattern you are seeing, intermingling synchronous and asynchronous code based on the correct placement of a keyword, then using try catch blocks to catch errors are just so ugly. Passing my data through a stream of pure functions that transform the data into what I need just feels pleasant to work with, but I do agree it takes awhile to be proficient in it.
  - hckrnwsthrwwy 6y ago
    Use NestJS, you can have RxJS and Angular in your backend
- hobby-coder-guy 6y ago
  > Sure, it's miles away from Cycle.js What do you mean?
- azangru 6y ago
  > Sure, it's miles away from Cycle.js Has cycle got any real-world adoption, apart from Andre writing the Manyverse client in it?
  - k__ 6y ago
    At least 24 companies are sponsoring the development, don't know how high the dark figures are. 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.
    - dmitriid 6y ago
      > At least 24 companies are sponsoring the development 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] [1] https://github.com/cyclejs/cyclejs/issues/851 https://github.com/cyclejs/cyclejs/issues/851 [2] https://staltz.com/software-below-the-poverty-line.html https://staltz.com/software-below-the-poverty-line.html
    - ethbr0 6y ago
      > very small eco-system 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.
      - WorldMaker 6y ago
        I used Cycle for a couple years, but the size of the React ecosystem made it much easier to just use React. There were prototypes of embedding React components in Cycle Apps, but more traction was made in embedding Cycle components in React apps, but by this point it rarely seems worth the effort to mix the component types together. (And with hooks eliminating whole sorts of reactivity issues with class components, I don't really miss Cycle much in React work. Though I miss Cycle a great deal when working in Angular, yikes.)
- deckard1 6y ago
  Maybe every example I've seen of RxJS is doing it wrong, but I've not seen a usage of RxJS that wasn't: 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.
- IggleSniggle 6y ago
  I'm sold on the "reactive stream" pattern, and I evangelized RxJS until I discovered cleaner libraries that accomplish much the same thing. Flyd[0] is my current library preference for JS. RxJS just has so many more abstractions than you need to do the job, and it doesn't make it very easy to incorporate whatever your own functional paradigm might be even though you would expect it to excel at this...It forces RxJS conformity, instead of being "just a function" that can itself be easily composed. (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. [0] - https://github.com/paldepind/flyd https://github.com/paldepind/flyd
jstummbillig 6y ago
"Automatic Inlining of Fonts" seems like a pretty huge deal to me (considering, of course, that the framework is stable and huge stylistic changes like react hooks are in fact not what you want out of a stable framework but mostly a display of its immaturity – even if the feature itself is great). Do any of the competitors include something similar?
- speedgoose 6y ago
  I'm not sure what they mean about font inlining, I didn't read the code. 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.
  - IggleSniggle 6y ago
    If the font is already loaded, then inlining is hurting rather than helping. Browsers will cache fonts and external libraries between sites when they are identical, so your users might even already have the font loaded: by inlining, you've forced them to load it again, even if they already had it in their local cache.
- WorldMaker 6y ago
  Inlining styles is download of a couple files and then a couple lines of webpack config. Almost all the competitors either already support it when you include the download file in your assests or just tell you to make the changes to your webpack config (or eject and do it in the case of something like Create React App). 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.
deleted 6y ago
[deleted]
pritambarhate 6y ago
Angular 2+ is a very good framework which has typescript support from ground up. We have dozens of project in it. It's very suitable for enterprise applications with hundreds of screens. Types make it a lot more maintabale. It has been quite easy to keep the applications updated to the latest version of Angular. Mostly it just takes 1-2 days of developer time to bring the application to the latest version of Angular.
- remlov 6y ago
  Agreed. I've worked in several, what would be considered, "large" projects in "current year popular framework". Angular always felt like it was more "batteries included" and maintainable with larger teams and is still my go to for new projects if given the option. Obviously YMMV on framework preferences if you're into the whole functional ts style vs classes.
  - miohtama 6y ago
    This is true. React/Vue ecosystems are more fragmented with tooling. Angular has one definitive tool chain. It makes it easier for Angular developers to jump between projects. But it also makes it faster, as Angular can optimise for speed with ahead-of-time compilation and stricter templates (also see some comments regarding this on this page).
    - phaedryx 6y ago
      I don't do much Javascript, but I need choose a front-end for a project I'm working on. It looks like Vue has an official router, an official store (Vuex), official testing tools, and an official browser plugin. I assume that everyone just uses the Vue version of things. Where is the fragmentation?
- polyterative 6y ago
  Same experience in our company. Very manageable.
fuzzy2 6y ago
From what I hear, Angular is still relatively popular in enterprise environments. Dunno why though. With my employer specifically it's basically "we've always used Angular". That's not entirely dumb of course, because of the built-up knowledge. Developers in these environments usually do not take part in these surveys.
- mgechev 6y ago
  > 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.
- Cthulhu_ 6y ago
  > Dunno why though 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.
  - fuzzy2 6y ago
    (I think you mean Angular 2, Angular 1 never existed. AngularJS is something different entirely.) You could be right, I can see how arguing with component instances etc. can be easier when you come from object-oriented GUI platforms.
- tashoecraft 6y ago
  Angular presents patterns for handling complex web applications as well as having a set update and release schedule. It doesn't take the typical javascript ecosystem approach of offloading the majority of package development to the open source community. All the major angular packages are updated every 6 months with breaking changes, insuring these packages all work together. No need to look out for a router, animations library, forms library, etc. A team member can switch teams and expect to work with the same tools. 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".
Abildtoft 6y ago
I think it is an unfortunate consequence of a new (relatively) poorly managed transition from AngularJS to Angular 2+, the latter of which should probably in hindsight have been named something other than Angular. 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.
- Cthulhu_ 6y ago
  Just the Angular 2 announcement lost them so much trust, and a lot of companies just switched to a different framework entirely because it effectively told them that the efforts they put into Angular 1 were wasted. 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.
stupidcar 6y ago
It's anecdotal, but that SVG path editor that recently made it to the top of HN was a brand new Angular project: https://github.com/Yqnn/svg-path-editor https://github.com/Yqnn/svg-path-editor And on npm it's gaining popularity: https://www.npmjs.com/package/@angular/core 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.
- Cthulhu_ 6y ago
  I've used both Angular (mainly 1.x) and React, and they both have their place. I like React for its minimalism, but Angular for its modularity and formality. The latter fits well in a Java / OOP organization.
- deleted 6y ago
  [deleted]
- kotojo 6y ago
  I'm not sure if the popularity increase is angular getting more popular, or front end development getting more popular. Vue has a similar track over the last year https://www.npmjs.com/package/vue https://www.npmjs.com/package/vue React is gaining even more quickly https://www.npmjs.com/package/react https://www.npmjs.com/package/react
mrmonkeyman 6y ago
Disagree. Angular is the only sane framework for me. Starting everything in it if I can. It's huge and still growing.
pjmlp 6y ago
In the Java and .NET world, Angular is just the go to SPA framework, eventually Vue. React only gets used when FE devs overweight the full stack ones. At least on the projects I have been involved with.
- WorldMaker 6y ago
  Funny, anecdotally as a full stack I much prefer React and it is all the front end devs telling me they "know Angular" and prefer it. In my experience, I think that Angular's templates using a .html file extension confuses a lot of front end devs into thinking they know Angular. (And in that same experience, they don't, not really.)
collyw 6y ago
I would still choose server side rendering and a bit of jQuery over a SPA app and JS frameowrk for a new project. It would take significantly less code and maintenance and would be fine for most projects out there.
- tored 6y ago
  Just wrote a small commercial app with SSR in PHP and some jQuery added on top for the more dynamic views. Used JsRender for the frontend templates. Great result.
modernlearner 6y ago
We started our project in Angular last year, and the updates are great. It feels like a proper framework a la Ruby on Rails or Django where as with React and Elm and other options it would have been more ad-hoc.
- deeg 6y ago
  I have a theory that the developers who like Angular have a background in dynamic web frameworks. We're used to having an opinionated structure. Throwing in code that goes against the opinion leads to pain but if you work with it you can create a lot of functionality quickly.
  - modernlearner 6y ago
    My background is Rails, Django and AngularJS. I've worked with everything that came before Angular/React (MooTools, Ember, Backbone) and you're right, I like the idea of an opinionated framework that provides enough tools to get up and running and to maintain for the next few years (at least). 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.
jimbob45 6y ago
If you’re going to make a comment like that, at least tell us what you think people are starting projects in please.
- xwdv 6y ago
  React.

by llimos 6y ago

__ryan__ 6y ago

Citation needed.

DJBunnies 6y ago
They clearly said feel, not fact.
llimos 6y ago
https://2019.stateofjs.com/front-end-frameworks/ https://2019.stateofjs.com/front-end-frameworks/ Look at awareness vs. interest. Lots of people know about it but most of them don't want to use it.

k__ 6y ago

While I personally prefer React 90% of the time, I would say with its deep RxJS integration Angular has its merits. Sure, it's miles away from Cycle.js, but Angular has a much bigger eco-system. If I would create a (realtime) data intensive app, I would probably use Angular for it.

josteink 6y ago
> I would say with its deep RxJS integration Angular has its merits 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.
- k__ 6y ago
  Doesn't Node.js mainly flow on callbacks? As far as my experience goes, promises require some extra work too.
- tashoecraft 6y ago
  Strongly disagree. Rxjs is such a better async pattern than anything else in the javascript ecosystem. The front end shouldn't care what node is doing, especially since not everyone's front end uses node. What I don't like about async await is it changes the pattern you are seeing, intermingling synchronous and asynchronous code based on the correct placement of a keyword, then using try catch blocks to catch errors are just so ugly. Passing my data through a stream of pure functions that transform the data into what I need just feels pleasant to work with, but I do agree it takes awhile to be proficient in it.
- hckrnwsthrwwy 6y ago
  Use NestJS, you can have RxJS and Angular in your backend
hobby-coder-guy 6y ago
> Sure, it's miles away from Cycle.js What do you mean?
azangru 6y ago
> Sure, it's miles away from Cycle.js Has cycle got any real-world adoption, apart from Andre writing the Manyverse client in it?
- k__ 6y ago
  At least 24 companies are sponsoring the development, don't know how high the dark figures are. 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.
  - dmitriid 6y ago
    > At least 24 companies are sponsoring the development 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] [1] https://github.com/cyclejs/cyclejs/issues/851 https://github.com/cyclejs/cyclejs/issues/851 [2] https://staltz.com/software-below-the-poverty-line.html https://staltz.com/software-below-the-poverty-line.html
  - ethbr0 6y ago
    > very small eco-system 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.
    - WorldMaker 6y ago
      I used Cycle for a couple years, but the size of the React ecosystem made it much easier to just use React. There were prototypes of embedding React components in Cycle Apps, but more traction was made in embedding Cycle components in React apps, but by this point it rarely seems worth the effort to mix the component types together. (And with hooks eliminating whole sorts of reactivity issues with class components, I don't really miss Cycle much in React work. Though I miss Cycle a great deal when working in Angular, yikes.)
deckard1 6y ago
Maybe every example I've seen of RxJS is doing it wrong, but I've not seen a usage of RxJS that wasn't: 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.
IggleSniggle 6y ago
I'm sold on the "reactive stream" pattern, and I evangelized RxJS until I discovered cleaner libraries that accomplish much the same thing. Flyd[0] is my current library preference for JS. RxJS just has so many more abstractions than you need to do the job, and it doesn't make it very easy to incorporate whatever your own functional paradigm might be even though you would expect it to excel at this...It forces RxJS conformity, instead of being "just a function" that can itself be easily composed. (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. [0] - https://github.com/paldepind/flyd https://github.com/paldepind/flyd

jstummbillig 6y ago

"Automatic Inlining of Fonts" seems like a pretty huge deal to me (considering, of course, that the framework is stable and huge stylistic changes like react hooks are in fact not what you want out of a stable framework but mostly a display of its immaturity – even if the feature itself is great). Do any of the competitors include something similar?

speedgoose 6y ago
I'm not sure what they mean about font inlining, I didn't read the code. 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.
- IggleSniggle 6y ago
  If the font is already loaded, then inlining is hurting rather than helping. Browsers will cache fonts and external libraries between sites when they are identical, so your users might even already have the font loaded: by inlining, you've forced them to load it again, even if they already had it in their local cache.
WorldMaker 6y ago
Inlining styles is download of a couple files and then a couple lines of webpack config. Almost all the competitors either already support it when you include the download file in your assests or just tell you to make the changes to your webpack config (or eject and do it in the case of something like Create React App). 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.

deleted 6y ago

[deleted]

pritambarhate 6y ago

Angular 2+ is a very good framework which has typescript support from ground up. We have dozens of project in it. It's very suitable for enterprise applications with hundreds of screens. Types make it a lot more maintabale. It has been quite easy to keep the applications updated to the latest version of Angular. Mostly it just takes 1-2 days of developer time to bring the application to the latest version of Angular.

remlov 6y ago
Agreed. I've worked in several, what would be considered, "large" projects in "current year popular framework". Angular always felt like it was more "batteries included" and maintainable with larger teams and is still my go to for new projects if given the option. Obviously YMMV on framework preferences if you're into the whole functional ts style vs classes.
- miohtama 6y ago
  This is true. React/Vue ecosystems are more fragmented with tooling. Angular has one definitive tool chain. It makes it easier for Angular developers to jump between projects. But it also makes it faster, as Angular can optimise for speed with ahead-of-time compilation and stricter templates (also see some comments regarding this on this page).
  - phaedryx 6y ago
    I don't do much Javascript, but I need choose a front-end for a project I'm working on. It looks like Vue has an official router, an official store (Vuex), official testing tools, and an official browser plugin. I assume that everyone just uses the Vue version of things. Where is the fragmentation?
polyterative 6y ago
Same experience in our company. Very manageable.

fuzzy2 6y ago

From what I hear, Angular is still relatively popular in enterprise environments. Dunno why though. With my employer specifically it's basically "we've always used Angular". That's not entirely dumb of course, because of the built-up knowledge. Developers in these environments usually do not take part in these surveys.

mgechev 6y ago
> 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.
Cthulhu_ 6y ago
> Dunno why though 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.
- fuzzy2 6y ago
  (I think you mean Angular 2, Angular 1 never existed. AngularJS is something different entirely.) You could be right, I can see how arguing with component instances etc. can be easier when you come from object-oriented GUI platforms.
tashoecraft 6y ago
Angular presents patterns for handling complex web applications as well as having a set update and release schedule. It doesn't take the typical javascript ecosystem approach of offloading the majority of package development to the open source community. All the major angular packages are updated every 6 months with breaking changes, insuring these packages all work together. No need to look out for a router, animations library, forms library, etc. A team member can switch teams and expect to work with the same tools. 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".

Abildtoft 6y ago

I think it is an unfortunate consequence of a new (relatively) poorly managed transition from AngularJS to Angular 2+, the latter of which should probably in hindsight have been named something other than Angular. 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.

Cthulhu_ 6y ago
Just the Angular 2 announcement lost them so much trust, and a lot of companies just switched to a different framework entirely because it effectively told them that the efforts they put into Angular 1 were wasted. 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.

stupidcar 6y ago

It's anecdotal, but that SVG path editor that recently made it to the top of HN was a brand new Angular project: https://github.com/Yqnn/svg-path-editor https://github.com/Yqnn/svg-path-editor And on npm it's gaining popularity: https://www.npmjs.com/package/@angular/core 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.

Cthulhu_ 6y ago
I've used both Angular (mainly 1.x) and React, and they both have their place. I like React for its minimalism, but Angular for its modularity and formality. The latter fits well in a Java / OOP organization.
deleted 6y ago
[deleted]
kotojo 6y ago
I'm not sure if the popularity increase is angular getting more popular, or front end development getting more popular. Vue has a similar track over the last year https://www.npmjs.com/package/vue https://www.npmjs.com/package/vue React is gaining even more quickly https://www.npmjs.com/package/react https://www.npmjs.com/package/react

mrmonkeyman 6y ago

Disagree. Angular is the only sane framework for me. Starting everything in it if I can. It's huge and still growing.

pjmlp 6y ago

In the Java and .NET world, Angular is just the go to SPA framework, eventually Vue. React only gets used when FE devs overweight the full stack ones. At least on the projects I have been involved with.

WorldMaker 6y ago
Funny, anecdotally as a full stack I much prefer React and it is all the front end devs telling me they "know Angular" and prefer it. In my experience, I think that Angular's templates using a .html file extension confuses a lot of front end devs into thinking they know Angular. (And in that same experience, they don't, not really.)

collyw 6y ago

I would still choose server side rendering and a bit of jQuery over a SPA app and JS frameowrk for a new project. It would take significantly less code and maintenance and would be fine for most projects out there.

tored 6y ago
Just wrote a small commercial app with SSR in PHP and some jQuery added on top for the more dynamic views. Used JsRender for the frontend templates. Great result.

modernlearner 6y ago

We started our project in Angular last year, and the updates are great. It feels like a proper framework a la Ruby on Rails or Django where as with React and Elm and other options it would have been more ad-hoc.

deeg 6y ago
I have a theory that the developers who like Angular have a background in dynamic web frameworks. We're used to having an opinionated structure. Throwing in code that goes against the opinion leads to pain but if you work with it you can create a lot of functionality quickly.
- modernlearner 6y ago
  My background is Rails, Django and AngularJS. I've worked with everything that came before Angular/React (MooTools, Ember, Backbone) and you're right, I like the idea of an opinionated framework that provides enough tools to get up and running and to maintain for the next few years (at least). 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.

jimbob45 6y ago

If you’re going to make a comment like that, at least tell us what you think people are starting projects in please.

xwdv 6y ago
React.