
Polymer 2.4: Paving the way for 3.0 and TypeScript support - ergo14
https://www.polymer-project.org/blog/2018-01-25-polymer-2-4.html
======
jondubois
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
In my experience giving your JSON API type information is one of the most
beneficial things you can do to your web codebase.

~~~
jondubois
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
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.

~~~
jondubois
But the schema can change over time with different API versions. So you need
different schemas on the front end for different versions of the API? It just
seems like a lot of hassle when ultimately all you need to do is get a string
property from the API and put it in a textbox.

~~~
bitoneill
Microsoft addressed this and says Typescript is most beneficial to manage
large code bases

~~~
jondubois
I've worked with TypeScript on large code bases. I found that the compile step
becomes really slow and it slows down the debug cycle.

On my last large project, I had to wait 10 to 15 seconds for the code to build
every time I saved the file (and yes the compilation step was optimized to
only include relevant code; a large number of dependencies don't help).

So every time I made a change to the code to check something, I had to wait...
You can't use console.log() to quickly check stuff anymore; the compile
overhead is so significant that you're forced to pull up the debugger and
manually step through the relevant code every single time you want to check
something (you want to get as much info as possible from each debug cycle
because it's so slow).

When writing plain JavaScript, I only pull up the debugger when it's a
particularly difficult bug (e.g. a race condition). For most bugs, I can get
all the information I need with just a couple of calls to console.log() in my
code. The debugger is just unwieldy.

~~~
bitoneill
I used to be a c++ dev so a 15 sec compile time doesn't seem that bad. But
what if you're compiler told you what was wrong faster than your console.log()
could help you find it. I think is a trade off a lot of people want to make.

~~~
jondubois
I agree, that makes sense for C/C++ because working with pointers and dynamic
memory is a lot more complicated - Types make sense for C/C++ because the
focus is execution speed and flexibility (not development productivity).

The case you describe very rarely happens to me with JavaScript; having fewer
primitives to work with greatly reduces these kinds of issues... Sure it opens
up the possibility that you'll do something stupid like trying to add an
object with a string; but that's a pretty silly thing to do. If you name your
variables properly then that never happens.

With C/C++, there are many primitives so you might get errors when you try to
assign an int64 to an int8 (for example)... With JS, however, because there
are fewer primitives so the odds of that happening are much much smaller.

Because there are so few primitives in JS, it's easy to remember how they all
interact with each other. The only exception is the boolean truth table for
'==' (which is a mess); that's why it's usually recommended to use '==='
instead.

------
floatboth
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
It will get fixed - modulizer is still being worked on, and some elements are
not being converted correctly as far as I can tell.

------
aphextron
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
Well you can do `polymer-redux`, `polymer-uniflow` or mixins
([https://www.captaincodeman.com/2017/07/06/managing-state-
in-...](https://www.captaincodeman.com/2017/07/06/managing-state-in-
polymer-20-beyond-parent-child-binding)).

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
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
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
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.

------
ZenoArrow
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
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
Thanks for the advice.

------
coding123
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.

