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 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.
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.
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.
Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular.
I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way applications are structured. I don't get the militant need for terseness that's seen in approaches like React Hooks. I also don't need the choice between multiple backwards-incompatible (or competing) routers, nor do I have a need for functionally pure reducers.
So, it may not be sexy, but It Works and that's good enough for me :)
I've been burnt by the non-Euclidian enormity of ExtJS, so I understand the desire for something simpler. On the other hand, when you leave the world of progressive enhancement and widgets (ie. jQuery), you find yourself needing a lot of common infrastructure and picking and matching that can be quite tedious (never mind dependency hell), which is something that react always had issues with -- and that seems to extend fractally, where it's not just MobX vs. React but then what framework/project setup you have on top of each of these choices. And now hooks.
Still, angular always struck me as going slightly too far into Java-land -- my Struts/J2EE/DI battle scars are larger than even my ExtJS mutilations.
And in between you've got VueJS/Vuex, which seems to move a bit too close to react at times, and EmberJs, which seems to move too slowly and/or without many people watching it.
I really want to go back to late-90s desktop UI development sometimes…
> I really want to go back to late-90s desktop UI development sometimes…
While it's not a JS framework, can I interest you in an explicitly VB/Delphi-inspired app development tool for the web?
It's got drag'n'drop design, you code entirely in Python (including the front end - it transpiles to JS), and it even has a built-in database: https://anvil.works/
But Vue got the batteries included? You have a router included and you can just keep your store as an object or use Vuex for larger applications (if you feel the need for even more structure). All this is according to the official docs, thus included and best practice?
When a typical application spends multiple megabytes just for the webfonts and logo JPGs on the front page, I don't really care whether my application bundle is 200k or 500k, though. I care more about productivity.
Now, this clearly needs SOME boundaries, but let's not start a whole "Electron" thread again :)
I think instead of meaning specific components (http and routing come to mind) that more often people mean by "batteries included" that Angular has an opinionated way to do most everything, and their docs/guides include examples. In my experience, Vue and React allow a higher degree of freedom in choosing how you would like to approach various things, and there are more choices for some core behaviors for them as well
Ah...Kotlin on the backend? Can you share more details about your stack/experience? I've been keeping an eye out for it to crop up in production backend stacks, so I'm very interested in learning how well it works for you...
I dunno about original poster but in Kotlin I use Javalin.io for HTTP web services and JDBI for SQL. Jedis for Redis access.
These are pretty typical Java libraries, but lightweight. Nothing particularly Kotlin about them but that's why I like Kotlin because you can leverage the entire Java ecosystem easily.
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 bundle size, which is a lot.
More than that, this release does a lot of preparation work for Ivy in version 9, which will bring a completely new rendering layer.
Also, there is a lot of preparatory work for the introduction of Bazel in the build pipeline, which will bring us fully incremental builds (recompiling only the part of the code that changed and nothing more).
> 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).
Yes, it was possible with Angular also before, just like with other frameworks, but now this is built-in the Angular CLI build pipeline.
This means that this is now mostly transparent to developers, and taken care for us by the build pipeline without having, for example, to configure webpack and Typescript manually ourselves.
In my opinion Angular's story is a story of how people invent problems and then valiantly tackle them.
- We want to re-write the whole thing from scratch. In TypeScript.
- And let's use Google's Closure Compiler for JavaScript. Even though it doesn't support TypeScript, modules, or anything, really from non-Google Javascript world (at the time)
- Oh. Then... Let's create a TypeScript to Closure Translator even though TypeScript doesn't let you extend the compiler and TypeScript and Closure are in general not entirely compatible
- Oh, and we use a weird combination of annotations and templates to work, so... we need to compile our templates into TypeScript (which we need to translate to Closure-compatible JavaScript which will then be compiled further down)
- Only the whole process is abysmally slow. Let's implement incremental compilation.
- It's probably still slow, complicated, and error-prone. We know! Let's use Google's Bazel! You know, the tool to build huge codebases in parallel on clusters. Yeah, why not use that to build JS code?
- Only bazel has no support for either Closure, or Javascript, or TypeScript, so we have to build tools and integrations to work with bazel!
> What's the point you are trying to achieve with that negativity?
Not trying to achieve anything. It’s my own personal opinion on how I view Angular’s development. The devs dig deeper and deeper holes to bravely climb out of them.
> Writing non existing tooling around some tools is almost positive
Since there’s no cost-benefit analysis, “almost positive” is entirely speculation.
> I doubt you are paying a cent to those developers to justify your complaints about it.
“Only paying customers are allowed to voice criticism. Please purchase a criticism package or a yearly subscription today. Volume discounts are available, contact your nearest sales representative”
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 framework, rather than hitting some threshold where you suddenly need to switch things over.
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.
Small, internal business apps have been a good use case for me. I'm working with few dev resources (me, myself & I), so the "batteries included" approach of Angular is nice, and knowing it's always served over a fast corporate network alleviates the filesize concerns somewhat. Plus, we're in a situation right now where some of our clients are being sort of amorphous on what server platform they'd like to migrate to and when, so the browser is a more stable target (ironically).
It's an unusual situation perhaps, but having done similar apps with other frameworks and paradigms over the past ~10 years, Angular 2+ just feels like a good tool for the job.
> Plus, we're in a situation right now where some of our clients are being sort of amorphous on what server platform they'd like to migrate to and when, so the browser is a more stable target (ironically).
Right, but you could still do server side rendering by consuming a third party API instead of a DB directly.
Maybe bloating is not an issue in some use cases, but client side rendering can have a major impact on the CPU.
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.
SPAs aren't classic websites, they are web applications and should only be used when you need to create a web application. If a SPA is created for every usecase a regular website would do is a bad management decision but nothing wrong with SPAs per see. And yes, in this particular case is a waste of resources.
I've been building Angular apps for 3 years now, and all projects I've built have had a "relatively light" frontend, meaning little to no business logic there.
Angular as a framework doesn't prevent you from doing anything on the backend. It's all about the re-usable components imo.
It's all about the use case. If you're on an ecommerce website and click between category and PDP pages 5-10 times browsing, a SPA is going to make that transaction an order of magnitude faster. Since you're only loading the smallest possible payload (JSON) that contains only the things that have changed, it is optimized in a way that is never going to be achievable with server-side rendering.
Yes it's all about the use case, but I generally don't buy that argument.
First, because the largest ecommerce websites are not SPAs and are generating a shit ton of revenue. Not only Amazon and Ebay but also stuff like Magento and Shopify.
Second, while it can be argued that after a number of clicks the total kbs will be lower by using JSON and rendering on the client, the vast majority of users really care about the initial load. Much like monthly payments, it's generally better to have a consistent 500ms lag than a 3000ms lag on the initial load and then 200ms on every click. Of course I made these numbers to explain my point.
This does not apply to all use cases obviously. In some cases such as an application like Gmail an SPA is completely justified and my arguments do not hold, but in the case of e-commerce I think there are no valid arguments for an SPA.
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.
I was recently at a Microsoft heavy tech conference and spoke to at least 50 .Net developers. Anyone who also did front end did so in Angular. I was surprised at how popular it is!
I work in the Danish public sector and we currently have 300 systems from various contractors. Almost all of them are moving toward a C#/JAVA api based backend and an Angular front. Only one of those systems uses Vue. None of them use React.
Outside the public sector React is a bit more popular, but it’s still mainly used outside of enterprise and Vue rarely sees any use.
The job-market doesn’t seem to follow the tech hype cycles much, at least not when you live in a country like mine.
I can confirm this for the Dutch public sector as well. I'm saying this as a longtime React contractor. There's some React contracts, but very few and no Vue that I know of.
We're not doing .NET, however i suppose besides the fact that it uses TypeScript it is popular with MS developers, because it gives you a structure that allow to develop enterprise applications in larger teams.
If you know your application will have to be enterprise grade, will be large, will be developed by enterprise devs and has to be supported for years to come, Angular is still the definitive choice (IMHO). Mainly because it gives your team a clear structure to operate in combined with known concepts.
This fact about Angular doesn't surprise me. It uses TypeScript which is a Microsoft joint, and the architecture feels rather similar to the MS standard MVVM. Two way data binding in the UI, a "code-behind" in the component. And TypeScript lends a sort-of C# flavor to the framework. It takes some "enterprise" and puts it in the front-end, which can help make the transition from ASP.NET MVC or whatever to Angular a bit easier (especially as compared to something like React).
If you're already doing .NET stuff, and you need enterprise-grade front ends, Angular seems like the natural choice still. One thing about Microsoft shops (of which my employer is one) is they tend to use Microsoft for everything, and despite Angular not actually being Microsoft, TypeScript makes it close enough. I'll be curious to see if the eventual production-ready release of client-side Blazor changes the dynamic at all.
In my experience (as a conference speaker) the people who recommend .NET and sell .NET consulting are often the same people who recommend Angular and do Angular consulting.
Both have a relatively high entry barrier compared to their alternatives (though lower than a few years ago).
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!
Readit News
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).
> 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.
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.
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.
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.
> 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.
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.
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.
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.
The thing we love about Angular is compartmentalizing everything.
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 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’m working on two huge projects using AngularJS, but would just as soon do the next with Vue. Hopefully Typescript doesn’t infect that project badly.
Google as an organization seems to have decided that C++ / Java is the one true paradigm for all work.
Could have called it "Rectangular". Opportunity, missed.
Yeah, just like that, all over again.
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.
That's a great thing about Vue, too. vue-router and vuex are well-designed and well-supported / integrated. Makes a huge difference.
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.
I built my business' web application (and android app) using Angular. It works so well both in the native browser, and in an Android wrapper.
My ONLY complaint about Angular is the initial load time.
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)
Or Flux/Redux?
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.
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.
You don't really have to upgrade every time a new version is out btw.
I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way applications are structured. I don't get the militant need for terseness that's seen in approaches like React Hooks. I also don't need the choice between multiple backwards-incompatible (or competing) routers, nor do I have a need for functionally pure reducers.
So, it may not be sexy, but It Works and that's good enough for me :)
Still, angular always struck me as going slightly too far into Java-land -- my Struts/J2EE/DI battle scars are larger than even my ExtJS mutilations.
And in between you've got VueJS/Vuex, which seems to move a bit too close to react at times, and EmberJs, which seems to move too slowly and/or without many people watching it.
I really want to go back to late-90s desktop UI development sometimes…
While it's not a JS framework, can I interest you in an explicitly VB/Delphi-inspired app development tool for the web?
It's got drag'n'drop design, you code entirely in Python (including the front end - it transpiles to JS), and it even has a built-in database: https://anvil.works/
It's a different story when your application is huge and mostly made of batteries. ;- )
Now, this clearly needs SOME boundaries, but let's not start a whole "Electron" thread again :)
These are pretty typical Java libraries, but lightweight. Nothing particularly Kotlin about them but that's why I like Kotlin because you can leverage the entire Java ecosystem easily.
I find Kotlin on the backend to be a pleasure.
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 bundle size, which is a lot.
More than that, this release does a lot of preparation work for Ivy in version 9, which will bring a completely new rendering layer.
Also, there is a lot of preparatory work for the introduction of Bazel in the build pipeline, which will bring us fully incremental builds (recompiling only the part of the code that changed and nothing more).
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).
This means that this is now mostly transparent to developers, and taken care for us by the build pipeline without having, for example, to configure webpack and Typescript manually ourselves.
How many different builds do you emit?
Do you run into any frustrations with your user error logging tools having different stack traces?
- We want to re-write the whole thing from scratch. In TypeScript.
- And let's use Google's Closure Compiler for JavaScript. Even though it doesn't support TypeScript, modules, or anything, really from non-Google Javascript world (at the time)
- Oh. Then... Let's create a TypeScript to Closure Translator even though TypeScript doesn't let you extend the compiler and TypeScript and Closure are in general not entirely compatible
- Oh, and we use a weird combination of annotations and templates to work, so... we need to compile our templates into TypeScript (which we need to translate to Closure-compatible JavaScript which will then be compiled further down)
- Only the whole process is abysmally slow. Let's implement incremental compilation.
- It's probably still slow, complicated, and error-prone. We know! Let's use Google's Bazel! You know, the tool to build huge codebases in parallel on clusters. Yeah, why not use that to build JS code?
- Only bazel has no support for either Closure, or Javascript, or TypeScript, so we have to build tools and integrations to work with bazel!
And the quests just keep popping up.
Writing non existing tooling around some tools is almost positive as they can pave the journey to other and better tooling.
Also, I doubt you are paying a cent to those developers to justify your complaints about it.
Not trying to achieve anything. It’s my own personal opinion on how I view Angular’s development. The devs dig deeper and deeper holes to bravely climb out of them.
> Writing non existing tooling around some tools is almost positive
Since there’s no cost-benefit analysis, “almost positive” is entirely speculation.
> I doubt you are paying a cent to those developers to justify your complaints about it.
“Only paying customers are allowed to voice criticism. Please purchase a criticism package or a yearly subscription today. Volume discounts are available, contact your nearest sales representative”
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.
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 framework, rather than hitting some threshold where you suddenly need to switch things over.
Even something that seems simple like a search form can be surprisingly interactive.
You mean like Angular or Ember?
Because you can perfectly use Vue, React, Inferno, Svelte, Imba, etc, on a multiple-page application.
> 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.
I obviously disagree, but please elaborate.
It's an unusual situation perhaps, but having done similar apps with other frameworks and paradigms over the past ~10 years, Angular 2+ just feels like a good tool for the job.
Right, but you could still do server side rendering by consuming a third party API instead of a DB directly.
Maybe bloating is not an issue in some use cases, but client side rendering can have a major impact on the CPU.
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.
Also Angular has helped me a lot with bowser compatiblity in the past (IE 9).
Angular as a framework doesn't prevent you from doing anything on the backend. It's all about the re-usable components imo.
At least that's why I opted to push for a SPA.
First, because the largest ecommerce websites are not SPAs and are generating a shit ton of revenue. Not only Amazon and Ebay but also stuff like Magento and Shopify.
Second, while it can be argued that after a number of clicks the total kbs will be lower by using JSON and rendering on the client, the vast majority of users really care about the initial load. Much like monthly payments, it's generally better to have a consistent 500ms lag than a 3000ms lag on the initial load and then 200ms on every click. Of course I made these numbers to explain my point.
This does not apply to all use cases obviously. In some cases such as an application like Gmail an SPA is completely justified and my arguments do not hold, but in the case of e-commerce I think there are no valid arguments for an SPA.
Outside the public sector React is a bit more popular, but it’s still mainly used outside of enterprise and Vue rarely sees any use.
The job-market doesn’t seem to follow the tech hype cycles much, at least not when you live in a country like mine.
If you know your application will have to be enterprise grade, will be large, will be developed by enterprise devs and has to be supported for years to come, Angular is still the definitive choice (IMHO). Mainly because it gives your team a clear structure to operate in combined with known concepts.
https://insights.stackoverflow.com/survey/2019#technology
This fact about Angular doesn't surprise me. It uses TypeScript which is a Microsoft joint, and the architecture feels rather similar to the MS standard MVVM. Two way data binding in the UI, a "code-behind" in the component. And TypeScript lends a sort-of C# flavor to the framework. It takes some "enterprise" and puts it in the front-end, which can help make the transition from ASP.NET MVC or whatever to Angular a bit easier (especially as compared to something like React).
If you're already doing .NET stuff, and you need enterprise-grade front ends, Angular seems like the natural choice still. One thing about Microsoft shops (of which my employer is one) is they tend to use Microsoft for everything, and despite Angular not actually being Microsoft, TypeScript makes it close enough. I'll be curious to see if the eventual production-ready release of client-side Blazor changes the dynamic at all.
However, you can see just how popular React is by number of npm packages that depend on it: https://github.com/facebook/react
Both have a relatively high entry barrier compared to their alternatives (though lower than a few years ago).
If we are using just a couple of WebComponents with traditional server side rendering, then Vue.