5 ms·

I've tried most of the major frontend JavaScript frameworks. My favourite one is Google's Polymer framework - I like it specifically because it is very lightwei

I've tried most of the major frontend JavaScript frameworks. My favourite one is Google's Polymer framework - I like it specifically because it is very lightweight, easy to setup, easy to integrate into existing projects and it's ideal for building complex single-page apps. The best thing about Polymer is that, unlike React, it works with W3C standards instead of going off on a tangent and hacking the DOM entirely. It extends current HTML5 standards instead of creating its own universe. With Polymer, each component has its own mini-DOM which is actually a real DOM - Not the virtual layer you get in React which keeps overwriting the real DOM. Unlike Angular, Polymer gives you a lot of control when it comes to how data flows throughout your app. Because of this, there are a few different component-level configs that you need get your head around. For example, by default in Polymer, data only flows downwards to child components, you have to enable a special 'notify' attribute to allow data to flow upwards to parents (this is different from Angular where data flows freely wherever there is a placeholder for it in your DOM). I think React has been getting way too much hype. Polymer, on the other hand, is ridiculously under-hyped. Of those people I know who used both React and Polymer, all of them preferred Polymer. I'd like to hear alternative opinions from other people though.

gcommer 11y ago
> it works with W3C standards instead of going off on a tangent and hacking the DOM entirely While this sounds good on the surface (standards!) I think it is missing part the bigger picture. React, and more generally, the whole ecosystem of related libraries/frameworks it has spawned, is most importantly defined by a move to describing components using pure functions. The virtual DOM diffing is, in my view, just an implementation detail; a means towards achieving the end goal of a simpler program design via pure functions. On a different but closely related note: Angular and Polymer both use template systems which have to reinvent control structures (looping, filtering, conditionals, ...) embedded into HTML via tag attributes (eg, `<li repeat="{{todoItems}}">`). Contrast this with React (and especially ClojureScript's Om or Reagent), where any such logic is implemented directly using the languages normal mechanisms for it (map/filter, loops and if statements, etc.). Using HTML template languages is realy just raising up HTML and treating it as some special class of data, whereas React-style libraries recognize that it's all just trees (AKA lists of lists), and programming languages are already very good at building them up and manipulating them. Programming languages are designed for manipulating data; HTML isn't.
- marknutter 11y ago
  The major difference being, if something is written as a Polymer web component, it's immediately usable by anybody else writing for the web (with the possible exception being React developers because of their unwillingness to acknowledge or adopt web components as a standard).
  - EdwardMSmith 11y ago
    > Trying to compare and contrast React with WebComponents inevitably results in specious conclusions, because the two libraries are built to solve different problems. WebComponents provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary; engineers can mix-and-match the technologies. As a developer, you are free to use React in your WebComponents, or to use WebComponents in React, or both. https://facebook.github.io/react/docs/webcomponents.html https://facebook.github.io/react/docs/webcomponents.html
    - marknutter 11y ago
      Directly from your link: "Note: The programming models of the two component systems (web components vs. react components) differ in that web components often expose an imperative API (for instance, a video web component might expose play() and pause() functions). To the extent that web components are declarative functions of their attributes, they should work, but to access the imperative APIs of a web component, you will need to attach a ref to the component and interact with the DOM node directly. If you are using third-party web components, the recommended solution is to write a React component that behaves as a wrapper for your web component. At this time, events emitted by a web component may not properly propagate through a React render tree. You will need to manually attach event handlers to handle these events within your React components." It's worse than that, though. Web components that maintain their own state can be randomly squashed by React's virtual-DOM diffing algorithm because of the way elements are held in memory. They are just not compatible, and the React Core team has made no apologies about not agreeing with the overall concept of Web Components.
    - 11y ago
leeoniya 11y ago
if you like declarative js-only templates and less monolithic/locked-in components, check out domvm [1]. disclaimer: mine. [1] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm

gcommer 11y ago

> it works with W3C standards instead of going off on a tangent and hacking the DOM entirely While this sounds good on the surface (standards!) I think it is missing part the bigger picture. React, and more generally, the whole ecosystem of related libraries/frameworks it has spawned, is most importantly defined by a move to describing components using pure functions. The virtual DOM diffing is, in my view, just an implementation detail; a means towards achieving the end goal of a simpler program design via pure functions. On a different but closely related note: Angular and Polymer both use template systems which have to reinvent control structures (looping, filtering, conditionals, ...) embedded into HTML via tag attributes (eg, `<li repeat="{{todoItems}}">`). Contrast this with React (and especially ClojureScript's Om or Reagent), where any such logic is implemented directly using the languages normal mechanisms for it (map/filter, loops and if statements, etc.). Using HTML template languages is realy just raising up HTML and treating it as some special class of data, whereas React-style libraries recognize that it's all just trees (AKA lists of lists), and programming languages are already very good at building them up and manipulating them. Programming languages are designed for manipulating data; HTML isn't.

marknutter 11y ago
The major difference being, if something is written as a Polymer web component, it's immediately usable by anybody else writing for the web (with the possible exception being React developers because of their unwillingness to acknowledge or adopt web components as a standard).
- EdwardMSmith 11y ago
  > Trying to compare and contrast React with WebComponents inevitably results in specious conclusions, because the two libraries are built to solve different problems. WebComponents provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary; engineers can mix-and-match the technologies. As a developer, you are free to use React in your WebComponents, or to use WebComponents in React, or both. https://facebook.github.io/react/docs/webcomponents.html https://facebook.github.io/react/docs/webcomponents.html
  - marknutter 11y ago
    Directly from your link: "Note: The programming models of the two component systems (web components vs. react components) differ in that web components often expose an imperative API (for instance, a video web component might expose play() and pause() functions). To the extent that web components are declarative functions of their attributes, they should work, but to access the imperative APIs of a web component, you will need to attach a ref to the component and interact with the DOM node directly. If you are using third-party web components, the recommended solution is to write a React component that behaves as a wrapper for your web component. At this time, events emitted by a web component may not properly propagate through a React render tree. You will need to manually attach event handlers to handle these events within your React components." It's worse than that, though. Web components that maintain their own state can be randomly squashed by React's virtual-DOM diffing algorithm because of the way elements are held in memory. They are just not compatible, and the React Core team has made no apologies about not agreeing with the overall concept of Web Components.
  - 11y ago

leeoniya 11y ago

if you like declarative js-only templates and less monolithic/locked-in components, check out domvm [1]. disclaimer: mine. [1] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm