I know that polymer is primarily used to create reusable elements, and angular is supposed to be used to create web apps (at least from a “high level” perspective), but I wonder, since you can wrap your own “Screens” as polymer elements, which actually could serve as controllers too, and switch the active page with the iron-pages element (see SPA demo), and you can also use more-routing well… instead of “routing by code”, it supports one/two way binding and events, I’ve actually done some small SPA app like that myself, and so far so good actually! moving on-
Assuming I don’t care about having some built-in REST wrapper such as the one provided by Angular (Easy to roll up my own if I use Dart), then in Dart’s case:
- Could polymer actually be used to create full apps?
- Would it have any implications in performance if my whole app is in polymer? by that I mean, every screen is really an element, and so on.
- Development speed, maintainability, and experience? (considering the fact that I use Dart which helps a lot in these areas)
- Overall, is it a good idea? I’d like to know your opinions.
- Any companies/indie devs have done this before? not necessarily with Dart, but with TypeScript/JS as well, although I’m 100% set on Dart.
I think Polymer is quite a good fit for that. I wouldn’t necessarily go for “a Polymer element per page” but that might depend on the kind of application you are going to build. Especially in Dart Polymer it’s a good start to make the root Element a Polymer element. You can for example keep the navigation and switch only a part of the view instead of the entire page (but that might be what you had in mind anyway)
You can also use dependency injection, which is a strong point of Angular.
The dirty checking might be better in Angular 2 but Angular isn’t released yet and Polymer also has plans to improve here.
Answered By – Günter Zöchbauer
Answer Checked By – David Marino (FlutterFixes Volunteer)