Related
I'm currently learning Front-end web development and the difference between Vanilla JavaScript, frameworks and libraries (React for example).
Now I'm familiar with web components for making new custom HTML tags. As I know, React is made for the same purpose, but when I visited the Instagram website (the first website that uses React that comes to mind) and looked at the HTML code, I didn't find any custom HTML element, in fact, most of the elements are made of "div"s tags.
If a complex social media website like Instagram isn't made of custom elements, then who uses them and why?
React is a totally different beast, dating back almost a decade. It was developed by Facebook because TOO many teams were doing TOO many updates in the same DOM. So they came up with a virtual DOM where all required DOM updates are merged before writing to the Browser DOM.
Works great for Facebook. Newer technologies like the Custom Elements API and Svelte (Compile, don't Transpile) have proven it is no longer the best solution.
Reacts outdated technology now scores a meager 71% on https://custom-elements-everywhere.com/
React and W3C Custom Elements are not friends
Because the Green DOM elements are not tracked by React.
And if you want to mix Green and Yellow you have to basically re-write/wrap each and every component into React syntax. Because React not only does DOM Elements different, but also does DOM Events different.
The future
This makes an interesting future: React and the W3C standard are diverging.
And the W3C standard is defacto set by Browser vendors,
not by the W3C, as we learned from the never implemented ECMAScript 4 saga (1999 - 2008)
So its
Apple (Safari) + Mozilla (FireFox) + Google/Microsoft (Chromium/Chredge)
versus
Facebook (No browser!)
'problem' with the W3C is all members have to agree on a standard; that is why it took years for the Custom Elements API to mature... and React got a head start
Facebook does now "own" 60% of the developers market...
but hey,
Microsoft had 90% of the Browser market... once,
and Flash was installed on nearly every device....once
The Custom Elements API will exist for as long as ECMAScript runs in the browser
It is not a framework or library! It is a language construct.
Not learning Custom Elements is like saying:
I am not learning Set or Map, I can do everything with Arrays
Older rant at: Web components - Services / non html components
Or believe the 2020 Front-End Survey:
As you said, instagram uses react which doesn't transpile to web components
react is not the only components based lib to NOT use web components, there's also ¹ : vue.js, Polymer.
But some other components based lib do use web components as their base ¹ : slim.js, stencil.
All of these libs can be used with webcomponents, some even tell us how to do: react, vuejs.
!!! this part may be considered as opinion based !!!
AFAIK the lib which chose not to use webcomponents were created before the web components API was finalized, and the cost to rewrite using them is too big.
!!! this part is opinion based !!!
Most person uses lib because web components doesn't give the same effortless two way binding.
In opposition webcomponents seem to give more control about when the component reload and how the binding is done, but it needs to be coded which is extra work.
¹ based on the list of custom elements returned by this script on the main page of each lib
In React it's different.
Working with React you are using JSX.
This is just tag syntax, which is neither a string nor HTML.
Under the hood this syntax in converting to usual JavaScript(using Babel).
You can read more about it here.
So I am coming from Angular and wanted to take a look at how to create vanilla Web components.
Now coming from Angular we tend to have things divided: Components (which acts as HTML,CSS, and some javascript) and then "services" which mainly acts do jobs such as collecting data and doing the "hard backend" jobs that shouldn't happen in components.
now while I know that Web components and a Framework such as Angular are not the same things I am wondering how you would structure a project.
All the articles I've found on web components only explain the bare minimum (Shadow-dom, template and custom HTML)
They don't really show you how to create an enterprise-level application with the technology.
So my question is two-fold:
What are the best practices for the structural architecture of an enterprise-level application made with web components?
Is separation of core logic such as encryption, datastreaming, and so on something you do when using web components, and if so how?
I am more and more inclined to say "Web Components" are a language construct.
It is called the Custom Elements API, so no different from the Fetch API, or the MutationObserver API
Then your question is: How can I build an application with the [name here] API?
Superduper "Tools"
Tools like Lit, Hybrids, HyperHTML, Lego, Stencil, all have a polyfill background, they made "Web Components" possible in the olden days when Browsers didn't fully support the Custom Elements API.
They have evolved to all claiming "This is the best Tool to develop Web Components"
In that sense they can be compared to jQuery.
Once a must for Web Developers,
and then selectors etc. became part of the W3C standard.
With the advent of IE9 in 2011, there was no real need for jQuery anymore.
Today's playing field
Now, Edge is running on Chromium, and Microsoft pushes Edge by default. All modern Browsers are up to par with the Custom Elements API
To take the jQuery comparison one step further back in history. There were dozens of jQuery alternatives 10 years ago. If you happened to invest in the "wrong" tool, you eventually had to convert to jQuery (or just Native JavaScript if IE9 was the oldest browser you had to support and you understood W3C standards (nearly) always win)
The same is going to happen with Lit, Hybrids, HyperHTML, Lego, Stencil and all others.
The odd one out
Angular or Svelte or Vue all play 100% nicely with the Custom Elements API
React scores 71% at https://custom-elements-everywhere.com/
The 60% React heads will say the W3C standard does not support React.
If you have been around long enough (> 20 years) you understand React can be compared to ECMAScript-4 (the W3C standard that never made it)
Great technology, but if the Browser Vendors don't implement it in the Browser, it has no future. That means React is a potential "jQuery" also. Or maybe Flash (ActionScript had ES4 constructs) is a better comparison.
Makes for an interesting future:
Will Facebook solve that 71% score?
Will all Browser vendors (Mozilla,Google/Microsoft,Apple) implement React(Native)?
The Future is now
If you do not have to support IE11 there is a modern, level Custom Elements API playing field.
If you are learning, learn the API first, then see if Tools can make your development life easier (and accept the risk it all needs to be refactored when your tool of choice goes where MooTools, YUI and many others went) ...
Then again... banks still run Cobol... maybe React is the new Cobol?
Your questions
What are the best practices for the structural architecture of an enterprise-level application made with web components?
Is separation of core logic such as encryption, datastreaming, and so on something you do when using web components, and if so how?
You built applications with Web Components as you built applications with Classes or Proxies. Components encapsulate logic, only difference being the Custom Elements API also makes for great (really great) semantic HTML.
Alas, I see companies and developers focussing on the "Tools" instead of on the API
To me, a fool with a tool, is still a fool.
I was in the Microsoft SharePoint world, when TypeScript was launched.
Made good money refactoring MVPs "great" TypeScript (alas in ES3 syntax because they forgot to keep up with JavaScript) to ES6
I left that world when Microsoft went all-in on React.
Component developers now learn tools, like they learned jQuery...
Enough rambling
The Custom Elements API is a JavaScript language construct.
It does some things really well and others not so well.
Will the API make an impact? Yes, just like Classes and Array methods did. And those required a mind-set change also.
My advice:
Play with them, like you learned .map and .reduce
don't try to write full blown applications, start small
create TicTacToe in a JSFiddle or CodePen.
Ask here on StackOverflow Code Review for feedback.
make mistakes
make more mistakes
make more mistakes
learn
The Custom Elements API is a W3C standard, supported by all Browsers,
this technology will work for as long as JavaScript runs in the Browser.
I gone through the same cycle and had the same question, actually in the position of the need to create an enterprise app and give my co-workers advise as a solution architect. With 20 years background in Web technology I thought it's not so hard to answer.
With the decision to support "modern browsers" the choice of the Web Component API was easy. I have also strong knowledge of Angular and React. We decided to use the project structure and similar tool chain (WebPack, Jest, you name it). This was clearly very wise.
In the beginning it was just a bit of library code we wrote to DRY. It ended after a year with a full blown thin library (let me put it here as a reference). After some time we understood that we really need data binding, a state model, and integrated validation. You're simply not productive enough without. It's still a lot more compact than the fat frameworks, but it's a lot more than just a new kind of jQuery. Web components itself are just API calls. But everything else is hard work on top of Proxy and his colleagues. That's what all the smaller libraries try to achieve more or less (Lit, Hybrids, HyperHTML, Lego, Stencil, ...). We ended up with something really complete and very close to the fat brothers, but still very small (decorators like Angular mixed with JSX like React). But despite the fact that you're eager to write a library I'd recommend to look at one of the mentioned ones. Be aware that a future API may reduce the need further, I'm pretty sure ES2025 will have a great deal of that stuff on board.
Disclaimer: I'm the creator and maintainer of such a thin library, called #nyaf.
As the Google IO just ended and Google just released Polymer 1.0, I am more and more lost regarding the Google intentions.
I am developer in a little team (5-6) and we are trying to find the best framework/library for our next project.
Google released Angular.js few years ago and it was nice, but the learning curve was high and the maintainability of a medium/big project was a nightmare.
Today, angular2 is in alpha and already very criticized. I have tried it to do a todoapp (hourliert/angular2-firetodo) linked to a firebasedb and I liked it but it is very verbose compared to aurelia (check the last post on durandal blog).
At the moment, I am doing a (little) webapp using the new polymer. I hate the fact that polymer didn't consider ES6 yet. But I have to say that it is nice (even in ES5) to use it. It feels very rigorous.
My question is, why doesn't Google use polymer for more public application (I know only these polymer app: Google Music, Translate community, Google IO 2015, that's it ?). It seems angular (1) is in the same basket. I don't know lot of Google public application built with it.
However, It seems Google uses Angular for more 1500 internals projects (I can't find the source of it, could you confirm ?).
Finally, I believed that, polymer would be used by angular2 team to build the next material ui. As polymer elements are reusable WebComponents, it would have been nice and could have explained why Google maintains Angular & Polymer.
But it seems not
And in addition of all of this, react is in the party...
2015 is a very innovative year for Front-End. On the other side, it gives sone serious headaches...
If someone have some explanations, I would be glad to hear them.
Thomas
Regarding Google's intentions for Polymer vs Angular, I believe they intend for them to work side-by-side. In their Polymer keynote they expressly say that Polymer is a library, not a framework, and that they believe there is a solid distinction between the two. They also stress that interoperability is a key feature of Web Components. The vision seems to be that you can import a Web Component (even those not built with Polymer) and use it right alongside Angular, jQuery, React, or whatever other framework you would prefer to build your overarching application logic with.
That said, because Polymer is still Javascript, you can use it to build components complex enough to handle entire applications, such as they did with their Santa Tracker. In that vein I believe the choice is left to the developer.
hate the fact that polymer didn't consider ES6 yet.
Actually there are third-party project which allow you to create Polymer 1.0 elements using TypeScript ES6:
https://github.com/nippur72/PolymerTS
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Our team is way too excited with the alpha release of Angular 2 and we're just eagerly waiting for it's stable release and getting started with it.
But during the ng-conf 2015 on Angular 2 by Misko, we came across following things which made me confused
TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing ?
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
I'm not sure I've structured my question well, but above are my concerns before I start learning angular 2 because with their demonstration of angular 2 + typescript seemed like it's gonna involve a lot of earning curve for me and my team.
I'll really appreciate if someone can clarify on the above listed concerns I have.
Thanks.
TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
TypeScript is about static analysis for better type-safety. It also has a pretty nice suite of editor tools (e.g. WebStorm). You don't need it for performance. It's more a tool for helping you author. Personally though, I love it.
I've begun migrating some of my existing open-source libraries to TypeScript because it's so much easier to work with. For example, check out Task Runner before and after.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
A lot of ES6 features can be polyfilled. Check out https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing ?
Web components are also polyfillable (see here). In this case, I'd suggest you follow the Angular team's recommended practices for creating your components. Also perhaps keep an eye on what's coming out of the Polymer team in this regard.
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
This sounds to me like premature optimization. Build for (plain) Angular first and optimize only if you notice performance problems in particular parts of your application.
TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
TypeScript is not required to use Angular2.
Most examples you see will use JavaScript:
classes (ES6)
decorators (ES7/Typescript)
types - (Typescript)
Except, browsers don't support those features yet so all Angular2 source will need to be transpiled to ES5.
So in ES5:
classes can be faked by extending prototypes
decorators can be faked using wrapper functions
types aren't really necessary to begin with, they're synctatic sugar added for safety
It would be unrealistic to expect existing users to inherit the risk of using experimental/bleeding-edge standards. As such, the documentation covers writing Angular2 apps in ES5, ES6/7, and Typescript.
Aside: I personally prefer not to use TypeScript. Traceur can be configured to support with experimental extensions for #decorators, and system.js provides a polyfill for the proposed es6-moduler-loader spec.
Here's a look at the Angular2 Documentation.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
As I said already, ES6 isn't officially supported yet in all browsers. Even if it were, most sites will still require a polyfill to provide backwards compatibility to older browsers.
One of the cool features of the es6-module-loader is the ability to dynamically load dependencies on the fly. By the time Angular2 is out of beta, it should be easy to incorporate this into your app as a feature-detection strategy.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing?
Not hard although you may need to use Angular2-specific web components. The reason being, Angular2 is more than a front-end web framework. It's can also be used for isomorphic (ie prerender on the back-end), native, and mobile apps. That means, touching the DOM directly is highly discouraged.
As for the creation of the components themselves... It's no different than creating any other component in Angular2. Unlike the old MVC model of grouping code by type (ie models, views, controllers), the component model encourages grouping code by context.
When you import a reusable component, it should come with any directives, services, etc required to use it.
For an example, see the I created. In addition to cloning the repo directly from GH, the code can be installed and imported directly via JSPM.
Simply import it, add the component class to your view directives and any <ng2-markdowm> element in your template will just work. It doesn't get much easier than that.
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
There are 3 major performance improvements introduced in Angular2.
1. 2-way data binding is no longer the default
Elements that require data binding need to be explicitly marked in the template (ie don't fret, the new syntax makes this really simple). As a result the overhead required to do dirty checking on the DOM is dramatically reduced.
That means, no more $scope, $scope.apply(), and weird scoping rules in the HTML markup. Instead, the hierarchy of custom <elements> is defined in the Angular2 components.
2. Angular2 leverages the virtual DOM
jQuery made it extremely simple to directly manipulate the DOM. As a result, it also made it extremely easy for inexperienced developers to thrash the DOM and trigger layout reflows via frequent incremental updates.
The VDOM is basically a simplified in-memory representation of the DOM. Incremental updates get applied directly to the VDOM which later get applied to the actual DOM in batches.
Aside from network requests, DOM manipulation is JavaScript's greatest performance weakness. The VDOM on the other hand is an order of magnitude faster. Instead of expecting devs to follow 'best practices' by manually batching updates to the DOM, Angular handles batching transparently.
Fewer DOM manipulations = less UI rendering/reflows = a much more responsive user experience.
3. Angular2 runs on a background worker
This isn't exactly a new concept. Desktop GUIs have worked this way for years, it just wasn't technically possible the introduction of HTML5 background workers.
In most desktop applications, the main context runs synchronously+ and the UI runs asynchronously in it's own separate thread. That makes the user experience responsive regardless of whatever the application is doing in the main context.
+Note: This isn't necessarily true, but for clarity sake.
In the browser, all execution happens in the main context+. That means, every time Javascript has to block on a CPU-heavy operation, the user interface becomes unresponsive to the user. This is not ideal and makes for a lousy/inconsistent user experience.
+Note: In practice browser implementations vary greatly but lets keep things simple.
With web workers, it's possible to push everything but the DOM+ into a background worker context. Ideally, Javascript's should have little-or-no impact on UI responsiveness.
+Note: The DOM's state still needs to be accessible to the renderer.
One side-effect this transition is, the Angular2 architecture is now completely decoupled from the UI/DOM. Meaning, it's now possible to write UI adapters for other platforms (ex for IOS, Android, SmartTVs, etc) that run on the same Angular2 code natively.
React
As far as I can tell React is using all of the same performance improvements as Angular. They use the VDOM to batch updates, and mentioned native portability to other platforms so I assume they went through the same architectural change as Angular.
Honestly, using background processing to free up the UI is just another step in the evolution to reach feature parity with desktop applications.
Angular2 vs React
I encourage you to watch the video again all the way to the end. The presenter screwed up when he wrote the code so the live demo wasn't an honest comparison.
With that said, it doesn't really matter which is faster. Neither will be dramatically faster than the other but they'll both be dramatically more responsive and scalable compared to other UI frameworks.
Update:
Rewrote the section about web components to better answer the question.
Note that Angular 2.0 does promise to work well with Web Components and Polymer, but in the current stage, i.e. Angular 2.0 alpha, it doesn't work (see this). So you'll have to wait for a while I guess.
I only know one js library and that is jQuery.
But my other coders in the group are changing AngularJS as their default library in new project.
I don't know anything about it. How is it different from jQuery?
I already have a set of functions done for similar tasks in jQuery. Can I still use jQuery stuff with AngularJS?
While Angular 1 was a framework, Angular 2 is a platform. (ref)
To developers, Angular2 provides some features beyond showing data on screen. For example, using angular2 cli tool can help you "pre-compile" your code and generate necessary javascript code (tree-shaking) to shrink the download size down to 35Kish.
Angular2 emulated Shadow DOM. (ref)
This opens a door for server rendering that can address SEO issue and work with Nativescript etc that don't work on browsers.
The official document site
Day one keynote from ng-conf 2016
Resource links
Original:
Basically, jQuery is a great tool for you to manipulate and control DOM elements.
If you only focus on DOM elements and no Data CRUD, like building a website not web application, jQuery is the one of the top tools. (You can use AngularJS for this purpose as well.)
AngularJS is a framework. It has following features
Two way data binding
MVW pattern (MVC-ish)
Template
Custom-directive (reusable components, custom markup)
REST-friendly
Deep Linking (set up a link for any dynamic page)
Form Validation
Server Communication
Localization
Dependency injection
Full testing environment (both unit, e2e)
check this presentation and this great introduction
Don't forget to read the official developer guide
Or learn it from these awesome video tutorials
If you want to watch more tutorial video, check out this post, Collection of best 60+ AngularJS tutorials.
You can use jQuery with AngularJS without any issue.
In fact, AngularJS uses jQuery lite in it, which is a great tool.
From FAQ
Does Angular use the jQuery library?
Yes, Angular can use jQuery if it's present in your app when the
application is being bootstrapped. If jQuery is not present in your
script path, Angular falls back to its own implementation of the
subset of jQuery that we call jQLite.
However, don't try to use jQuery to modify the DOM in AngularJS controllers, do it in your directives.
Update:
Angular2 is released. Here is a great list of resource for starters
I want to add something regarding AngularJS difference with jQuery from a developer's perspective.
In AngularJS you have to have a very structured view and approach on what you want to accomplish. It is scarcely following a linear fashion to complete a task, but rather, the exchanges between various objects take care of the requests and actions, which, then, is necessary as angular is an MVC-Based framework. It also requires an at least general blueprint of the finalized application, since coding depends much on how you want the interactions to be completed.
jQuery is like a free poetry, you write lines and keep some relations and momentum appropriate for your task to be accomplished.
Though, in Angular JS, you should follow some rules as well as keeping the momentum and relations proper, maybe it is more like classical Spencerian sonnet (a famous classical poet) whose poem is structural and tied to many rules.
Compared against AngularJS, jQuery is more like a collection of codes and functions (which is, as already mentioned, great for DOM manipulation and fast-effect achievement), while AngularJS is a real framework which gives the developer the ability to build an enterprise web-application with a lot of data-binding and exchange within a superbly organized-routing and management.
Furthermore, AngularJS has no dependency on jQuery to complete its task. It has two very superb features which are not found in jQuery in any sense:
1- Angular JS teaches you how to CODE and accomplish a goal, not just accomplish a goal by any means. Worth to mention that AngularJS fully utilizes the core and heart of Javascripts and paves the way for you to incorporate in your app, the techniques such as DI (dependency-injection). To work with angularJS you should (or must) learn more elevated techniques of coding with Javascript.
2- Angular JS is fully independent to handle directives and structure your app; you might then simply claim that jQuery can do the same (independence), but, indeed, AngularJS, as several times mentioned within the above lines, has independence in the most excellent possible structurally MVC-Based way.
A last note is that, there is no war of Names, since it is far disturbing to be biased, or subjective. jQuery's magnitude and greatness has been proved, but their usages and limitations( of any framework or software) are the concerns of the discussion and similar debates around.
Update:
Using AngularJS is decisive as it is expensive in terms of implementation, but founds a strong base for future expansion, transformation and maintenance of the application. AngularJS is for the New World of Web. It is targeted toward building applications which are characterized by their least resource consumption (loading only necessary resources from the server), fast response time and high degree of maintainability and extendability wrapped around a structured system.
AngularJS :
AngularJS is for developing heavy web applications. AngularJS can use jQuery if it’s present in the web-app when the application is being bootstrapped. If it's not present in the script path, then AngularJS falls back to its own implementation of the subset of jQuery.
JQuery :
jQuery is a small, fast, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler. jQuery simplifies a lot of the complicated things from JavaScript, like AJAX calls and DOM manipulation.
Read more details here: angularjs-vs-jquery
I think this is a very good chart describing the differences in short. A quick glance at it shows most of the differences.
One thing I would like to add is that, AngularJS can be made to follow the MVVM design pattern while jQuery does not follow any of the standard Object Oriented patterns.
They work at different levels.
The simplest way to view the difference, from a beginner perspective is that jQuery is essentially an abstract of JavaScript, so the way we design a page for JavaScript is pretty much how we will do it for jQuery. Start with the DOM then build a behavior layer on top of that. Not so with Angular.Js. The process really begins from the ground up, so the end result is the desired view.
With jQuery you do dom-manipulations, with Angular.Js you create whole web-applications.
jQuery was built to abstract away the various browser idiosyncracies, and work with the DOM without having to add IE6 checks and so on. Over time, it developed a nice, robust API which allowed us to do a lot of things, but at its core, it is meant for dealing with the DOM, finding elements, changing UI, and so on. Think of it as working directly with nuts and bolts.
Angular.Js was built as a layer on top of jQuery, to add MVC concepts to front end engineering. Instead of giving you APIs to work with DOM, Angular.Js gives you data-binding, templating, custom components (similar to jQuery UI, but declarative instead of triggering through JS) and a whole lot more. Think of it as working at a higher level, with components that you can hook together, instead of directly at the nuts and bolts level.
Additionally, Angular.Js gives you structures and concepts that apply to various projects, like Controllers, Services, and Directives. jQuery itself can be used in multiple (gazillion) ways to do the same thing. Thankfully, that is way less with Angular.Js, which makes it easier to get into and out of projects. It offers a sane way for multiple people to contribute to the same project, without having to relearn a system from scratch.
A short comparison can be this-
jQuery
Can be easily used by those who have proper knowledge on CSS selectors
It is a library used for DOM Manipulations
Has nothing to do with models
Easily manipulate the contents of a webpage
Apply styles to make UI more attractive
Easy DOM traversal
Effects and animation
Simple to make AJAX calls and
Utilities usability
don't have a two-way binding feature
becomes complex and difficult to maintain when the size of a project increases
Sometimes you have to write more code to achieve the same functionality as in Angular.Js
Angular.Js
It is an MVVM Framework
Used for creating SPA (Single Page Applications)
It has key features like routing, directives, two-way data binding, models, dependency injection, unit tests etc
is modular
Maintainable, when project size increases
is Fast
Two-Way data binding
REST friendly
MVC-based Pattern
Deep Linking
Templating
Build-in form Validation
Dependency Injection
Localization
Full Testing Environment
Server Communication
And much more
Think this helps.
More can be found-
jQuery vs. AngularJS: A Comparison and Migration Walkthrough
"Thinking in AngularJS" if I have a jQuery background?
What are the key differences between jQuery and AngularJS?
jQuery Vs AngularJS – A Good Comparison
What is the difference between jQuery and AngularJS?
Jquery :-
jQuery is a lightweight and feature-rich JavaScript Library that helps web developers
by simplifying the usage of client-side scripting for web applications using JavaScript.
It extensively simplifies using JavaScript on a website and it’s lightweight as well as fast.
So, using jQuery, we can:
easily manipulate the contents of a webpage
apply styles to make UI more attractive
easy DOM traversal
effects and animation
simple to make AJAX calls and
utilities and much more…
AngularJS :-
AngularJS is a product by none other the Search Engine Giant Google and it’s an open source
MVC-based framework(considered to be the best and only next generation framework). AngularJS
is a great tool for building highly rich client-side web applications.
As being a framework, it dictates us to follow some rules and a structured approach. It’s
not just a JavaScript library but a framework that is perfectly designed (framework tools
are designed to work together in a truly interconnected way).
In comparison of features jQuery Vs AngularJS, AngularJS simply offers more features:
Two-Way data binding
REST friendly
MVC-based Pattern
Deep Linking
Template
Form Validation
Dependency Injection
Localization
Full Testing Environment
Server Communication