We Keep Coding

Web components community polymer web components

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.

Web components - Services / non html components

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.

Migrate backbone to angular 6

Currently, my project is running on backbone js which is a hybrid application. So, I want to migrate the backbone Js application to angular 6 but I need specification Why angular is better than Backbone Js for building a hybrid application.

Okay... I see what you try to achieve here. IMHO As a JS-developer you should be able to answer most of this question by yourself. No framework or toolkit is perfect, neither are Backbone.js or Angular (or PhoneGap / Ionic / React (native) / you call it)! If you want to migrate your app to another language, ask yourself for which reasons you would do so: Do you simply want to learn another language? Or has Backbone.js proven to fail in certain situations/scenarios?
I did a hybrid-app project several years ago only using Backbone.js - and had no problems so far. However, if I would have to do the same job with more complex views, view-transitions, routes and all that mobile-related stuff, I'd probably choose a toolkit that can handle these scenarios much better and with less amount of code - such as Flutter, React native or even native programming. That is why you will first have to assess for yourself what your hybrid-app project really needs. Do you have to deal with heavy data? Then keep on using Backbone.js. Do you need two-way data-binding in forms? Well, that one goes to Angular. Or are parts of your code simply too verbose, un-testable or buggy? Then you should assume refactoring your code as much as possible instead of re-inventing the wheel.
A last word: There have been several discussions in the Backbone.js/Marionette.js community about how to migrate an app to framework xy. As a rule of thumb you should keep in mind that developing NEW components in another language / scripting style is way smarter that re-developing the entire app (which would, as a matter of fact, break a lot of your given business logic and lead to endless nights of doing the same thing over and over).

AureliaJS for long-lasting project

I'm wondering about framework choice, for an app I want to maintain for years. By maintain I mean mainly continious developing and upgrading. My problem is that AureliaJS is more friendly and nice to work with tool, comparing to Angular 4. But the current version of Aurelia is mere 0.32 and I worry that in the future there could be a lot of backward incompatibile editions. Could anyone experienced JS developer advice me with that choice? Thanks in advance.

I'm an Angular Developer, I think Angular is Awesome for long-lasting projects for many reasons
Support: it is supported by Google, It use Typescript as a core language for developing your application which is supported by Microsoft.
Huge Community: Angular has big community at the time of writing this answer Angular repository has 27095 star at GitHub, 497 Contributor while Aurelia has 9984 star and just 88 contributor
Cutting Edge Features: By talking about features Angular follow cutting edge trends in front-end world such as AOT: Ahead of Time Compilation , Universal Angular Apps which implement server-side rendering to increase the performance of angular app and bring SEO to Single Page Application.
Angular CLI: Also Angular has cli (Command Line Interface) which make developer life easy by enable scaffolding new application and make components, services and other stuff easier.
Global Events: Angular has Conferences that take place regularly in many countries.
Used by Big Brands: many big up and running web applications use Angular for their Apps such as Freelancer.com
Used to Develop Multi-Platform App: with Angular you can make web applications, webview mbile applications using Ionic native mobile applications using NativeScript, Cross-Platform Desktop Applications using Electron
Regular Versions: Angular has regular versions every 6 months there is new major version, with backward compatibility with old version
I don't have experience in another modern javascript framework so I can't compare angular with another framework, but I think Angular is a Good Choice for the reasons I have Provided

I'm an Angular and React developer at workplace but I have used Aurelia for my personal projects and i can confidently say that the learning curve is easy and fast compared to Angular
If I had to start a project, Aurelia would be my first choice
I also enrolled in Aurelia course at pluralsight which helped me a lot. Another place to look for is www.danyow.net
I hope that corporations start adopting Aurelia just as much as React and Angular

JavaScript frameworks to build single page applications [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My goal is to migrate an existing web application to a RESTful single page application (SPA).
Currently, I'm evaluating several Javascript web application frameworks.
My requirements are as follow:
RESTful data layer (like ember-data)
MV*-structure
Dynamic routes
Testing-support
Coding by convention
SEO-support
Browser-History-Support
Good (API-) documentation
Production-ready
Living community
Backbone
The current application is using backbone.js. Overall, backbone.js is a nice project, but I'm missing well-defined structures that determine where what has to happen and how things must get implemented. Working in a bigger team with changing developers this leads to some kind of unstructured code, difficult to maintain and difficult to understand. This is why I'm searching now for a framework, that already defines all this stuff.
Ember
I looked into ember.js the last days. The approach seems very promising to me. But, unfortunately, the code changes almost daily. So, I won't call it production-ready. And, unfortunately, we can't wait for it to be version 1.0. But I really like the idea behind this framework.
Angular
Angular.js is a widely spread framework as well, maintained by Google. But I could not get familiar with angular. For me, the structure seems kind of unclear, explanations are missing of the overall responsibilities of each part of the framework, and the implementations feel circuitous.
Just to get this straight: this is just my personal impression and might be based on missing knowledge.
Batman and Meteor
As I understood, both frameworks need a server part as well. And since we just want a RESTful backend - no matter what language, technic or software, this is not what we want. Further, the backend API does already exist (RoR).
Knockout, CanJS and Spine
I did not go any deeper into these three candidates. Maybe this will be my next step.
So my questions now:
Am I missing any good SPA-frameworks?
What framework would you suggest/recommend?
Would you avoid any of the mentioned frameworks?
What is your experience in bigger SP applications?
PS: I'd would like to recommend a great blogpost from Steven Anderson (core developer from Knockout.js) about the "Throne of JS"-conference (from 2012) and javascript frameworks in general.
PS: Yes, I know there are already some question on SO. But since the development is so rapidly and fast for SPAs, most of them are already out-of-date.

I recently had to decide on a JavaScript SPA framework on a project too.
Ember
Looked at Ember early on and had similar thoughts as you about it - I really liked it but it felt like it was still too early to use... about half the tutorials I read didn't work with the current version because something had recently changed in how templating works.
Backbone
Backbone was the first frameworks we seriously looked at. I'm not sure I understand why you think it doesn't have "well defined structures"? Backbone is pretty clear about how to divide up Model and View code. Maybe you mean there's not some kind of app template? Anyway, Backbone seems really focused on the model/REST-binding part, but doesn't really prescribe anything for view binding. If model binding's important to you and you're using Rails it should be a breeze to do this. Unfortunately, the web services for my app didn't really match up, and I had to write my own .sync and .parse methods for everything. The separation of Model and View code was nice, but since we'd have to write all our bindings from scratch it wasn't worth it.
Knockout
Knockout is like the Yin to Backbone's Yang. Where Backbone is focused on the Model, Knockout is a MVVM framework and is focused on the View. It has observable wrappers for JavaScript object properties and uses a data-bind attribute to bind properties to your HTML. In the end we went with Knockout since view binding was mainly what we needed for our app. (...plus others, as discussed later...) If you like Knockout's view binding and Backbone's model bindings there's also KnockBack which combines both frameworks.
Angular
Looked at this after Knockout - unfortunately we all seemed pretty happy with how Knockout did view binding. It seemed a lot more complex and harder to get into than Knockout. And it uses a bunch of custom HTML attributes to do bindings, which I'm not sure I like... I may take another look at Angular later, because since I've come across multiple people who really like the framework - maybe we just looked at it too late for this project.
Batman, Meteor, CanJS, Spine
Didn't really look too closely at any of these. Though I know Spine is a similar framework to Backbone with explicit Controller objects, and is written in CoffeeScript.
Afterword
As I mentioned, we ended up using Knockout because, for our project, focusing on view binding was more important. We also ended up using RequireJS for modularization, crossroads and Hasher to handle routing and history, Jasmine for testing, as well as JQuery, Twitter Bootstrap, and Underscore.js (and probably more libraries I'm forgetting at the moment).
Javascript app development is more like the Java ecosystem than the Rails ecosystem. Rails provides a solid core of stuff you're going to use for every app (Rails framework), and the community provides a lot of customizations on top of that (gems). Java provides... a language. And then you can choose Java EE or Spring or Play or Struts or Tapestry. And choose JDBC or Hibernate or TopLink or Ibatis to talk to the database. And then you can use Ant or Maven or Gradle to build it. And choose Tomcat or Jetty or JBoss or WebLogin to run it in. So there's more emphasis on choosing what you need and what works together than choosing THE framework to use.

it's been a year since we started development on our Cloud services project with numerous SPAs, so it was a big decision, which javascript framework to use for our UI to satisfy our RESTful architecture needs.
and after a lot of researches we ended up using Dojo framework .
main features you'll love:
educated community and a team that came up with a perfect design pattern. great conventions and modular/object-oriented architecture. with CrossBrowser programming attitudes :)
MV* structure. build UI widgets with external .htm templates and for production, build all your javascript & templates into a single, minified and small .js
build classes with inheritance. property setters, a lot of function tools.
pub/sub mechanism (named topics in dojo)
a lot of UI controls, from validation form control, dialogs/tooltips to a heavy featured, highly customizable (but lightweight) chart & data-grid solution.
a good unit test system named DOH. it also have a robot to reproduce mouse/keyboard actions.
a querying tool (like JQuery) named NodeList with all jquery features and even a lot of it's plugins.
and the good but not so complete part. it has a JsonRest module to use with your REST services. its a handy tool but it lacks a lot of features.
to overcome these issues, we developed an AJAX poller, error handling and universal, loading & notifications solution.
we did it very easily using dojo framework conventions and structures.
if you don't want to do that, perhaps you have to use another framework for this part.
looking at great SPAs around the web you'll find out all of them are customized and using multiple frameworks. but our experience with Dojo alone was fantastic. and therefore I suggest you to don't think of any other framework since all of them are incomplete for a SPA. but ultimately you have also another option (which I don't recommend and have no details information on). go with a JAVA framework that is capable of building SPAs, by automatically generating UI & javascript.