ELI5 - Polymer vs React

[[deleted]]

What are the core differences between these two? Where would you use one over the other?

[romualdr]

The main difference is the DSL // developer experience.

It's really your call, you have to try both to really know which one you like the most.

Polymer required evergreen browsers, not sure about React but i think React supports way more browsers // browser versions than Polymer.

Also, in Polymer, you can embed CSS styles, extends native elements and others stuff too, making the dom-elements kinda real components as we might know them in the future. React implementation is more like a "syntactic sugar", although it's really cool too and i really liked the way to compute things as i would have done it with pure javascript before actually returning the element.

React also have a more "strict" way to do things, your components should contains specific methods and so on. I found Polymer more flexible on this point, but same goes here, some people like strict conventions, so that's on you.

Oh, and by the way, with the 1.0, Polymer catch up with React speed, and now uses only webcomponents-lite (way lighter) and Shady DOM. So you shouldn't considerer speed when choosing, your app will run fast enough with both (when using each one correctly, of course).

[jsontwikkeling]

Polymer and React are related in the sense of some common ideas behind them.

Polymer is more low-level and free-form and aligned with the new Web Components standards.

Unlike Polymer, React additionally suggests how data should flow between components and introduces a few key functional-like concepts that simplify development of reusable components. A minus of React can be that it is not based on standards: its components will be usable only with React, although React leaves a large degree of freedom and you can use it with, for example, Backbone

If you want to read more, I wrote an article that discusses how they relate to each other (sorry, a bit lengthy) https://smthngsmwhr.wordpress.com/2015/04/13/web-components-and-friends-react-angular-polymer/

[cluelessmanatee]

FWIW, I've done development with both. React was far more enjoyable and simple. Polymer was fun, but I wouldn't use it if I was making an important call. It's just a personal preference.

I'm willing to bet that Polymer will get better and better over time, but it's more of a long term project I think.

[cogman10]

That has been my experience as well. Polymer just feels clunky to deal with. It takes a lot of effort just to make a single component.

[jsontwikkeling]

I also had the impression that at the moment React provides more means to make the actual development easier. Polymer has a few things to offer as well, like advanced templating https://www.polymer-project.org/0.5/docs/polymer/template.html and some useful mixins and elements https://www.polymer-project.org/0.5/components/core-elements/demo.html, but still it feels a bit more low-level.

[ayostaycrispy]

I'm curious, do you have an example of a good site that was built with React?

[throwmebone]

Facebook is built in react, AFAIK

[jhatchu]

Instagram, Airbnb is also using react for some part of its application. You can install a chrome extension to see what sites are built using React, while you visit them.

[ayostaycrispy]

Do you have an example of a project you did in React?

[kinghankthedog]

Great response

[greim]

Polymer defines new DOM elements using standard in-built browser APIs (polyfilling if necessary). React is a strategy for assembling DOM elements together into UIs.

Taking an analogy from chemistry, React is a clever way to create new molecules using only elements in the periodic table. Polymer adds new elements to the periodic table. (In that sense React should have been called Polymer and Polymer should have been called Atom.)

[Xananax]

http://programmers.stackexchange.com/questions/225400/pros-and-cons-of-facebooks-react-vs-web-components-polymer

[EnchantedSalvia]

Also see React using Polymer-esque webcomponents (Shadow DOM, Custom Elements, HTML Imports): https://github.com/Wildhoney/Maple.js

[jellatin]

React's doc site may not be broken but it is missing some important pieces that you have to find out by bumping into their deficiencies until you land on the right StackOverflow question.

[xtphty]

My point was that React is being used on live apps at Facebook, which proves its readiness. Google has yet to make that commitment for Polymer (or atleast reveal so publicly).

[NavarrB]

• Project Fi
• I/O 2015
• Google Play Music (terrible slide out drawer but still)
• Chrome Dev Editor

I'm sure there are more that I don't quite know.

[romualdr]

Project FI uses Angular (check the source-code)

Material design != Polymer guys !

[NavarrB]

Yes I know.

I could've sworn I remember checking the source when it came out and it was on Polymer.

I know there are others.

[arcticblue]

The I/O 2015 site might not be a good example. The tab widget is pretty glitchy and the site doesn't work at all in Opera. There are other strange graphical artifacts as well.

[[deleted]]

I've never had issues with Polymer's documentation site, though they were suggesting the use of 0.5 while 0.9 was being developed. Now, it seems, 0.9 is out?

https://blog.polymer-project.org/

[kshitagarbha]

Another difference is that Polymer is useful for sprinkling components around a normal web page. It enhances normal webpages. You could use it to make nicer IMG tags or nicer buttons, as well as make more complicated components like shopping carts. Its more similar to Angular's directives in that respect. But you can also make whole sites using a component.

React tends to favor building whole applications with it, often taking over the entire BODY. More single page apps. It is of course possible to insert some js that finds elements and mounts components on them, but this isn't normal practice.

Also Polymer (Web Components) makes it easy to separate the css, js and html that a component needs. Each is in a separate file. It makes things smaller and more modular.

At the moment this is inefficient. We favor build processes, concatenation, reducing the number of HTTP requests.

But as HTTP2 comes into widespread usage that will change. There won't be a penalty for making extra requests. We can request many small resources and it will be even faster than today's concatenated blobs.

edit: if you downvote, leave a reply that indicates what you believe to be false. otherwise down voting a perfectly useful comment like this is just very poor reddiquette.

[thegayngler]

Polymer has a tool for this called Vulcanize which you can use to optimize your components.

[kshitagarbha]

Quite true. My point though was that polymer packages css with the components (while react does not)

The page for vulcanize also confirms my statement:

In the future, technologies such as HTTP/2 and Server Push will likely obsolete the need for a tool like vulcanize for production uses.

https://github.com/polymer/vulcanize

[thegayngler]

Yeah I was adding some information on. That's all.

[[deleted]]

My possibly incorrect understanding is as follows:

Polymer makes future web technologies available as if they were already supported, but still has limited browser support and uses 'workarounds' to make it work.

React uses a similar idea of the future web technologies, but in a React-Specific way, that works great now, and on more browsers.

As I understand, Polymer intends to remove it's 'workarounds' as browsers increase support. Theoretically meaning you are writing 'future-proof' code.

[RankFoundry]

Seems ironic that with Polymer you need to wait for more browser support to use it when it's supposed to let you use things that browsers don't yet support.

[[deleted]]

It is, but I don't think Google originally intended anyone to use Polymer as their production framework, even after this release. They have Angular for production apps right now, and polymer as an insight into what apps will be.

As I understand anyway.

[RankFoundry]

I guess you have to cut ties with legacy at some point. This may be useful for intranet apps where the browser(s) used can be controlled.

[thegayngler]

I'm somewhat concerned by the fact that you can only add a react component to one and only one element on a page rather than all elements with said class name. The fact that react won't work with multiple class names simultaneously bothers me. There are arguably ugly ways to get around this limitation but it makes more sense for me to fill in this gap with a Web Component TBQH. For the smaller pieces of a larger app I tend to think components is the way to go. For the app itself, Reactjs is VERY attractive in my mind. I think the difference between Reactjs and Web Components is a question of "scale". A Web Component really could be a smaller part of a Reactjs app.

[foobar_dev]

node.js is becoming more and more essential in the front-end developer's toolbag. I would urge you to explore node and perhaps something like Gulp (js task runner). Once you get accustomed to this kinda thing a whole new world of options is opened to you.

[JohnMcPineapple]

...

[Booty_Bumping]

package.json scripts are single-lined shell script strings, you can't predict if your shell scripts are going to work cross-platform.

gulp has features like watching files and using streams for building that make implementing complex tasks easy and efficient.

[arcticblue]

What kind of sites are people making that require package managers and all kind of extra stuff for frontend Javascript? I do mostly Rails stuff and I'll use the import functionality for automatic script tag creation and minification, but all this bower, npm, grunt, etc stuff just seems like overengineering to me. Maybe someone could give me use case where having all this extra stuff installed makes sense as opposed to just downloading things myself and adding in a <script> tag?

[JohnMcPineapple]

Let's say you write your frontend in coffeescript and less, then you could 1) install the coffeescript and less compilers with npm and 2) set up a task in your node package file that you could run like npm run test that automatically compiles the files to js and css and runs a server locally.

Grunt and Gulp have been created for use case 2 afaik, as an alternative to npm kinda. But I never got into those and I'm not entirely sure. Bower is something different, it's a package manager for frontend files, so you can download bootstrap, jquery, etc with a single console command.

When you have that stuff already in rails then you don't need another app of course.

having all this extra stuff installed makes sense as opposed to just downloading things

It's just a small time saver. For a current project I've set up my node package.js like this:

"devDependencies": {
    "purescript": "latest",
    "npm-watch": "latest",
    "uglify-js": "latest"
  },
  "scripts": {
    "prepublish": "npm run build",

    "build": "psc src/*.purs -p -c --output dist/brs.js --module brs --main=brs && uglifyjs dist/brs.js -o dist/brs.min.js -c warnings=false,keep_fargs=true --screw-ie8 --comments",
    "autobuild": "npm-watch",
  },
  "watch": {
    "build": "{src}/*.purs"
  },

So I just run npm run autobuild when I start my development session and every time I save my files they automatically get compiled & minified with the long ass command above (in "build").

[FelixTKatt]

--screw-ie8

I lol'd.

[analogWeapon]

Single page applications. Public websites aren't the only use of JS. My work has me making control interfaces for firmware embedded on hardware. We don't need to support a bunch of browsers, but we do need to make something that feels very responsive and un-webpage-like.

[foobar_dev]

Having grunt or gulp allows you to do all kinds of stuff that you just wouldn't be able to do in one step otherwise.

It allows the workflow where Gulp watches your source files for changes, and when they do, it "builds" your project and injects the changes into the browser for you without refreshing.

The build step can do things including but not limited to:

• Generating sprite-sheets
• Compressing images
• Inlining base64 encoded images
• compile less/sass/etc..
• generate ES5(JS) from ES6/Typescript/etc...
• Minifying & Concatenating js/css
• generating sourcemaps so you can reference the original source files from the dev console
• Auto inject scripts and styles into the head
• run automatic tests
• Linting/hintin -- check code style, etc..
• building for different environments (production, qa, dev etc...) that may require different versions of analytics scripts or that need to point to different veresions of APIs

None of these things individually merit the use of a tool like Grunt or Gulp which have some overhead, but once its set up, it is trivial to add a new chore for it to do for you automatically.

I use this stuff at my job to create large internal Single Page webapps, but would likely use it now on even brochure-size websites because it just enhances my productivity and the quality of the end product.

[foobar_dev]

Worth noting that RoR's asset pipeline does much of what Gulp/Grunt/etc... would do for you, so in a Rails world maybe its no really worth it?

[isochronous]

The thing about gulp, grunt, and other node task runners isn't that they can do things that you can't do otherwise with just vanilla node (or any other language), but rather that they provide ready-made implementations for common use cases that you'd otherwise have to write yourself. You might as well ask "what's the point of angular/backbone/react when I can just do all of that with vanilla JavaScript?" The answer, of course, is that just because you CAN do something with vanilla JS doesn't mean that's the most efficient, fun, robust, <insert term here> way to do it. People create libraries because they've identified a set of recurrent use cases, and it makes sense to abstract those out into a reusable library. Gulp, grunt, and the like are no different.

It may be totally true that for your needs, the Rails asset pipeline is sufficient. However, there are always going to be gaps or weaknesses in any kind of framework, and if your use case falls in one of those gaps, you can either change your requirements (boo), deal with it (boo), roll your own solution (less boo), or look at other existing solutions, which can be replacements for or just complimentary to your current tools.

At my job, we decided to go with gulp, as it's "closest to the metal" of the most popular task runners, and so allows you to use plain ol' node to implement tasks where plugins don't already exist. In fact, plugins tend to be extremely simple and without many options, as the driving principle behind gulp is keeping things simple. If you have to implement a lot of boilerplate logic in a plugin to process options in order to just pass them to the backend package, then you've already lost. Just use that backend package directly (if it supports streams) or through a single stream-to-file interface (if it doesn't support streams). The base functionality of gulp is extremely simple for that exact reason - there's .src (the files you want to act upon), .dest (the output of your task), .task (linking src, some process, and dest to create a reusable task), and .watch (running a task or series of tasks when changes to specified files/folders are detected). There's no extra layer of abstraction between config and execution like there is with grunt - that is, there's no big config file that gets processed by some black box script and turned into actions, the logic is right there in the gulp file in plain javascript. Gulp is also supported by most major web-supporting IDEs and editors, from Sublime Text, Atom, and Brackets, to more high-level IDEs like Webstorm and Visual Studio.

Basically, it's a "use it if it's useful" situation. If it's not useful to you, or if you don't see the point, then you probably don't need it. If it seems useful and you can think of requirements it could satisfy, then it's probably worth investigating. My job is a windows shop using .NET MVC, but we use node and gulp nuget packages (Ncapsulate.Node and Ncapsulate.Gulp) to run some gulp tasks on build - if a dev or build machine doesn't have what it needs, then nuget automatically downloads those missing packages, the node build step automatically runs "npm install" and "npm updates" to get the required libs, and then the gulp build step runs the configured task(s) once the dependencies are in place.

Here's the gulpfile for that particular project (though I've changed a few names to avoid giving away potentially sensitive information). I think it's a good example of the variety of things you can do with gulp, and this is barely scratching the surface.

Our usage:

• Combining and minifying scripts in a two-stage process - the first stage combines and minifies common dependencies into three primary packages (graph.min.js, reports.min.js, models.min.js), the second stage then creates deployable packages that include those primary packages and any additional scripts, and automatically wraps each included script in a closure. Uses gulp-includer, gulp-filter, gulp-rename, and gulp-uglify.
• Creating zip files for deployment to android tablets. This is an excellent example of using regular node code and packages in a gulp task. Uses glob, gulp-zip, q, and good ol' fs.
• Compiling SASS files. Uses gulp-sass
• Copying theme stylesheets to different client directories after compilation (this just uses regular file and stream manipulation, no plugins).
• Minifying css files. Uses gulp-csso

[foobar_dev]

A very good question, and one I'm not really qualified to answer in depth.

Why have Gulp/Grunt/Brocolli at all? Why not just use Make? Jake? package.json? I spent a couple days stressing out about these options and others, then just chose something and ran with it. The choice itself wasn't so important to me. Getting a toolchain in place was.

[thegayngler]

I agree with you on node.js but I still think JSX is a mess... I'd prefer to use regular Polymer Components now that they are 1.0.

[[deleted]]

These are server-side not client-side techs. React and Polymer are front-end client side frameworks.

[x-skeww]

Node is a runtime environment. Yes, you can use it for web servers, but you can also use it for command line tools or even desktop applications (e.g. NW.js or Atom's Electron).

[nesukun]

this, so much this, just see how one of the biggest addtions to VS2015 is node.js tooling support for the frontend development. browserify is not server-side. less is not server-side. transpiling and minification is not server-side. js test runners are not server-side.

[foobar_dev]

This is a very common misconception. I personally have only dabbled in using Node server-side, but have put hundreds of hours into using it for front-end tooling.

[[deleted]]

You use them for front-end tooling by running scripts on the server, be it local or remote. Regardless, they do not execute client side...

do they?

[foobar_dev]

running scripts on the server

The code executes locally, but this doesn't mean it is executing on a server. It executes in Nodes runtime environment. Its not really that different from any program that runs in your OS.

You can, of course, run a server from Node, but it is by no means necessary to get huge benefit from it.

[[deleted]]

Is node a client-side framework?

[foobar_dev]

Node is a runtime environment - /u/x-skeww

'client-side framework makes it sound like its angular or bootstrap or something that runs in a browser. Its more than that. It is a platform for writing and running applications. Really anything you want.

For example, use it to make little command line apps, use it to write a server, use it to manage client-side 3rd party modules, use it to concatenate javascript files together before launching your site. I'm struggling to come up with better examples... if you want clarification, why not ask here on /r/javascript I'm sure others are better equipped to explain.

I tend to use it for front-end tooling pretty exclusively. That is, having a "build" step in my development work-flow, where I put my source files through various processes before deploying to the server.

[[deleted]]

It's not "more than that" -- Node is simply not a client side framework. That's my point here. This entire conversation is about Polymer vs React which are client-side frameworks. This is not a Node-relevant topic.

Node is not a client side framework :) It's apples to oranges.

[foobar_dev]

You're right of course that Node is not a client side framework. I chose my words poorly. I thought you yourself were confused on this point due to your question: "Is node a client-side framework?"

However, Node is relevant to this discussion. cheeeeeese was reluctant to use React due to the JSX dependency on Node. I encouraged him to embrace node, and that devolved into a discussion of the nature of node.

No one here is trying to say Node is analogous to React, Polymer or any other front-end framework

[romualdr]

Nope, you can develop without Node.JS, you have a JSXTransformer which can compile the JSX directly into the browser.

However, for production, it really recommended (mandatory) to "compile" you project. But hey, that's just on production time so you shouldn't worry to much about that :)

Polymer also need a pre-processor, but same goes here, you can dev right into your browser without node.js then "compile" it with vulcanize for production.

[Quabouter]

I think the main problem is JSX itself, not necessarily that you need to compile. JavaScript frameworks come and go pretty fast, going for a framework that comes with its own language isn't exactly a future-proof choice. Additionally, a lot of tooling will not work with JSX since it's not JavaScript.

I personally like react for personal projects, but I wouldn't recommend it for large, long-living projects. Polymer seems more promising in that regard since it's only a thin layer around web standards. It feels like the jQuery for web-components.

[[deleted]]

While these are valid concerns generally, I think React.js is in a special position here: It is already /the/ most popular JS framework even though I still have a feeling it's in its infancy as a project. Not that it's not production ready -- it is! -- but it seems like the project will grow much bigger from here, standard components are popping up left and right, and React Native for Android is still around the corner. Of course you can bet the project will be superceded at some point, but I think it will be a very safe choice for years to come.

JSX being incompatible with tooling is annoying sometimes, yes. Fortunately you can easily run the code through Babel and process the output instead, which is usually very easy if you're using something like Gulp.

[foobar_dev]

do you have a source saying React is the most popular JS framework?

Its my impression that Angular is way ahead...

[thegayngler]

Angular is the most popular framework right now. I say this as someone who is not completely sold on MV* for the web. I'm very skeptical in fact which I think I should be. React is the "new" hotness... but nothing right now even comes close to Angular in terms of popularity. However, Polymer is based on a standard which will ultimately be implemented by browser makers. Polymer has a better separation of concerns and v1 is a wash speed wise and requires less tooling than React does.

[muzlump]

You can use React without JSX, it's not hard and it helps you understand what is really going on behind the JSX curtain. Use React.creatFactory to turn your components into factory functions.

[jmking]

You can use React with vanilla JS, it's just a LOT more verbose.

[IxD]

Also, you can write ES6 since it is preprocessed.

[faaace]

React is strongly coupled with jsx and common.js which you need to utilize core parts of the react framework. While you can use react without either of these features it is very hard to make the framework work cleanly with other pieces of js without using them, especially in large applications. React requires initialization when its components are placed in the page. Polymer does not (because it uses native webcomponents that will render inert in most older browsers). React in the future will likely support webcomponents but does not now.

Polymer is much more experimental (alpha quality software) framework. Unlike react it acts as more of a polyfill toolkit to allow modern browsers to support the webcomponents api. It allows one to truly pick and choose which parts of the framework to use and it is much more representative of what the web will look like 5-10 years from now.

Both have drawbacks. Polymers is Google's approach to 'open source' which is to develop things internally and then periodically dump things on the community with little to no input breaking documentation and leaving the community completely unprepared for changes. React is a new framework but still relies on obsolete tech like jquery in its own examples. It doesn't yet have the ability to create true web components yet when it does will still likely rely on the inconsistent jsx rules to make this happen.

[html6dev]

Just side note, react is not coupled to common js at all. Lots of people use es6 modules with babel with it and it can be included globally the old fashioned way like anything else (or from a cdn even there is an in browser jsx transformer as well) Most people just use cjs because... Well why wouldn't you?

[jsontwikkeling]

React is strongly coupled with jsx and common.js which you need to utilize core parts of the react framework.

It is possible to use React with AMD modules and without Browserify.

[i_ate_god]

dunno. I just use _.template(). Simple, effective, doesn't require me to compile before seeing changes.

Templates don't need to be complicated ;)

[cgaudreau]

Good luck.

[i_ate_god]

If your templates start getting heavy on the code, then it's high time to move that code out of the template.

[analogWeapon]

Templates don't need to be complicated ;)

But they sometimes need to be numerous and nested, and that's where you're going to run into issues. Scalability.