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.
Related
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 8 months ago.
Improve this question
We have an large application spread across multiple teams, built with Java Server Pages. The goal is to migrate to Angular. A monolithic migration/launch was deemed not practical, so a gradual migration is preferred.
The idea is to use a Webpack 5 Module Federation app shell to load Angular micro frontend remotes into the existing JSP app. The question is whether to load the remotes as Angular apps or Web Components. The thought is that Web Components might allow them to embed a reusable microfrontend fragment into the JSPs in cases where they can't migrate an entire page at once, or they have components that will exist in both the unmigrated JSPs and the new Angular pages.
After the migration, they'll either keep the micro frontend architecture if it's justified, or abandon it and merge the remotes into one Angular app.
Another alternative might be lazy loaded modules rather than opening the pandora's box of micro frontend architecture. Just informally split the app up into lazy loaded modules per team. Downside here is possibly more teams stepping on each others toes in the repository, but that's no different than how they've been operating. Their concern about lazy loading modules is they don't think they'll be able to do something like this:
<!-- my ancient JSP site. LOL page load with every click -->
<JSP-header></JSP-header>
<myAngularComponent></myAngularComponent>
<script type="text/javascript" src="https://lawlcats.com/myAngularComponent.js"></script>
<JSP-footer></JSP-footer>
All in all, the proposed solution is incredibly complex. These teams are brand new to Angular and are already considering combining different frameworks within a micro frontend architecture, AND implementing web components. Sounds like a huge lift to me. I'm also unsure if they've considered how they'll manage the repository across teams.
Does anyone see room for improvement or flaws in this plan? I'd love suggestions for the micro frontend remotes being Angular vs Web Components, vs abandoning micro frontends altogether in favor of lazy loaded modules.
Well, it would be good if your team first fully grasped what are the implications of MFEs or WebComponents as tools.
Micro Frontends are self-contained, stateful, full-fledged, and fully black-box applications. Maybe it would help your team to think about them as iframes.
You stick a MFE app somewhere on your page, and that is it. It does its own thing. The host app just hosts all the MFE apps on all the different http ports, but it doesn't know anything about what's going on inside of them.
In the simplest classic example, there is no communication between the host and the apps, and the apps also never ever talk to each other. AFAIR, if you wanted them to communicate, it's theoretically possible to do that via http (since they do actually live on specific ports), or wild shenanigans like utilizing LocalStorage. But it's generally not easy.
WebComponents, on the other hand, are just raw components that do one specific thing. They are also black boxes, but usually super tiny and thin. You can think of them as something like input.
An input knows how it should be styled, it knows which raw browser Web APIs it should talk to, it knows that it should render text in response to the user typing on their keyboard, and how to expose a couple values and events to the external world. But ultimately, an input in itself is pretty dumb and can hardly be called an "application". It's just a small building block of the actual modern JS app.
inputs also don't talk to each other - why would they - but they expose clear, native html APIs for input and output, so the host app can very easily talk to them and make use of them. The host is still responsible for actually knowing how to do that though.
As for your use case, your options depend on your team's technical and business needs.
MFE Federation is a pretty strictly defined type of architecture. It might work in your use case, but you'll need to consider that trying to organize any kind of communication between these separate apps later on is asking for trouble.
On the other hand, if you really want to just have a bunch of modern JS components that you could stick anywhere in your existing JSP code, then WebComponents might be your best bet. IIRC, Angular components can be built and used as WebComponents like in your example, so it could be viable to write them in Angular (and then possibly migrate the entire app to an actual Angular SPA sometime later). The problem is that these components won't do anything by themselves, they still need the host page to actually use them.
It might also viable to write just one application with a bunch of lazy-loaded modules - which the standard straightforward case in modern Angular - and let it live under some specific routes. You would then just start rewriting pages in Angular one by one. Nobody likes that, but sometimes it's just what has to be done. As an upside, in that case at least you would have an actual modern Angular app as the host for all the JS components, instead of whatever JSP thing you currently have.
In theory you can mix-and-match approaches 2. and 3., with some pages only partially using the new shiny WebComponents, and some pages fully rewritten. It's probably what will have to eventually happen, but I'd try to initially stick to just 2 or just 3, to make the first steps of the migration simpler for your inexperienced devs.
Whether you choose Webpack MFE Federation, JS/Angular WebComponents, or a simple Angular SPA, I would strongly recommend looking into NX, which is a very powerful, framework-agnostic JS monorepo toolset. Among other features, it should help you solve the problem of managing the code between teams.
With NX, you can add arbitrary tags to all of your modules, and make the linter track and ban the dependencies between specific tags. As a simple example, your could say that modules tagged team-a cannot be used by team-b or team-c, so that Team A can safely do whatever they want in them without breaking anything that other teams actively use.
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.
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.
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).
I have a performance issues with Angular (as many others). I wish to change only the view layer to either reactjs or Mithril. I found examples of React js (for example http://www.bimeanalytics.com/engineering-blog/you-put-your-react-into-my-angular/), but not of Mithril.
Can anyone advice to the pros and cons of using Mithril as an angular view vs Reactjs?
Thank you!
I don't think there's an objective answer here, and as a Mithril user I have my biases, but here is what I think.
In terms of philosophy, Mithril and React are quite similar: you write view functions that describe how your app should look at any given time. In terms of rendering performance, I don't think there's a clear winner. There are links / blog posts that say Mithril is faster than React, and vice versa.
So instead what I think you should focus on is:
1) Which API do you prefer? With React you should use JSX lest you have to reverse engineer their documentation. Mithril also just has one lifecycle hook (the view function), whereas React has several (such as shouldComponentUpdate) -- do you need all those hooks?
2) Community support -- React is the clear winner here, and the fact that there are existing examples of integration with Angular is a win.
3) Compatibility - DOM redrawing / diffing in React is done when data changes, just like Angular, but Mithril's redraw is centered around user interaction (such as clicks, route changes, ajax requests). You can manually redraw, but that's less desirable. I don't know how well Mithril will fit into an Angular setup.
Should you decide to use Mithril, I'd encourage you to use the Google group (https://groups.google.com/forum/#!forum/mithriljs) as a resource, or at least report back on your experience.
Mithril and React have many similarities. I've used both of them and here are some pros and cons.
Mithril
Pros: It's loading times are very fast. This is because it's templates are compiled first and then served to the browser. You can write Mithril views in JavaScript. Small size, good documentation and doesn't force you into a predefined structure.
Cons: Small API can make it unsuitable for larger more complex projects.
ReactJS
Pros: React's one-way data binding means that it's easy to see where and how your UI is updated and where you need to make changes. It also provides server-side rendering, virtual dom support, good debugging tools, easy to write tests, easy to reuse components, flux architecture patterns, and extensive SVG supports etc.
Cons: Heavy on memory compared to Mithril, not a complete solution as it mainly focuses on the view, and need to learn a new syntax etc.
In my view, React is overall preferable. But, if your application doesn't need all these extra stuff that React provides, you should go with Mithril.