Replacing angular with standard web technologies - angularjs

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

Related

In 2019, how much is it necessary to migrate a site from Angularjs to another framework?

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").

Convert Silverlight APP to HTML5 SPA – tools and technologies

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.

Given the convergence of DurandalJS & AngularJS which should be chosen for a new project?

The owner of the DurandalJS project is now working at Google on AngularJS Next (v2?) in addition to keeping the current version of DurandalJS maintained. The two frameworks are converging.
http://blog.angularjs.org/2014/04/angular-and-durandal-converge.html
For a new mini-SPA project, which framework would be the best choice specifically with regard to the upgrade path?
I note that Rob Eisenberg has listed a number of tips to help existing DurandalJS users get ready for the next version, so it appears there will be an upgrade path available, but I'm wondering if the upgrade from AngularJS to the next generation framework would be simpler.
http://eisenbergeffect.bluespire.com/preparing-for-durandal-nextgen/
To be clear - I'm more concerned in making the right choice for the future (large SPA, split into multiple mini-SPAs) than for my current needs.
I'm not sure which one would be the best choice for now ... actually I'd say none of them is future save enough. Angular 2.0 is going to be definitely different from 1.0 and of course also from Durandal.
Nevertheless the framework itself maybe not that important. I think you should focus on separating code in reusable components. Whether it is a Angular Service/Factory/Provider or a clean Require Module in Durandal it actually doesn't matter. Getting it into the "NEW" Framework should be just a matter of adding the proper wrappers. As for 2-way-binding use the oberserver plugin to maintain clean POJOs.
The most important change from my perspective in NG2 will be the support of Lifecycle events, so even using those in Durandal now will be somehow supported in NG2. As for composition there for sure will be a way to simulate that easily in NG2 as well.
For current work the only two things important for the decision of the currently used Framework in my opinion are the use of RequireJS and Framework simplicity. Sure you can add it to Angular as well, there are several guides on that, but Durandal was built from ground up with RequireJS in mind. Especially in bigger projects this can save you a lot of headache from missing or wrong dependencies. As of the second argument -> porting Durandal to Angular is not that of a big deal because it's written in an easy and understandable way. Vice-versa may be a totally different story. Getting your custom Directives implemented as a combination of templating and ko-bindings can get pretty hard :)
So as a closing statement, if it's going to be a small project, but with the need for continuous support as well as update to NG2 in future, I'd go with Durandal. Besides RequireJS everything is exchangeable and adaptable. In the case of Angular I'm not sure how drastically the new DI system will change the way of development so that would be a show-stopper for me.
Btw. here is the design-document for NG2. So as you see there kinda everything that is important is gonna change:
Router
Persistance
Directives
Modularization (maybe we finally see RequireJS :) )

Is it possible to use ExtJS components in AngularJS?

I'm really enjoying learning to use AngularJS. Now I'm looking for components I can use with it. I've been looking at Angular-UI components but I'd like to know if it's possible to use the nice, supercharged components in ExtJS. Does anyone have experience with this? Any hints or tips or Angular directive libraries?
The company I work for is making a similar move. We currently rely heavily on an older version (3.x) of ExtJS, and the effort to upgrade to the current (5.0) version is at least equal to the effort required to move to angular.
To answer the question (to the best of my limited knowledge):
They can exist together in the same JS application.
Can you use UI elements of ExtJs with Angular?
You can put angular in control of markup via HTML templates in Ext.
Is this a wise idea?
Probably not.
Why would I consider doing this?
I need absolute control over the markup and don't care about possible page load issues
I need to serialize or de-serialize in some special way that Ext doesn't innately provide
I need to do something special like pub/sub (still totally possible with Ext)
In our case, it is a proof of concept for a few modals. If I am biased, I am biased in the direction of ExtJs (which is a huge statement given my background). The more exposure I have to ExtJS, the more I personally like it. I've used several frameworks in the past like Ember, Backbone, KnockoutJs and AngularJs and they are excellent tools that are reaching a level of maturity that makes them excellent choices. That said, they don't follow the same development model/pattern that ExtJs does, and I don't think a direct compare is fair to either side.
It would be almost like comparing Ext to Node (silly, I know).
If your project requires some special functionality that you don't believe is possible in Ext, you are probably like me and have limited experience with it. If you have a lot of experience with Ext, and want to try what we are trying, I say go for it. The single downfall of Ext is the size of the built package that is delivered. Another small framework isn't going to help that, but it also isn't going to cause more pain.
In the end, for me, I just love JS and expanding my knowledge of how things work now and in the future.
For the post above asking about the lack of traction for Ext: the answer is simple... it's not free, and thus not an option for many of us who aren't writing commercial software that fits well with the license.
In our AngularJS app at work, we have integrated a 3rd party ExtJS app with it, not for its UI components though. We open certain popups of that app based on user input and when the user commits data in the popup, we respond to ExtJs events to refresh our app. AngularJS is flexible enough to integrate with any other Javascript code/libraries as long as the library has public events to respond to. I would recommend going through the Directive and scope documentation on how to effectively create directives and respond to scope events.
Personally I do not feel ExtJS and AngularJS would be needed together, unless you are forced to use it like me. There is http://angular-ui.github.io/ that brings in a lot to the table. Again any given JQuery plugin can be integrated using directives, filters etc in AngularJS. So you may want to investigate into that before trying to bother with ExtJS.
Why do you need AngularJS anyway if you have ExtJS? I agree learning Ext can be somewhat difficult though once you've bitten through it there is nothing better at the moment. The only disadvantage is the heavier footprint but who cares? It's not like it's causing any problems... We use nothing but ExtJS at work and the progress in our apps is amazing. It integrates seamlessly with Spring MVC. We don't need to hack in HTML directly which I consider more of an advantage than a disadvantage: no more writing tags, no more open/close tag issues, you can still use css and Ext handles any browser incompatibilities so what else do you need more?? Angular is just the new kid on the block but in total it can not (yet) compete with ExtJS. It doesn't even com close. Just my 2$.
Sencha is planning to add support in the framework. Please find the link at the bottom for reference:
At SenchaCon in Las Vegas on November 7-9 2016, Sencha will be introducing the ability to use Ext JS components, layouts, and themes within an Angular 2 application, which we are currently calling the Ext JS Bridge to Angular 2 (also known as ‘The Bridge’).
https://www.sencha.com/blog/first-look-ext-js-bridge-to-angular-2/

Hybrid page-based / single-page web-app (Angularjs, Ember.js) with progressive enhancement?

I'm wondering if anyone has found a solution to this problem. Is there a way to get the best of both worlds:
build a page-based site, with permanent links, accessibility, SEO, and graceful fallback / progressive enhancement (basically all the best practices of web development)
and, for those with javascript, a responsive front-end experience with ajax loading of content, no page refreshes while navigating the underlying site pages, minimal redundant downloading of scripts/content/css/etc. (all the benefits of a client-side framework like AngularJs or Ember.js)
I see a few major sites are able to manage this (gmail, stackoverflow), and I see that Jeff's new site builds a bare-bones version of the site in a noscript tag.
Is the solution to the hybrid page-based/single-page app to build two versions of the site, send both, and let the client decide which it can show? (is this what gmail does?)
Or is the problem that AngularJS et al. are simply not designed to allow for graceful degradation?
It hurts my DRY brains to think that #1 is the answer.
(The reason I am focusing on AngularJs is that I like its support for html templating, declarative style, and its attempts to fix js scoping. Ember and other frameworks are excellent too; maybe one of them would be a better fit for a hybrid site?)
This questions is a bit of a nuanced one because the answer is "it depends". For example you mentioned Gmail, there isn't any reasons whatsoever that an application like Gmail would need to be indexed for SEO, though depending on what you want or need to support you may want to ensure you can support not having Javascript.
However even the "no-javascript" argument is getting tired and weak these days, at least for the class of "web applications". If I want to use a Windows application I need Windows, if I want to use a javascript powered web application it isn't unreasonable to assume that I'm going to need a browser that isn't crippled to use it.
However back to your question I can only speak to AngularJS because I'm the most familiar with it. For the most part it does allow you to support a progressive enhancement approach, though don't expect to use things like URL routing if this is what you want to support. What you can do is use AngularJS controllers, bindings and directives similar to how you might use jQuery as a way of enhancing the interactions and behaviours of the page.
Just keep in mind this approach will seriously limit what you can do with Angular (or Ember for that matter) and it may start to be debatable what you are getting from this approach that you couldn't easily do with jQuery alone.
The alternative these days is to do what sites like Twitter are doing. That is basically serve fully rendered HTML from the server for any view on the initial load and then use Javascript for subsequent loading and enhanced UI behaviour. This is very effective (though perhaps quite challenging to implement) if you really need to support browsing with and without Javascript and has the added benefit of improve the rendering/load times for the first request. Again "it depends" because it depends a lot on how your site actually works if it is possible to use this. You have to design for it, and it isn't going to be trivial or easy.
Update:
For what it's worth we are taking the Year of Moo approach and rendering the pages that need SEO using PhantomJS and sticking the cached initial state of them somewhere to serve them up. We have a rake task we run on deployments to update this. Again this is just the initial state but it helps get around the issue for now.
Things are always changing though and I'm sure I will have changed my mind on this approach in a year or so.
Have you read Google's Making AJAX Applications Crawlable. You can have JavaScript single page app and crawlable content.
If you stick with angular, there is interesting article: Turns out it is possible to have your AngularJS application indexed

Resources