Polymer and Google Blockly

[phil cleaver]

I'm the biggest fan of Google and everything they have done.  Google Blockly and Polymer are my absolute two favourite things that's going on online right now.  Google tells us that with Polymer they have completely reinvented the way the web works, and they have.  What they have done with Polymer is mind-blowingly awesome.  It does away with most of the JavaScript needed to write apps and now you do it all in HTML.

Throw in Firebase, another Google company and they have utterly and completely made all our lives (as long as you're a Web Developer) far far easier.  It's nothing short of genius.

Polymer has been around for 2 years now, Blockly has been around for at least 3 years, so why oh why am I struggling to make these two things work together?  It is completely unfathomable to me that a company with as many resources as it has, a company so ahead of it's time has made 2 completely awesome products, yet has apparently spent no time getting the left hand to talk to the right one, and linking them up.

There is a Blockly Web Component at https://github.com/gmp26/blockly-element.  It kind of works, but there's no data-binding on the workspace, or on the generated code, making it (almost) totally useless for anything serious.  It works when the blockly-element is in regular DOM, but put 2 of them in shadow DOM and see if you can find the workspace xml?  I've spent all in all probably a week of my life trying to get Blockly to work in a web component, and failed  :-(

Google, please stop this ridiculousness, and get someone from the Polymer team to go have a chat with Neil and I'm sure that in no time at all they can have a Blockly Web component working, and everyone who has discovered the wonders of Blockly will discover the virtues of Polymer, and many cool things will come of it.

Fustratingly yours

Phil

[Justin Fagnani]

Hi Phil,

While Google may seem like it has infinite resources to coordinate and build bridges between all of it's projects, it isn't remotely true. Google is a collection of teams and individuals that have their own set of goals and priorities and of course, time limitations, that also fit together within the greater direction of their larger organizations and company. It's simply not feasible for every project to even share the same goals, much less be seamlessly integrated even if they did.

Ultimately, Blockly and Polymer don't necessarily share the same goals or audiences.

Blockly is indeed a cool project, especially as a teaching tool. It's been around even longer than 3 years as part of various project Neil has worked on, and at least I am keenly aware of it and have talked to Neil several times before. Blocky attempts to make syntax errors impossible, and to guide novice programmers towards the discovery of constructs that are compatible with each other. Blockly is still an imperative programming language, just not a text-based one, and while it limits syntax errors it does much less to prevent logic errors. Blockly is also not very well known, not exactly fast to program in for experienced programmers, and not likely to be a popular choice for experienced engineers, nor designers and more general web developers that we target with Polymer, it's mostly targeted at education.

Polymer is not trying to completely replace JavaScript, but to offer an easier way to build custom elements. Our philosophy and methodology include some aspects, like declarative templating and data-binding, that do "replace" imperative programming (this is language-agnostic even) for some focused tasks, but for other tasks programmers still use JavaScript. If you wish you can use a compile-to-JS language like Dart, TypeScript, CoffeeScript, etc., but we by default use the lingua-franca of the web, and feel strongly that this is the productive choice to reach and be usable by the broadest audience.

And so, we have limited resources, we should spend them on things that will be the most useful to the most users in our audience. Right now that includes things like more elements, testing infrastructure, performance tuning, addressing high-demand features in data-binding, styling and layout, modules, etc., and my personal favorite: Polymer Designer. We know there's more to do than that (and it's not an exhaustive list of what we're working on), and if you're frustrated that we haven't done the thing you care about, we're more frustrated that we don't have infinite time.

We are very sympathetic to the idea that programming and building web apps should be easier. It's why we want elements to be usable by non-programmers. It's why some elements simply wrap other APIs to make them usable via markup and data-binding. And it's why we work on Polymer Designer.

If Blockly can be shown to fit well in this world of custom elements, then I'm sure it's something that interested community members can drive, and we would help out as much as we can. I certainly can see how it might be used to build the logic portion of elements.

I'm personally interested in non-imperative logic building for use in Polymer, but my current experiments focus on a non-imperative dataflow programming approach that fits nicely with our data-binding system. If you're interested in that, I'll be sure to announce any interesting developments in the usual places.

Cheers,

  Justin

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/d8fdefb6-5323-445f-85ff-332307192115%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.