Let me start with the justification. A lot of companies that have now been using AngularJS for years are still using it, and don't have immediate plans to migrate to 4+. So there's marketability, plus the inevitable requirement of knowing both as an Angular developer.
My question is broad I know, but I am curious to hear from folks who have experience with both. Are they completely different, or will some of the knowledge transfer? For those who know both really well, what are the key differences that really stick out to you?
In comparison to Angular (2 and higher), AngularJS has several important limitations that affect the way applications can be built.
A single injector with string DI tokens and no built-in lazy loading.
Config/run phases and synchronous bootstrapping (the overview of configuration recipes).
Scope hierarchy for data binding and its consequences for application architecture - the concept of digests, performance impact, AngularJS-specific services ($timeout, $q, ...) instead of native counterparts, etc.
jQuery-influenced approaches for manual DOM manipulation.
Considerably different set and API of built-in services, directives and filters (pipes).
No support for nested applications (possible with a hack).
No view encapsulation and component styles.
No built-in component router.
No built-in translation/i18n.
No built-in support for workers and server side rendering.
No official CLI.
The development of AngularJS has been focused on providing upgrade strategies and common features since 1.5. In a lot of aspects Angular/TypeScript experience can serve as a source for best practices for modern AngularJS development.
AngularJS is generally more flexible in the ways how its injector and compiler work and allows for a plethora of neat hacks that have been rendered impractical or impossible in Angular.
There's a lot of smaller differences that AngularJS introduces which may be discarded if the goal is to intentionally limit development practices to the ones that allow to build TypeScript/ES6/ES.next AngularJS application that follows Angular guidelines and could be easily upgraded to Angular in future.
ng-metadata does its best to unify AngularJS coding practices with Angular but still requires a good understanding of the differences between two frameworks.
However, smaller differences make a big difference if a developer works on existing AngularJS project that heavily relies on them and uses legacy coding standards.
Related
I'm a project manager of a market place and I'm trying to find solution for my concerns. For two years a ago we decided to develop market place.
In front layer we decide to use angularjs and our team professional implement front layer using AngularJS. We add dependency injection for first time to angularjs 1.3 and solve google analytic crawling in SPA website.
But when google announce On July 1, 2018 AngularJS entered a 3 year Long Term Support period. As a project manager I have a big concern because We living in 2019 and after two years whats happen for our website ?
But my biggest question is how optimistic how long can we use Angularjs?
how much migration is necessary for this framework and
Is it possible that the sites written with Angularjs are not able to work after 2021?
Google announced:
All AngularJS applications that work now, will continue to work in the future. All published versions of AngularJS, on npm, bower, CDNs, etc will continue to be available.
For more information, see
Angular Blog - Stable AngularJS and Long Term Support
AngularJS Version Support Status
It’s out of date now, and new projects should absolutely not be built using it. This isn’t to say it was ever a particularly great choice. AngularJS came out of nowhere and became popular by default, rather than because it had particularly great design. It has a difficulty curve better suited to a great roller coaster than a decent framework, and a bunch of weird architectural and terminology choices. What the hell is a $scope, anyway? And what is a directive? What does transclusion actually mean? Meaningless terms that AngularJS has created. AngularJS does some things that are fundamentally wrong, such as creating invalid attributes on HTML markup. Even Google doesn’t use Angular for their own apps, like Gmail, and there’s a reason for that.
In fairness, AngularJS was always a poor choice. Its idiosyncratic code means that unlike other frameworks, it’s not good at implementing an agnostic, javascript solution. AngularJS code looks unfamiliar to anyone not super experienced with the weird intricacies of AngularJS itself.
Thankfully, this decision is well made for you – AngularJS is now quite thoroughly dead, and only legacy projects will continue to be using it. We should be grateful for what AngularJS has given us, and respect the position it held, but we should be just as pleased that it’s gone.1
The change is only about "support" and it means, no more bug fixes and no more improvements. Other than that, everything will be the same. Although, you should consider some disaster scenarios after LTS.
I saw some posts about running AngularJS and Angular side by side and I think it can be a good solution for your problem. Since you have enough time to migrate, your team can develop new features on Angular and you can also maintain your current AngularJS. Eventually you can get rid of AngularJS depending on your project size and development capacity.
Please check these scenarios.
Running AngularJS 1.6 in Angular 5 (side by side)
Running Angular and AngularJS frameworks side by side
For Angularjs support, you can find the previous discussion on this portal: angularjs 1.x support lifecycle and end-of-life
And the question regarding migration, in my personal opinion migration is a better option as the latest Angular version provides Boost in performance, Mobile-driven approach, code Maintainability & optimization, and most importantly Reduced development time and costs with better support.
And if asked about the migration approach, I would suggest a complete re-write that can be the most cost-effective strategy. If you’re a manager, put your team through Angular training (live, online, videos, books). Allocate time and budget for getting your developers up to speed with Angular as the learning curve is steep and prior experience with AngularJS is not overly helpful. Then your developers will write the new version of the app as per best practices recommended for Angular/TypeScript projects.
And finally, it’ll definitely pay off in the end. And, secondly, the newer versions of Angular won’t let you systems become outdated or irrelevant.
There is a team called XLTS.dev who are providing extended support for AngularJS beyond December 2021.
We have used Angular JS extensively in our company for enterprise projects, mobile applications and continue to use it. Google's decision to stop development of AngularJS and put it on a EOL will definitely make developers to panic. But 3 years to migrate away from it is a long time and you can plan accordingly.
If your plan is to migrate to Angular, then you can follow their official guide to upgrade using ngUpgrade. You can find numerous articles online that explain how they upgraded existing AngularJS apps to Angular.
If your plan is to consider migrating to a totally new framework, then this will involve some work. You should take a look Web Components spec. Your existing directives/components can be re-written, with less effort, as web components (shadow DOM) or custom components (without shadow DOM). There are libraries that help you write these generic components - supported on most browsers today - Stencil JS, lit element and a few others.
The advantage of using Stencil JS is that it provides tools to compile your web components to target different frameworks (Angular, React, Vue, Ember).
The latter solution seems feasible as it allows you to migrate directives one by one over a period of time, without having to re-write the whole application in one go. In the future you can also re-use your components in the framework of your choice.
As for your question about will it continue to work after 2021 - yes it will continue to work. The problems you might face might not really be of technical nature, but related to hiring resources to work on it or maintain it.
I am AngularJS developer and I do continue to use this framework for some of my projects. I am aware that in not too distant future this library will be completely outdated (as some of you can say it's the case now), however:
AngularJS ecosystem gives you still lots of choice/support (as framework is very mature)
my main libraries as ag-grid, highChart or others, help to build great apps out of the box with little time
I still do enjoy to work with this framework for it's simplicity and flexibility
If you should build brand new app I would recommend React or Vue (or other framework) especially if you do not have significant experience with Angularjs. However if Angularjs is not new for you, you need to go fast - just use your experience and go for Angular.
Taking into account what you wrote:
My main concern is after 3 years of support. Whether after the 3 year end of support, Angularjs sites can continue to work without problems
Angularjs apps won't just stop to work like that, from one day to another.
As your project requires long-term maintenance, needs to be built from scratch and will take lots of effort - Angularjs ecosystem is then probably not the best choice for you (I do insist "for you").
AEM itself is self reliant WCMS and can be used to generate very rich digital experiences over multiple channels.
Often there is talk of using Angular as front end and moving AEM to backseat. What is point of doing so?
Using angular will add additional complexity and developer has to deal with it, increasing efforts for building system.
It will undermine core AEM features e.g. HTL & clientlibs
Multi channel experience can still be achieved without angular.
In short: there is no point in doing so when you deliver static pages, as seen in standard AEM use cases. It get's even worse: when you want to use AEM for dynamic pages, you might run into performance issues, so an external data source / index to query the "dynamic" data is almost mandatory.
I would recommend a clean separation of view and view-model using Sightly and Sling models which allow for a fast refactoring of views in case there is a good reason to migrate the frontend to a different technology / templating language.
And I am leaving out the fact that Angular will be basically replaced by Angular 2 and there are strong competitors like React, Ember etc...
AEM's core strengths are:
WYSIWYG
Multiple Adobe suite integration (analytics, target etc)
Authoring experience for MSM
Security integration from UI to db layer
There are many more strenghts along with many weaknesses. Using Angular or other similar platforms require AEM to be used as Content as a Service (CaaS) which isn't its primary strenght yet.
Organizations that invest in AEM are mostly after the core strenghts provided by it and won't normally benefit from using AEM as a CaaS platform. Unless Adobe provides plugin model for their integration suite that can work with mainstream front wnd technologies like Angular (2) and React, it would be a very uphill task for any team to get the most out of AEM suite without missing out on all the benefits provided (at a cost) by the whole of Adobe marketing suite.
In short, from TcO perspective, these platforms are not easily compatible with AEM due to the unique nature of product which means the integration is normally a challenge and sometimes counter productive when integration benefits of the core platform are compromised.
I believe it totally depends on the use case. I have done projects with AEM using jQuery and others using Angular. If developer knows what he/she is doing, adding angular is not much of a hassle. 2 way data binding, a clean way of doing Ajax and ease of Single Page Application, that pretty much sums it up. Works really well..
Angular and other front-end frameworks provide the additional benefit of SPA which if integrated the right way with AEM can work wonders!
Yes, I agree that integration is an uphill task but the page load times can reduce significantly and using features like routing we can reduce the server calls for transition across the site pages.
Why AEM-Angular integration can be a good thing?
AEM can be used as a CaaS platform in few cases where the content will primarily be loaded using SPA. In other cases, components can be a mix of HTL and Angular where HTL can provide additional security using proper context.
You can pass AEM authored content to Angular directives/components as attributes and perform the desired functionality.
Angular can be used to build reusable components and directives on the front-end which can simply be reused across AEM components.
The Angular dependencies can be made a part of the AEM client library and this ensures that Angular functionality works as expected.
Build tools like Maven and Ant are powerful enough to support the integration. Simple tasks have to be written in pom.xml.
AEM 6.4 Beta has support for front-end frameworks and I have observed how fast the content load can be!
Other AEM integrations (Adobe Target, Adobe Campaign, Adobe Analytics) can be still leveraged in similar ways as before.
Did I forget JQuery? Angular and other front-end frameworks will provide cleaner and more efficient ways of doing the same things in JQuery.
The decision to use both will totally depend on the use case and this is not recommended for all solutions though.
I have worked on AEM for more than a year. In my project, the stack was AEM, jQuery, and some 3rd party library to handle JS relevant issues(like IE support and util functions).
If you want to integrate Angular then I see the below things from your query
Good :
You don't need the headache of java related issues.
No need for more backend developers(though I am a backend developer).
If you do want to change some files in stage or prod environment, no need to go with java change directly package installation will work.
You can leverage angular strategies to build your project efficiently.
No need to worry about your project optimization. Angular will take care of JS library optimization and loading into client-side browser.
No need worry for page speed issues from google audit for your websites. That will be taken care of by Angular.
You will be able to achieve the hybrid model of clientlib and can avoid lot's of Js issues along with clientlib comes in to picture.
Testing of components will be easier.
AEM also follows Component similar to angular, so things can be merged based on good architecture.
Not Good:
sightly syntax might be underutilized.
Still, there will be cases you have to dependent on java for achieving some features.
Security issues need to be fixed as everything will be done on the client-side.
more issues if you are using etc/map related URLs.
more complexity if you follow SEO optimization standards.
More dispatcher configurations.
Needs to habituate aem structure with angular structure.
AEM structure will be more complex when merged with angular
I am quite new to Angular. I have written this answer based on my experience. I will keep updating if any edits required.
Using AEM as an integration layer is a challenging decision. AEM is a content management system and works well for static content (content is cached at Dispatcher layer).
However, it use the Jetty server under the hood. Jetty uses thread pools for handling requests. It means that when the number of users increases, it use more and more resources. The situation is the same for time-consuming operations - think about API's unavailability or delays.
Instead of using AEM as an integration layer, you delegate this integration logic to more reactive systems such as Knot.x. Then AEM may serve only static pages (templates), Knot.x would fill all required data from external APIs.
See more here.
My team is working on a strategy to convert our cloud based Silverlight app to HTML5 app. Although we have been working on formulating a strategy to find best possible set of tools, technologies, and methodologies to convert our App to HTML, I am asking this question here to get some feedback from the large community at SO and to learn from experiences of the people who may have done similar things in recent past.
My question has a few parts.
Our app is written in Silverlight and uses WCF RIA services. Most importantly, we rely a lot on MVVM and we wish not to rewrite that logic again hence to reuse as much code as possible. What would be, in your opinion, the best possible combination of tools and technologies for us to use?
In order to make SPA, we would like to use some of the “cool” new frameworks out there but we really want to minimize our work (due to hard deadlines) and be able to thoroughly test our app easily and quickly (hence the code reuse). Is SPA even a good option or should we go for traditional MVC app? Keeping in mind that there are more than 200+ views in our app.
If we chose to go the SPA route, which framework is best suited in terms of life span. We have to move away from Silverlight because it is going to die soon. We don't want to be in the same situation again in near future.
Moving an existing Silverlight app to and HTML5 web app is the perfect project for AngularJS. Angular has it's own similar MV* design pattern, but you will not be "reusing" code from your existing silverlight apps. The main ideas and abstractions may be similar, but just the nature of how html and js work together, and especially how they work in angular, you have to do it the angular way.
Also, Angular is somewhat of an engineering approach to web development. It is not a learn-it-in-a-weekend piece of cake framework to master. There's a lot that goes into it. There's noob ways to do things in Angular, somewhat noob-ish ways to do the same things, and then the so-called "right" way of doing it so you may find yourself learning some ways of doing things only to have them replaced with "better ways".
If you want to "minimize your work" then Angular might not be the best choice, but if you want your HTML5 app to be really awesome then any framework you with will require some studying in addition to getting used to the inherent quirks of Javascript.
Angular 2 is hot and just launched a Beta release, but I'm still happily using AngularJS 1.4 for all production apps.
Both angular and laravel are great frameworks meant for slightly different purposes. Since they achieve to do similar things like -
They both focus on an MVC-inspired application structure, and each of them support a different directory structure by default
They both offer templating engines of their own, with conflicting syntax (which can be changed of course)
They both offer DOM iterators ( php foreach vs ng-repeat )
And many more similar conflicts
Since they are so similar in philosophy, isn't it redundant (and even conflicting sometimes) to develop a web app which uses both these frameworks?
Since each of them are so powerful in themselves, would it be a good idea to mix both? How common is the combined use of these in real world websites?
Am I better off using angular with basic PHP instead, if say, I was developing a medium scale web service (5000+ users)
What are some of the other backend+frontend framework combinations which are symbiotic and most frequently used?
Yes they can do similar things, but they don't have to.
Of course it doesn't make much sense to use the same feature of both of the frameworks. Meaning if you choose to use AngularJS for templating you don't need Laravel's views. But that's nothing you should worry about. If you don't use it, you don't use it. The fact that you don't use the entire functionality of a framework shouldn't have any bad impact on your application.
But note: Be consistent
Don't render one view with Laravel and use AngularJS for the other.
Recommendation
I personally have made good experiences with Laravel as a RESTful API and AngularJS taking care of the rest. So AngularJS is doing all the frontend stuff and communicates with Laravel only via JSON.
I'm working on a project which has the luxury of using ECMA 6 on the latest browsers for a product that will be shipped in 1.5 years. So we thought why not use Web Components now that Angular 2 isn't available (which is going to be ECMA 6). And while we are at it, can we replace Angular altogether without having to go back to stone age?
How to replace Angular?
There's this site called youmightnotneedjquery.com which is basically about how modern browsers actually have most of the stuff that jQuery was traditionally used for. I'm interested to see something like that for Angular.
We mainly use four Angular features. What are my options for replacing them?
Angular Directives --> Web Components
Angular Modules --> ECMA 6 Modules (not exactly the same thing)
Angular Routes --> ???
Angular 2-way databinding --> ???
PS. We don't want to replace Angular with something similar like Backbone or Ember. We want to replace it with standard web technologies but if we have to use small tools to fill the gap, we'll consider it.
I've been researching in the past 3 weeks and turns out many people are thinking about an alternative after Angular took a drastic change path. Fortunately the upcomming W3C Web Components standard actually has all we need and it works right now with polyfills from the Polymer project. So to answer the question:
Angular Directives --> Web Components use the polyfill until all browsers support it.
Angular Modules --> ECMA 6 Modules part of the problem is solved with HTML imports. But you can also use Traceur until the browsers support it.
Angular Routes --> There's a component for that™ use <app-router>.
Angular 2-way databinding --> Polymer adds a "magic" layer on top of the plain standard web components. This includes many features including data-binding.
+Plus More
If you're wondering about the build process for concatenating files in order to reduce the number of HTTP requests, take a look at Addy Osmani's post about Vulcanize. Spoiler: you may not need it with the upcoming HTTP 2 optimizations.
Many Angular projects use Twitter Bootstrap for the layout. Polymer can do that plus it plays nicely with Google's Paper elements (totally optional but superbly awesome).
If you want to make yourself familiar with web components in general, here is a bunch of nice articles: http://webcomponents.org/articles/
And here is a wealth of web components: http://customelements.io/ I don't know if it's going to be a new NPM, but the list components is pretty impressive and growing.
It's relatively complicated to expose an API for an Angular component. People have come up with all sorts of methods from link function to emitting events. In Web Components, however, it's really easy to make your component interact with the world outside and indeed the API and events you expose aren't much different from standard HTML tags like <audio>.
Just like Angular, you can use Polymer with Dart as well.
Conclusion
Overall, I don't see any reason to use Angular except if:
You have a huge source code investment in angular and don't want to port everything to standard web. (Angular 2.0 will deprecate your code anyway, so you're stuck with Angular 1.*)
Your team is too lazy to learn a new technology (in that case web might not be the right platform for this attitude anyway).
Angular was good for what it was doing and had its own Hype cycle. Web components solve many of the issues Angular was trying to address. Probably Angular had a role as a proof of concept for the Web components. But now it's time to move on. Web is reinventing itself everyday and it's inevitable to moves someone's cheese.
I'm not saying that Polymer is the ultimate answer to everything. At best it's another Angular which will render useless in a couple of years, but now it's a good time to learn and use it. The W3C standards don't die easily though, and Polymer tends to be much closer to them.
There's an element for that™ is the new There's an app for that™
TLDR: seriously consider writing an almost Angular 2.0-compatable Angular 1.3 app before rolling your own framework
It seems as if you've identified that Angular does a lot of things the right way and that's why you're attempting to replicate it, so basically you're going to roll your own by combining a hodgepodge of libraries. Unless you have an enormous investment of Engineering hours, the framework you build will likely be:
Lightly documented
A cross-browser maintenance nightmare and (worst of all)
Difficult for new hires to learn
If there wasn't a framework out there that did what you want to do already, I think rolling your own makes sense, but by trying to recreate Angular you're:
Taking on a lot of Engineering work that has already been done by a dedicated team, that could have been spent on building product
Made it MUCH more difficult to onboard new employees because you have to:
Find candidates that are willing to use a home-grown framework instead of growing their skills at an open source framework they could use elsewhere
Train these employees to use your framework (and good luck unless your documentation is mature)
I know your question asks how to replace Angular, but I've seen too many companies go the route of rolling their own and paying for it down the road. Again, if your budget includes a ton of core resources to build out (and document, and maintain) the framework and you don't think there is any chance corners will get cut when push comes to shove later if timelines get tight, then rolling your own might make sense. However, I think you should seriously consider reading up on how to write Angular 1.3 apps so that they're easy to port to Angular 2.0 and go the Angular route. Just look at the size of the community you're missing out on:
http://www.airpair.com/js/javascript-framework-comparison