My Naive Thoughts On Polymer 2, And The Google I/O 2017 Presentations

108 views
Skip to first unread message

Nick Pavlica

unread,
May 26, 2017, 4:08:20 PM5/26/17
to Polymer

All,

 After watching multiple presentations from Google I/O 2017 on Polymer 2, I was struck with an oppositional view of the “adopt the platform” mantra that the presenters were espousing.  While reflecting on this reaction for a couple of days, I couldn’t help but reminisce of days gone buy in this industry.  It feels as though we keep reinventing the same wheel, and expecting a different result.  For those of us that have been around long enough, we remember the failures of the past, and why they failed.  Specifically, I’m thinking of Java Applets, and all the time I wasted writing them.  While watching the presentations, I couldn’t help but notice the almost constant promotion of ES6 classes, and their use within Polymer 2.  I also couldn’t miss the constant assumption that this will be the standard, that should be adopted.  The more I thought about these annoyances, the more they continued to bother me, and it makes me question if our industry will every make any real progress, and move past a single set of ideas.  Here are some very basic examples to help highlight my point:

 

A Basic Java Applet

 

import java.applet.Applet;
import java.awt.Graphics;

public class HelloWorld extends Applet {
   public void paint(Graphics g) {
       g.drawString("Hello world!", 50, 25);
   }
}

<HTML>
<HEAD>
<TITLE> A Simple Program </TITLE>
</HEAD>
<BODY>

Here is the output of my program:
<APPLET CODE="HelloWorld.class" WIDTH=150 HEIGHT=25>
</APPLET>
</BODY>
</HTML>

 

A Basic Polymer 2 Component

 

<link rel="import"  href="https://polygit.org/components/polymer/polymer-element.html">

<script>
 // Define the class for a new element called custom-element
 class CustomElement extends Polymer.Element {
   static get is() { return "custom-element"; }
   constructor() {
       super();
       this.textContent = "I'm a custom-element.";
     }
 }
 // Register the new element with the browser
 customElements.define(CustomElement.is, CustomElement);
</script>

 

<!DOCTYPE html>
<html lang="en">
 <head>
   <script src="https://polygit.org/components/webcomponentsjs/webcomponents-loader.js"></script>
   <link rel="import" href="custom-element.html">
 </head>
 <body>
   <custom-element></custom-element>
 </body>
</html>

 

 

These feel eerily similar to each other don’t they?  I can’t help but think that a certain style off code, primarily a certain form of OOPs is once again being forced on the developer.  Each time the presenters proudly proclaimed we use ES6 classes with inheritance and everything;  I couldn’t help but cringe, then follow it with a little chuckle.  I mean really, we were doing this two decades ago.  With the ever increasing awareness of functional programming styles and their benefits, it’s a little frustrating to feel like the “platform” is forcing or promoting one style without an obvious open door to other styles.  A monolithic conceptual paradigm will certainly result in a false barrier to innovation, and will force the creation of even more abstractions over the “platform”.  

 

This just makes me want to stay as far away from Polymer and web components as I can, which I know isn’t the intention, but is the side effect of the message that was being presented.  I’m certain that I’m not alone in the assumptions that I’ve made, and that negative feelings that were inadvertently created as a result of these presentations.   I’m sure that I’ve missed many of the finer details, and I’m probably wrong on all accounts;  However,  I would love to learn how the Polymer team, and the standards committees are planning to interoperate, and even accommodate some of the ideas from Purescript, Elm, ClojureScript, and others.  At the end of the day it’s still all just some form of JS, but I’m fearful that the tech community will continue to recreate Java over and over again without regard to other advancements and ideas.  

 

Many Thanks!

-- Nick


Bruce Anderson

unread,
May 26, 2017, 5:15:59 PM5/26/17
to Polymer
Hi Nick, I'm a fellow developer, not part of the Polymer team.  My first foray into a production web app involved applets.  Glad we've moved on :-)

But I don't think applets fell out of favor because they used classes.  That was the one aspect I've missed all these years, until recently.  They were problematic in terms of performance, being confined to a rectangle, blurry printing, needing to compile a complex, proprietary language when JavaScript could do the same thing almost as fast, with a much lower learning curve, etc.  And just not being "of the web" in the best sense, but controlled by one vendor (who famously went after another vendor for daring to ship their own version of it).

Most functional languages including F#, Scala, Haskell have classes.  Nothing is forcing you to make your classes have mutable members.  

I've seen examples of custom elements built with Elm, for example.  You might also look at SkateJS, if you have a strong aversion to OOP.

Nick Pavlica

unread,
May 26, 2017, 6:21:36 PM5/26/17
to Polymer
Hi Bruce,
  Thanks for helping me better understand Polymer!

Hi Bruce,
  Thanks for helping me better understand Polymer!


On Friday, May 26, 2017 at 3:15:59 PM UTC-6, Bruce Anderson wrote:
Hi Nick, I'm a fellow developer, not part of the Polymer team.  My first foray into a production web app involved applets.  Glad we've moved on :-)

But I don't think applets fell out of favor because they used classes.  That was the one aspect I've missed all these years, until recently.  They were problematic in terms of performance, being confined to a rectangle, blurry printing, needing to compile a complex, proprietary language when JavaScript could do the same thing almost as fast, with a much lower learning curve, etc.  And just not being "of the web" in the best sense, but controlled by one vendor (who famously went after another vendor for daring to ship their own version of it).

  Classes, definitely weren't the cause of applets demise for sure :)   I was a huge Java/OOP zealot for years, and still have a copy of the "Object Oriented Thought Process" on my book shelf. Part of the point that I was trying to make, is that the OOP style isn't the only valid method of creating software, and we shouldn't always be pushing in that direction.  The Polymer team/project are always talking about standards and the platform which makes me concerned that they aren't taking the other approaches into account.  This assumption is probably totally wrong, but it's the perception that I get from the docs, and the presentations that I've seen. 

 

Most functional languages including F#, Scala, Haskell have classes.  Nothing is forcing you to make your classes have mutable members.  

   In a way, this helps clarify why I think that it's important to have, and encourage multiple styles.  There are pros and con's to each and we should be allowed to use the one we want or need to.
 
 
I've seen examples of custom elements built with Elm, for example.  You might also look at SkateJS, if you have a strong aversion to OOP.

  I've seem some of the Elm stuff, but haven't looked into SkateJS yet. 


Thanks again for the feedback!
-- Nick
 

Karl Tiedt

unread,
May 26, 2017, 6:34:09 PM5/26/17
to Nick Pavlica, Polymer
How best would you develop a collection of extendable components while avoiding classes? Even 10 years ago libraries rolled their own class systems... Should we avoid the platform way of doing inheritance and extensibility just because? Everything you have alluded to in the past is all making do with what was available at the time... 

ES6 is what's available from the platform... With that being said, your aversion to it is confusing... I will agree that the "module" system that landed in ES6 is by far not the smartest choice but it's what the lovely standards committee gave us...

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/fc2c20e0-c690-4f8c-935f-b5ffec21d428%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nick Pavlica

unread,
May 27, 2017, 9:59:42 AM5/27/17
to Polymer, lin...@gmail.com
Hi Karl,
  The first rule of tech, is that we will never agree on anything :)

On Friday, May 26, 2017 at 4:34:09 PM UTC-6, Karl Tiedt wrote:
How best would you develop a collection of extendable components while avoiding classes?

  Honestly, I don't believe that anyone can answerer this, they can only work within the bounds of what they know, or whats forced upon them.
 
Even 10 years ago libraries rolled their own class systems...

   They were/I was doing it allot longer than 10 years ago... But I get your point, it's a style that works for many, and shouldn't be ignored.  However, I don't believe that we can should ignore other approaches, and should try to accommodate them when and where it's possible.
 
Should we avoid the platform way of doing inheritance and extensibility just because?
Everything you have alluded to in the past is all making do with what was available at the time... 

  No, we shouldn't ignore the platform, but we should also try to incorporate new ideas.  As I pointed out in the code above, there is little to no real innovation in Polymer and web components, with the exception that there are multiple vendors this time.  From the perspective of someone that's been doing this far too long, it just starts to feel like ground hog day. 

 

ES6 is what's available from the platform...
With that being said, your aversion to it is confusing...


  I don't know what's confusing about it.  ES6 is barley brining the language to a level of what was available decades ago, and it still has a Long way to go.  Thankfully things are starting to move forward, in ES, and other languages that give us some choice.

 
I will agree that the "module" system that landed in ES6 is by far not the smartest choice but it's what the lovely standards committee gave us...

 
  I think that Anders Hejlsberg did a great job in his presentation this year at MS Build, where he talks about how Typescript fits into the multi-paradigm hybrid thing that's Javascript/ES whatever.  He describes the use of classes in Typescript, but then reveals that the typescript compiler is actually written in a functional approach.  It's definitely worth the watch. 

  https://www.youtube.com/watch?v=d1f6VBmWg6o

If you haven't seen Rich Hickeys talk on Simplicity, it's a great watch, and may help clarify some of my thinking.

  https://www.youtube.com/watch?v=rI8tNMsozo0&t=11s
 
Regards!!
-- Nick

 

To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

Bruce Anderson

unread,
May 27, 2017, 10:00:14 AM5/27/17
to Polymer
Hi Nick

I totally relate to your point about the desire to accommodate different styles of development.  Actually, this is what really excites me about web components -- that, even within an application, we can integrate components from different teams or individuals together, and not give a hoot what lies under the hood, as far as programming philosophy.  I think it's fair to say that the Polymer team share this view, but they do recommend a few key steps to make components work everywhere in harmony.  I think those recommendations can accommodate both functional and OOP approaches.

It's great that we can have budget cars, electric cars, vans, etc, using whatever innovative approach the manufacture comes up with.  But it is helpful that the brake is always to the left of the accelerator, and that roads have lanes.  :-)

I view Polymer as a reference implementation, one cohesive way of making the disparate platform standards work together.  Ultimately, that means making some choices, adopting a philosophy.   But I think the driving force behind their efforts is to allow us more choices and innovation, rather than having to buy into large monolithic frameworks. 


Bruce
Reply all
Reply to author
Forward
0 new messages