Comment by jondubois | Hacker News Reader

Comment by jondubois | Hacker News Reader

Parent Full thread

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.

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

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

> 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

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.

What I struggle to understand is why you would need need to 'sync' the DOM with your data? If you're dealing with atomic values, you don't need to diff or 'sync' data. In Polymer, when you update data on the frontend, it sends a CRUD update request to the server, the relevant field is then updated in the database, then a realtime notification is sent out to all frontends which are subscribed to changes on that specific field.

Multiple fields might belong to the same 'object' but each field is atomic and can be updated independently of the whole object (without having to diff the entire object each time). This is much more efficient on both the client and server because diffing is expensive and incurs a high latency and bandwidth overhead when you scale out. Diffing is useful for collaborative editing of unstructured text documents, but it is not needed for structured (or even semi-structured) data.

The web components standards mostly deal with lifecycle and composition, not templating. One could easily not use a template system at all, or compile-to-JS template language like JSX, in a web component.

Looping and conditionals are often included in template languages because those are the most often used and most declarative control structures. More complex manipulations are left to code. This tends to work out very well in practice.

Polymer is also purely declarative/functional but it doesn't need to do DOM diffing, instead, it relies on the atomicity of individual properties.

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

Reply on news.ycombinator.com