Literally just finished a huge re-write of an angular 4 app to latest Angualr 7 today, to revise the UI and improve everything. As I was about to merge it in I see this... time to upgrade!
Job security
Angular v8.0
91–100 of 210 posts
Re: Angular v8.0
#92While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.
I tend to agree. But in defense of the SPA, my experience is that over time, most screens accrete complexity. You start out with a simple content screen. Then the client wants comments. Then they want richer comments. Then they want live comments. Etc. Over time, most of my web applications tend to require richer and richer interactivity on each screen. As a result, it's nice to have started out with a client-side fr…
Your last paragraph summarizes why I default to a client-side framework if there's going to be much of any JS interactivity at all on a screen.
Even something that seems simple like a search form can be surprisingly interactive.
Re: Angular v8.0
#93Angular 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 la…
> 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.
Re: Angular v8.0
#94Earlier quoted context omitted.
It feels familiar to Java developers, due to Typescript which is also statically typed (but much better IMHO) and due to the use of decorators and classes, which are an awesome way to describe a component. Being familiar to a large base of existing developers is a huge feature.
React has also been using classes for a long time (although the trend is to move away from them for performance and simplicity reasons). There is also a huge upward trend of people using TypeScript with React. Personally, after using TypeScript & Angular at work, I've preferred switching to TypeScript when using React in personal projects. My main gripe with Angular (vs. React) has been the lack of first class suppor…
> React has also been using classes for a long time
And this
> (although the trend is to move away from them for performance and simplicity reasons)
Make me very frustrated because things like react became very popular for their simplicity. I read the reasoning the react team gave for hooks and I am not sure it justifies having such vastly different way of building components.
Re: Angular v8.0
#95This release is awesome, here is a summary from the Angular team blog - https://blog.angular.io/version-8-of-angular-smaller-bundles... The main feature among many is differential loading, that will load different versions of the application depending on the capabilities of the browser. This will avoid installing polyfills without the need for them and reduce the bundle size. There are reports of 40kb reduction in bu…
> There are reports of 40kb reduction in bundle size, which is a lot.
It would be for libraries like react or vue that are already small. Angular is still big enough that even after being 40kb slimmer it's still fairly huge (I think the typical build is like ~550+kb).
Re: Angular v8.0
#96While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.
I'm not a fan of Angular, but how many times are we going to have this conversation. At this point, this is a completely off-topic comment that has no place in this thread. I'm getting javascript fatigue fatigue.
> With some exceptions, there is really no benefit
This is just a contradictory sentence of hyperbole. Who cares if there are plenty of use-cases to not write a SPA. There are also plenty of use-cases for it, and many benefits.
Angular is a popular library and therefore this is newsworthy and we should respect it as such instead of devolving into a played-out asymptotic argument.
Re: Angular v8.0
#97Angular 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 la…
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 S…
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.
Re: Angular v8.0
#98While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.
I'm kind of with you.
I think SPA's can be suitable (sometimes) for internal line-of-business applications, where you have a degree of control over the environment the end user will be using your application on (ie the device/browser (+version)/etc) and bandwidth isn't a big issue.
In this sort of environment, Angular can work pretty well.
For public facing applications, where you can't say with confidence that your end user will be on a modern computer, using a modern browser with a good internet connection, etc, you are better using a server-side rendering framework and progressively enhancing using something like Vue.js.
That's my 2 cents anyways.
Re: Angular v8.0
#99Angular 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 la…
> 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.
Re: Angular v8.0
#100While the effort by the Angular team deserves praise, I think for the vast majority of use cases it is a mistake to do it all client side. With some exceptions, there is really no benefit in making a SPA but there are many drawbacks. I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.
Angular has server side rendering capabilities, called universal angular app, which allows sending HTML pre-rendered to the client similar to Next.js or Nuxt.js.