8 ms·

Polymer 2.4: Paving the way for 3.0 and TypeScript support

43 points by ergo14 9y ago

westbrook 9y ago
I've already upgraded some of my extensions to the tagged template literal syntax. It's so much nicer than what I was working with before, and is tiding me over for IE11 support in lit-html. Pretty big wins all around. Next, I'm gonna have to take a deeper look at those TS decorators!
- 52-6F-62 9y ago
  I don't really work in Polymer (usually React) but just the same you might appreciate my favourite and most-abused decorator: https://github.com/andreypopp/autobind-decorator https://github.com/andreypopp/autobind-decorator
  - westbrook 9y ago
    That's a great one. It's a big part of my TC39 reading: https://github.com/tc39/proposal-decorators#decorators https://github.com/tc39/proposal-decorators#decorators Very exciting.
coding123 9y ago
This is great news for Polymer - I can't wait to try out 3.0 when it's ready :) Typescript is indeed a favorable target for their existing audience.
aphextron 9y ago
Can anyone reccomend a good state management scheme for building large scale Polymer apps? My team has gone this route of building small custom elements for everything, but getting them to communicate has been a pain. AngularJS solved that really well I think with $broadcast and $emit, but we'd rather stay away from monolithic frameworks.
- ergo14 9y ago
  Well you can do `polymer-redux`, `polymer-uniflow` or mixins (https://www.captaincodeman.com/2017/07/06/managing-state-in-polymer-20-beyond-parent-child-binding https://www.captaincodeman.com/2017/07/06/managing-state-in-...). I went with redux. You could I guess technically you could implement $broadcast - but that would be slow same as with angular, as for $emit you can just emit standard events.
- westbrook 9y ago
  This could also be of benefit to your research: https://gist.github.com/kevinpschaaf/995c9d1fd0f58fe021b174c4238b38c3 https://gist.github.com/kevinpschaaf/995c9d1fd0f58fe021b174c...
ZenoArrow 9y ago
I like the idea of writing Web Components with TypeScript. Are Web Components (or the frameworks pushing it forward) good enough for production use? Any issues worth considering before diving in?
- westbrook 9y ago
  I've used web components in production in two different companies and in a number of personal projects, so I'd say so. The move to official TS support is brand new, so you might catch some turbulence in that area. Polymer generally is about to make the move from 2.x to 3.x, so there could be some issues there. However, you can work with 3.x code now, and the official release should be in the next month or two, so getting started now might be just the right time.
  - ZenoArrow 9y ago
    Thanks for the advice.
jondubois 9y ago
Polymer is my favourite front end framework. I hope it doesn't start forcing developers to use TypeScript because then I'd have to stop using Polymer. TypeScript is not suitable for building the vast majority of web UIs; it just makes things way more complicated (with the added build step, source-mapping issues, missing type definitions, outdated type definitions...) and adds no value beyond improved code completion and compiler warnings (and those two are conveniences at best). Web applications are centred around APIs. APIs use JSON... JSON doesn't have types; so already there is an obvious impedance mismatch! It makes no sense at all whatsoever that the front end logic should be more strict than the API! As far as the front end is concerned, the API is the one source of truth; so unless you're willing to go back to the old days of SOAP and also start adding type annotations to your transport protocol then it makes no sense whatsoever to use TypeScript. The main exception I can think of are web-based games; in this case it's possible that most of the complexity is actually on the front end itself (and not in the data integration aspect).
- hazza1 9y ago
  In my experience giving your JSON API type information is one of the most beneficial things you can do to your web codebase.
  - jondubois 9y ago
    To some extent, but there is a difference between giving each object a type property (which is open to interpretation by the client app) vs forcing the client to adhere to rigid type definitions/constraints (which make it more difficult for the client to actually use the API). Developers who have used SOAP before will remember what that's like.
    - ascorbic 9y ago
      The client has to adhere to the shape of the JSON that the API is generating anyway. Defining those types just makes it easier to avoid mistakes. There's no reason that need to be any more rigid than the API would otherwise be.
floatboth 9y ago
I wish they actually focused on 3.0 more. This "auto generated from 2.x" thing is pretty bad — paper elements that depended on neon-animation just don't work in 3.0: https://github.com/PolymerElements/paper-dialog/issues/156 https://github.com/PolymerElements/paper-dialog/issues/156
- ergo14 9y ago
  It will get fixed - modulizer is still being worked on, and some elements are not being converted correctly as far as I can tell.

43 points by ergo14 9y ago

I've already upgraded some of my extensions to the tagged template literal syntax. It's so much nicer than what I was working with before, and is tiding me over for IE11 support in lit-html. Pretty big wins all around. Next, I'm gonna have to take a deeper look at those TS decorators!

52-6F-62 9y ago
I don't really work in Polymer (usually React) but just the same you might appreciate my favourite and most-abused decorator: https://github.com/andreypopp/autobind-decorator https://github.com/andreypopp/autobind-decorator
- westbrook 9y ago
  That's a great one. It's a big part of my TC39 reading: https://github.com/tc39/proposal-decorators#decorators https://github.com/tc39/proposal-decorators#decorators Very exciting.

coding123 9y ago

This is great news for Polymer - I can't wait to try out 3.0 when it's ready :) Typescript is indeed a favorable target for their existing audience.

aphextron 9y ago

Can anyone reccomend a good state management scheme for building large scale Polymer apps? My team has gone this route of building small custom elements for everything, but getting them to communicate has been a pain. AngularJS solved that really well I think with $broadcast and $emit, but we'd rather stay away from monolithic frameworks.

ergo14 9y ago
Well you can do `polymer-redux`, `polymer-uniflow` or mixins (https://www.captaincodeman.com/2017/07/06/managing-state-in-polymer-20-beyond-parent-child-binding https://www.captaincodeman.com/2017/07/06/managing-state-in-...). I went with redux. You could I guess technically you could implement $broadcast - but that would be slow same as with angular, as for $emit you can just emit standard events.
westbrook 9y ago
This could also be of benefit to your research: https://gist.github.com/kevinpschaaf/995c9d1fd0f58fe021b174c4238b38c3 https://gist.github.com/kevinpschaaf/995c9d1fd0f58fe021b174c...

ZenoArrow 9y ago

I like the idea of writing Web Components with TypeScript. Are Web Components (or the frameworks pushing it forward) good enough for production use? Any issues worth considering before diving in?

westbrook 9y ago
I've used web components in production in two different companies and in a number of personal projects, so I'd say so. The move to official TS support is brand new, so you might catch some turbulence in that area. Polymer generally is about to make the move from 2.x to 3.x, so there could be some issues there. However, you can work with 3.x code now, and the official release should be in the next month or two, so getting started now might be just the right time.
- ZenoArrow 9y ago
  Thanks for the advice.

jondubois 9y ago

Polymer is my favourite front end framework. I hope it doesn't start forcing developers to use TypeScript because then I'd have to stop using Polymer. TypeScript is not suitable for building the vast majority of web UIs; it just makes things way more complicated (with the added build step, source-mapping issues, missing type definitions, outdated type definitions...) and adds no value beyond improved code completion and compiler warnings (and those two are conveniences at best). Web applications are centred around APIs. APIs use JSON... JSON doesn't have types; so already there is an obvious impedance mismatch! It makes no sense at all whatsoever that the front end logic should be more strict than the API! As far as the front end is concerned, the API is the one source of truth; so unless you're willing to go back to the old days of SOAP and also start adding type annotations to your transport protocol then it makes no sense whatsoever to use TypeScript. The main exception I can think of are web-based games; in this case it's possible that most of the complexity is actually on the front end itself (and not in the data integration aspect).

hazza1 9y ago
In my experience giving your JSON API type information is one of the most beneficial things you can do to your web codebase.
- jondubois 9y ago
  To some extent, but there is a difference between giving each object a type property (which is open to interpretation by the client app) vs forcing the client to adhere to rigid type definitions/constraints (which make it more difficult for the client to actually use the API). Developers who have used SOAP before will remember what that's like.
  - ascorbic 9y ago
    The client has to adhere to the shape of the JSON that the API is generating anyway. Defining those types just makes it easier to avoid mistakes. There's no reason that need to be any more rigid than the API would otherwise be.

floatboth 9y ago

I wish they actually focused on 3.0 more. This "auto generated from 2.x" thing is pretty bad — paper elements that depended on neon-animation just don't work in 3.0: https://github.com/PolymerElements/paper-dialog/issues/156 https://github.com/PolymerElements/paper-dialog/issues/156

ergo14 9y ago
It will get fixed - modulizer is still being worked on, and some elements are not being converted correctly as far as I can tell.