8 ms·

I rejigged my personal website using Polymer and was thoroughly impressed. It's pretty heavyweight, mostly because I'm too cheap to precompile and minify my Jav

I rejigged my personal website using Polymer and was thoroughly impressed. It's pretty heavyweight, mostly because I'm too cheap to precompile and minify my Javascript, but the modular approach means that I can now, finally, apply actual software engineering principles to building websites. The documentation could be better, and you pretty much have to like Material Design, and there could be a richer set of standard widgets available, and it desperately needs a CDN, but other than that I found it really pleasant to use. What I haven't tried is building any kind of reactive interface. It's got some support for binding elements to data, but I didn't explore that much. Anyone care to comment?

seivan 11y ago
Did you try React before switching over? How did you enjoy data-bindings after working setState() ?
- david-given 11y ago
  No, I've never touched React (mostly because it seems to require precompilation). I've been meaning to check it out at some point but the barrier of having to set up a Javascript toolchain has, so far, been too high to be worth it. Before the Polymer rewrite the trivial amount of interactive stuff on my site was raw jquery.
  - mbrock 11y ago
    FYI, React doesn't require any precompilation. You only need to include a JavaScript file. The JSX stuff is entirely optional, although almost everyone uses it. I share your fear and loathing of JavaScript compilation toolchains, and I successfully avoided all of them on a medium-sized React project. After we had a good working prototype, we started using some more tooling, but we kept it extremely simple to start with. 1. JSX tags simply compile to calls like React.createElement("a", { href: url }, ["content"]) and if you just create a short alias for that function, you don't need JSX at all. 2. If you're anything like me, things like Flux scare you by being weirdly ideological and requiring unnecessary boilerplate. You can ignore it and just use a single object to store all your state, according to the "keep it simple, stupid" philosophy. That said, I would recommend that you look at the Redux library, which is a simple and rational approach to the nebulous "Flux" concept. Redux is simple—it's just a certain design pattern that makes sense in the React context. 3. I find React.addons.update to be the most obvious and simple way of doing immutable updates to nested structures—which is what most React programs are doing all the time. People have come up with various libraries for more sophisticated immutable data structures, but you're unlikely to need them, and React.addons.update gives you 90% of the bang. Next time I have a bit of non-stressed free time, I'd like to make a repository with an example React application that's extremely simple, requiring no tooling and as much as possible avoiding "lockin" to various newfangled libraries and paradigms...
    - bsimpson 11y ago
      I shared your fear of toolchains, but with Webpack, Babel, and Hot Module Replacement, I've been won-over. Those tools make it painless to sculpt out a UI in real-time, using the latest ES sugars and a sane module system. Webpack has Uglify built-in, so you can target a minified file for production. With Babel and JSX, you're still writing idiomatic JS, so you don't have the same lock-in problems you might with something like CoffeeScript. In my mind, it's a clear value-add with no observed downside. What's your hesitation?
      - mbrock 11y ago
        Yeah, those things are nice and compelling. I've used them, often happily! Some of the new language features are hard to live without once you're used to them; I especially like async/await and the destructuring syntax. The flip side is simply that it's more technology, more stuff to learn, more stuff to keep running on your computers, and more potential bugs and strange interactions to run into. I don't like to talk about it in a negative way, because it can sound like I'm disparaging the technology. But, there are nice things about having your project be written in the actual language that the browser already supports. Like simply never having to think about transpilers. Of course once you've learned about tools like Webpack and Babel, you can use them to your heart's content if they make you more productive. I just wanted to emphasize to the person I replied to that you don't NEED any of them. Especially not to just get started. You don't need minifying until there's a problem with your page load time and until you actually know that minifying will help with that -- until then, it's strictly speaking a premature optimization. (Writing less complex code may be more important!) And so on. And "no observed downside" is not strictly true if you consider the cost of added complexity. For someone who is overwhelmed by infrastructural proliferation, it should be nice to hear that you can develop actual applications with just plain JavaScript and maybe a small Makefile.
        bsimpson 11y ago
        By "no observed downside", I meant once the toolchain is set up. Now, I get Hot Module Replacement and JS Harmony sugars for free, without having to worry about which browsers natively support which new features. Your point about perceived complexity/intimidation is a good one, but for me, removing cross browser inconsistencies simplifies development more than Webpack complicates it.
  - seivan 11y ago
    You know what, the barrier is fucking shit, that's true. I had issues myself and I'm not sure I am doing it right. However don't knock it off because of the precompilation stuff. Mostly because I'd like a nice comparison by someone, heh :) I personally hate bindings now, apart for using them with forms, but React offers a mixin for that. What I am interested is if Polymer is worth it or not.
    - tracker1 11y ago
      If you like a discrete control flow, then Polymer is a valid approach. TBH, if your application isn't beyond moderately complex, it doesn't matter too much which framework you choose as long as you have relatively clean separation of logic and control flows. React (with a flux-like control flow library, such as Redux) has a higher cognitive load to start. Where it shines is as additional features are added, there is very little additional complexity. Where with Polymer (or Angular) your application as will see a curve of additional complexity as features are added. I started a pretty basic setup for React + Webpack with hot reloading[1]. I'm going to add in Redux next, then Router... At which point I'm planning on adding in material-ui[2]. From there, I'll try to keep it updated or forked to use as a base application. I started it off by following te SurviveJS book[3], but my direction is a bit different. I'd also recommend reading the full stack redux tutorial[4]. [1] https://github.com/tracker1/r3k-example https://github.com/tracker1/r3k-example [2] http://material-ui.com/#/ http://material-ui.com/#/ [3] http://survivejs.com/ http://survivejs.com/ [4] http://survivejs.com/ http://survivejs.com/
  - RussianCow 11y ago
    JSX isn't mandatory, so you can just write plain old JS if you want. And if you want to use JSX but don't want to use a full-blown toolchain for development, there is an in-browser JSX transform library[0] that you can include to do the compilation on the client side. [0]: https://facebook.github.io/react/docs/tooling-integration.html#in-browser-jsx-transform https://facebook.github.io/react/docs/tooling-integration.ht...
    - seivan 11y ago
      To be fair React without JSX is pretty bad. I did that for a while with TypeScript before it got JSX support.
      - cloverich 11y ago
        I agree with you but to provide some more context, some people seem to prefer the non-JSX approach. Here is a (random) example of what that looks like: https://github.com/littlebits/react-popover/blob/master/examples/basic/index.js https://github.com/littlebits/react-popover/blob/master/exam...
        seivan 11y ago
        Oh yeah, I remember seeing that with coffee-script without the parentheses.
      - malandrew 11y ago
        React with JSX is pretty bad. A library like https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript solves the verbosity with not using JSX.
  - k__ 11y ago
    I made a quick tutorial with this in mind. Most of it is JSX based, but it has 3 lessons without it. Maybe this helps :) https://github.com/kay-is/react-from-zero https://github.com/kay-is/react-from-zero
Zikes 11y ago
Polymer has a few baked-in elements to help with various data binding needs: https://www.polymer-project.org/1.0/docs/devguide/templates.html https://www.polymer-project.org/1.0/docs/devguide/templates.... Another classic approach I've seen is to create an "<x-app>" element which contains the entire site, which also handles the various application state and binding tasks. The Polymer Starter Kit[1] follows this approach, and it also includes tools for building/minification using Vulcanize[2] and gulp[3]. [1] https://github.com/polymerelements/polymer-starter-kit https://github.com/polymerelements/polymer-starter-kit [2] https://github.com/Polymer/vulcanize https://github.com/Polymer/vulcanize [3] http://gulpjs.com/ http://gulpjs.com/
kawera 11y ago
A new and pretty nice set of wc widgets is http://expandjs.com http://expandjs.com
tolmasky 11y ago
We (tonicdev.com) experimented with both Polymer and React before settling on React. Doing things "the right way" in Polymer/WebComponents was just a mess. It did in fact remind me of the "old way" of doing things in Cocoa: AKA, accounting for every edge case with every appendChild or DOM mutation that could take place on your component. Having tried React's "API-less" approach of just re-rendering what you want given the params/sub-components, it was an absolute time sink that just offered no benefits. Here is a question I asked back then: http://stackoverflow.com/questions/25856324/iterating-through-polymer-content-insertion-points http://stackoverflow.com/questions/25856324/iterating-throug... You'll see in the answer the complexity around dealing with children that come and go (vs in React you'd actually write it declaratively once and be down with it -- kind of interesting that Polymer has so much "templaty" stuff and is ultimately less declarative than the pure JS approach React).
BurningFrog 11y ago
> finally, apply actual software engineering principles to building websites I've waited a looong time for that. It does seem like we're getting close to being able to work on the web like I did on my Mac in 1990!
wwweston 11y ago
> actual software engineering principles to building websites What are the actual software engineering principles Polymer enables developers to apply?
- hugozap 11y ago
  Mostly composability. Assembling a web app from small custom and self contained components is a big difference. It's just a library, so it won't do magic but it's a big improvement.
- pfooti 11y ago
  Separation of concerns and better variable scoping as well. In a webcomonent inside a shadow dom, you can do something like input id="mainInput" or some other generic-named DOM id, without worrying that some other third-party library or component will create another node with the same id. Similarly for CSS selectors and class names - I mean, BEM and SMACCS and stuff are cool and all, but it's also nice to know that my CSS styles won't leak outside the component, so I can just do div class="main" or something and not worry about how other developers name their classes on other branches of the DOM.

seivan 11y ago

Did you try React before switching over? How did you enjoy data-bindings after working setState() ?

david-given 11y ago
No, I've never touched React (mostly because it seems to require precompilation). I've been meaning to check it out at some point but the barrier of having to set up a Javascript toolchain has, so far, been too high to be worth it. Before the Polymer rewrite the trivial amount of interactive stuff on my site was raw jquery.
- mbrock 11y ago
  FYI, React doesn't require any precompilation. You only need to include a JavaScript file. The JSX stuff is entirely optional, although almost everyone uses it. I share your fear and loathing of JavaScript compilation toolchains, and I successfully avoided all of them on a medium-sized React project. After we had a good working prototype, we started using some more tooling, but we kept it extremely simple to start with. 1. JSX tags simply compile to calls like React.createElement("a", { href: url }, ["content"]) and if you just create a short alias for that function, you don't need JSX at all. 2. If you're anything like me, things like Flux scare you by being weirdly ideological and requiring unnecessary boilerplate. You can ignore it and just use a single object to store all your state, according to the "keep it simple, stupid" philosophy. That said, I would recommend that you look at the Redux library, which is a simple and rational approach to the nebulous "Flux" concept. Redux is simple—it's just a certain design pattern that makes sense in the React context. 3. I find React.addons.update to be the most obvious and simple way of doing immutable updates to nested structures—which is what most React programs are doing all the time. People have come up with various libraries for more sophisticated immutable data structures, but you're unlikely to need them, and React.addons.update gives you 90% of the bang. Next time I have a bit of non-stressed free time, I'd like to make a repository with an example React application that's extremely simple, requiring no tooling and as much as possible avoiding "lockin" to various newfangled libraries and paradigms...
  - bsimpson 11y ago
    I shared your fear of toolchains, but with Webpack, Babel, and Hot Module Replacement, I've been won-over. Those tools make it painless to sculpt out a UI in real-time, using the latest ES sugars and a sane module system. Webpack has Uglify built-in, so you can target a minified file for production. With Babel and JSX, you're still writing idiomatic JS, so you don't have the same lock-in problems you might with something like CoffeeScript. In my mind, it's a clear value-add with no observed downside. What's your hesitation?
    - mbrock 11y ago
      Yeah, those things are nice and compelling. I've used them, often happily! Some of the new language features are hard to live without once you're used to them; I especially like async/await and the destructuring syntax. The flip side is simply that it's more technology, more stuff to learn, more stuff to keep running on your computers, and more potential bugs and strange interactions to run into. I don't like to talk about it in a negative way, because it can sound like I'm disparaging the technology. But, there are nice things about having your project be written in the actual language that the browser already supports. Like simply never having to think about transpilers. Of course once you've learned about tools like Webpack and Babel, you can use them to your heart's content if they make you more productive. I just wanted to emphasize to the person I replied to that you don't NEED any of them. Especially not to just get started. You don't need minifying until there's a problem with your page load time and until you actually know that minifying will help with that -- until then, it's strictly speaking a premature optimization. (Writing less complex code may be more important!) And so on. And "no observed downside" is not strictly true if you consider the cost of added complexity. For someone who is overwhelmed by infrastructural proliferation, it should be nice to hear that you can develop actual applications with just plain JavaScript and maybe a small Makefile.
      - bsimpson 11y ago
        By "no observed downside", I meant once the toolchain is set up. Now, I get Hot Module Replacement and JS Harmony sugars for free, without having to worry about which browsers natively support which new features. Your point about perceived complexity/intimidation is a good one, but for me, removing cross browser inconsistencies simplifies development more than Webpack complicates it.
- seivan 11y ago
  You know what, the barrier is fucking shit, that's true. I had issues myself and I'm not sure I am doing it right. However don't knock it off because of the precompilation stuff. Mostly because I'd like a nice comparison by someone, heh :) I personally hate bindings now, apart for using them with forms, but React offers a mixin for that. What I am interested is if Polymer is worth it or not.
  - tracker1 11y ago
    If you like a discrete control flow, then Polymer is a valid approach. TBH, if your application isn't beyond moderately complex, it doesn't matter too much which framework you choose as long as you have relatively clean separation of logic and control flows. React (with a flux-like control flow library, such as Redux) has a higher cognitive load to start. Where it shines is as additional features are added, there is very little additional complexity. Where with Polymer (or Angular) your application as will see a curve of additional complexity as features are added. I started a pretty basic setup for React + Webpack with hot reloading[1]. I'm going to add in Redux next, then Router... At which point I'm planning on adding in material-ui[2]. From there, I'll try to keep it updated or forked to use as a base application. I started it off by following te SurviveJS book[3], but my direction is a bit different. I'd also recommend reading the full stack redux tutorial[4]. [1] https://github.com/tracker1/r3k-example https://github.com/tracker1/r3k-example [2] http://material-ui.com/#/ http://material-ui.com/#/ [3] http://survivejs.com/ http://survivejs.com/ [4] http://survivejs.com/ http://survivejs.com/
- RussianCow 11y ago
  JSX isn't mandatory, so you can just write plain old JS if you want. And if you want to use JSX but don't want to use a full-blown toolchain for development, there is an in-browser JSX transform library[0] that you can include to do the compilation on the client side. [0]: https://facebook.github.io/react/docs/tooling-integration.html#in-browser-jsx-transform https://facebook.github.io/react/docs/tooling-integration.ht...
  - seivan 11y ago
    To be fair React without JSX is pretty bad. I did that for a while with TypeScript before it got JSX support.
    - cloverich 11y ago
      I agree with you but to provide some more context, some people seem to prefer the non-JSX approach. Here is a (random) example of what that looks like: https://github.com/littlebits/react-popover/blob/master/examples/basic/index.js https://github.com/littlebits/react-popover/blob/master/exam...
      - seivan 11y ago
        Oh yeah, I remember seeing that with coffee-script without the parentheses.
    - malandrew 11y ago
      React with JSX is pretty bad. A library like https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript solves the verbosity with not using JSX.
- k__ 11y ago
  I made a quick tutorial with this in mind. Most of it is JSX based, but it has 3 lessons without it. Maybe this helps :) https://github.com/kay-is/react-from-zero https://github.com/kay-is/react-from-zero

Zikes 11y ago

Polymer has a few baked-in elements to help with various data binding needs: https://www.polymer-project.org/1.0/docs/devguide/templates.html https://www.polymer-project.org/1.0/docs/devguide/templates.... Another classic approach I've seen is to create an "<x-app>" element which contains the entire site, which also handles the various application state and binding tasks. The Polymer Starter Kit[1] follows this approach, and it also includes tools for building/minification using Vulcanize[2] and gulp[3]. [1] https://github.com/polymerelements/polymer-starter-kit https://github.com/polymerelements/polymer-starter-kit [2] https://github.com/Polymer/vulcanize https://github.com/Polymer/vulcanize [3] http://gulpjs.com/ http://gulpjs.com/

kawera 11y ago

A new and pretty nice set of wc widgets is http://expandjs.com http://expandjs.com

tolmasky 11y ago

We (tonicdev.com) experimented with both Polymer and React before settling on React. Doing things "the right way" in Polymer/WebComponents was just a mess. It did in fact remind me of the "old way" of doing things in Cocoa: AKA, accounting for every edge case with every appendChild or DOM mutation that could take place on your component. Having tried React's "API-less" approach of just re-rendering what you want given the params/sub-components, it was an absolute time sink that just offered no benefits. Here is a question I asked back then: http://stackoverflow.com/questions/25856324/iterating-through-polymer-content-insertion-points http://stackoverflow.com/questions/25856324/iterating-throug... You'll see in the answer the complexity around dealing with children that come and go (vs in React you'd actually write it declaratively once and be down with it -- kind of interesting that Polymer has so much "templaty" stuff and is ultimately less declarative than the pure JS approach React).

BurningFrog 11y ago

> finally, apply actual software engineering principles to building websites I've waited a looong time for that. It does seem like we're getting close to being able to work on the web like I did on my Mac in 1990!

wwweston 11y ago

> actual software engineering principles to building websites What are the actual software engineering principles Polymer enables developers to apply?

hugozap 11y ago
Mostly composability. Assembling a web app from small custom and self contained components is a big difference. It's just a library, so it won't do magic but it's a big improvement.
pfooti 11y ago
Separation of concerns and better variable scoping as well. In a webcomonent inside a shadow dom, you can do something like input id="mainInput" or some other generic-named DOM id, without worrying that some other third-party library or component will create another node with the same id. Similarly for CSS selectors and class names - I mean, BEM and SMACCS and stuff are cool and all, but it's also nice to know that my CSS styles won't leak outside the component, so I can just do div class="main" or something and not worry about how other developers name their classes on other branches of the DOM.