If I look at the polymer shop I am instantly sold on wanting to use this as a starter for my web shop. Not just because it's already a web shop (full pwa technology) but because it has excellent (offline) experience on browser/mobile, has proper documentation and is still maintained.
But then look at the polymer home page and see the project is based on an outdated polymer version and even the fact that it's using polymer in the first place is curious:
The Polymer library is in maintenance mode. For new development, we recommend Lit.
So my question is if lit will have the rich choice of web components that the shop seems to be depending on?
This may be a dumb question but I skipped polymer other than looking at some exciting news in google IO
The goal of Lit, and of Polymer before it, is to help build web components and applications using browser features as much as possible.
For instance jQuery wrapped all the different browser features in it's own syntax, to the point where developers were learning jQuery, rather than Javascript. jQuery components assume that you have jQuery and rely on those jQuery methods to function.
Both Lit and Polymer championed web components - this makes each component much more self-contained. Using a mix of jQuery and any of its competitors was really painful, but that isn't the case here.
All the components used to build that shop are stable and still on npm. You can use them if you want and I have live applications that still use them.
However, championing the latest browser features has its risks. Polymer relied heavily on HTML Imports (that only Chrome ever implemented and were ultimately dropped) and its own template library. It was ultimately ported to ES6 modules, but the core design is far less suited to it. Those components are pretty stable, but you don't really want to start anything new with it.
Lit is quite a lot less opinionated than Polymer, and much lower level. For instance Polymer supported two way binding with {{property}} syntax, but had to make assumptions (that often broke) about what you were doing to support it. Lit drops that for extremely stable property setters but if you want to users to write values you have to subscribe to events and roll that yourself (Lit does make events very easy to manage though).
So if you're going to build your own web components or application Lit is by far the better choice, and LitElement is lightweight and extremely compatible with everything else. You can use those Polymer shop components in Lit (I have) but for most of them there are newer alternatives, in particular MWC.
Is Web Components give better performance when compared to Native HTML elements. Since each elements getting mutated only when getting attached to DOM. So, expensive operations inside Element callbacks leads to poor performance.
I wrote one sample Web Component with some expensive implementation in connectedCallback handle, When I try render the component, each component took time in a consecutive order.
I don't see any reference related performance pin points on Web Components.
Update 1
I have a created small page with Native and Web Component implementation, Seems Web Components page took 4ms to finish but Native took only 1ms. Refer my Performance screens. In Web Components scripting is taking more time.
Native HTML Example:
Web Component Example:
Since Custom Elements are extending native HTML elements (through class extends HTMLDivElement), with extra features added, I would say: in the best case, they can only be as good as native HTML elements.
The gain in performance is when compared with 3rd party frameworks (that don't leverage this new technology): Web Components should be faster.
You can see it when comparing native vs polyfilled Custom Elements implementations.
You can greatly improve the performances of your web component using StencilJS (github). It will do a lot of optimisation work pretty easily, as well as implementing a Virtual DOM to your web component for an optimal rendering.
You can check the performances here.
I am thinking if you just plainly do a simple "Hello World", of course Native Elements will be the winner because it doesn't need JS to work while Custom Elements will need JS to define and startup the rendering of the text.
Now, a better comparison is when, let's say, using the same code base, you create a carousel using JS and Native elements only, and a custom element that is a carousel. Then I think rendering performance would be equal. The only advantage I can think of on using custom elements rather than manipulating a native element via JS is that you can reuse the custom tag anywhere and it will work as a carousel, rather than when you have to use new Carousel(document.querySelector('.carousel')) on every carousel div that you created using only native elements.
Native HTML Elements will always be the winner, since Web Components are implementing them, which adds an extra layer of "complexity".
I personally don't think Web Components are introduced to outperform Native HTML Elements (you can say the same for Js Frameworks like Angular, React & Vue). I think they're made for convenience and to make the life of developers much easier. Since we're writing code for humans and in the second place computers, an important aspect of web development is readability, which improves enormously with Web Components.
IMHO a better comparison between Native HTML Elements and Web Components will be the extent to which it supports developers to write more readable code and be more productive.
I know it is bad practice to have the DOM manipulation in anywhere other than directive. but I do not understand why is it a bad practice to have the DOM manipulation in the service/factory as we can reuse them.
I have searched online and also found the same question on stackoverflow
stackoverflow question
but still not clear with the answers.
Angular follows declarative principle which means
a style of building the structure and elements of computer
programs—that expresses the logic of a computation without describing
its control flow
At the same time services in angular were introduced to contain business logic. If business flow is complex - imperative approach suites better.
In such a way if you have DOM manipulation in the service you probably violate separation of concerns principle, as you are coupling UI and business layers. And coupling itself eventually ends up in spagetti-code when this "reusable" components (according to new requirements) should look a bit different in the modules where they were integrated
Directives, by definition, are always attached to a DOM node. So when we create a directive, it either expands or replaces the DOM node.
services are engaged with directives so we are able to manipulate view of an app through directives. however, there are cases where you might need to manipulate DOM element(s) via a service, like in a modal window.
I have a rule of thumb for situations like this. can DOM manipulation be done directly with the attached node? and answer to this question tells me if I need to use a directive (yes) or a service (no) but overall it depends on complexity of your project as well.
I'm confused by the "componentization" of the web UI. If I have a need for a component, should I write my own jquery-ui plugin or should I write, if I use Backbone.Marionette, a MarionetteComponent ?
Both are be reusable, isolated unit of view and behaviour. So they are conceptually fighting and compete at same level.
So I don't actually see when to create one or the other. jQuery seems to be more universal, but developers tends to write MarionetteViews/Component.
If you want to use your ui component in most possible situations you could do your component without coupling with neither jquery-ui or backbone view.
If you want to make your component more future proof (yes I'm a dreamer) you can do it generic, and you can try to implement it with AMD, CommonJS or ES6 Module syntax. check for example https://medium.com/#brianleroux/es6-modules-amd-and-commonjs-c1acefbe6fc0
The advantage of this is that anyone can use it with React, Angular, [put here other future framework] or vanilla JS.
And if you want to make easier for others to implement, you can add as well the code that wraps your component to integrate with those frameworks, libraries, etc.
I am not very familiar with Backbone but as I remember this is architectural framework which should give you guidelines how to structure your code into views, controllers, components and other useful services.
On the other side there is jquery library which main purpose is to abstract the operations on the DOM so that the browser specifics can be hidden and easier interface is provided. Of course jquery has a lot more useful primitives but it doesn't say how to structure your code.
If you have decided to use Backbone you should write your components as MarioneteComponents so that they fit nicely into Backbone. Even if you write it as jquery component (or you need to use already existing component) you can create wrapper for Backbone but this is additional work.
If you want to make truly reusable component you should write it using vanilla js. After that everyone can make wrapper which will adapt it for the specific framework.
Hope this helps.
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