5 ms·

A couple of down sides of web components: - they interact poorly with requirejs and amd in general. - they flat out dont work at all in IE8 - there's no 'goo

A couple of down sides of web components: - they interact poorly with requirejs and amd in general. - they flat out dont work at all in IE8 - there's no 'good' solution for the request hell you get from loading 50 components; although some of the tooling is getting there (vulcanize). - the tooling in general is currently rubbish; no way to easily combine sass + jade + coffee into a web component (eg. with gulp, no the dart bindings don't count as tooling). no way to have external resource files. ...but despite that all, they're fantastically productive, great for testable ui, great for making reusable elements you can use in multiple projects. Short answer is: yes, unless you have to support IE8.

DCKing 12y ago
> - they interact poorly with requirejs and amd in general. > - the tooling in general is currently rubbish; no way to easily combine sass + jade + coffee into a web component (eg. with gulp, no the dart bindings don't count as tooling). no way to have external resource files. If you use Dart and its Polymer libraries, these two things should not be a problem. Why does that not count? He didn't say he wants to use Sass, Jade or CoffeeScript. IMO, Dart is becoming much more interesting to me as it seems it is the best way to work with Polymer.
- rektide 12y ago
  Most javascript developers want to use Javascript and want to use what's available in the defacto javascript package manager (npm) and want to use the build tool that works with the javascript packages (browserify). Suggesting using something other than Javascript, it's packages, and it's preeminent packager to get started with Polymer is exactly the problem parent was highlighting, and your suggestion is bloody not well helping.
  - DCKing 12y ago
    Why the hostile reaction? Expanding your horizons is not a bad thing. > Most javascript developers want to use Javascript OP mentions nothing, parent mentions CoffeeScript. Dart also has packages and an official package manager. It also has a dogfooded official Polymer library. Setting up a modular toy project with packages was easier to understand in Dart than JS for me. I don't see how I'm "bloody well not helping".
    - deleted 12y ago
      [deleted]
    - rektide 12y ago
      "polymer has these integration pain points" "you should try dart! it integrates well" you definitely told shadowmint to go fuck himself.
  - Cthulhu_ 12y ago
    IMHO, if you (nonpersonal you) identify as a Javascript developer instead of a web developer, you're a very limited and narrow-minded developer. Learning a new language is easy, and installing some new tooling shouldn't take more than a minute nowadays. Looks like Polymer is installed using Bower anyway, which is pretty standard.
    - rektide 12y ago
      If you are a webdeveloepr that builds non-Javascript tools that don't integrate with the rest of Javascript tooling, you will have a very isolated, limited, unadopted and narrow-minded niche you carve for yourself.
tinco 12y ago
If you keep everything external it works fine. We have a large project in Polymer, and we use CoffeeScript and Sass, with no problem.
- shadowmint 12y ago
  got an example? I've not seen any decent 'assembly' tools that pull all the bits together (ie. specifically post compile, turning your separate elements into one self contained .html include)
  - tinco 12y ago
    Well we haven't implemented it yet, but we use Gulp. So my plan is to just concat everything together. I've read there's a syntax for defining resources inside html files, which is probably what we're going to do.
  - deleted 12y ago
    [deleted]
ahuth 12y ago
For anyone using Rails, I've made a gem which integrates Web components seamlessly into the asset pipeline. This gives you two things: 1. In production, all imports get concatenation into 1 HTML import. 2. Any web component can use assets that need to be compiled, such as SCSS or CoffeeScript. It's called Emcee, and is available here: http://www.github.com/ahuth/emcee http://www.github.com/ahuth/emcee
- deleted 12y ago
  [deleted]
Flow 12y ago
With ReactJS you get to code as if everything is a component, why use polymer now instead of that?
- ffreire 12y ago
  ReactJS is a solid solution if you need to ship something _today_, but I think the trend will continue towards WebComponents as they become standardized across vendors (if not Polymer then x-tags, if not x-tags then... etc). In that sense, it's better to familiarize oneself with the technologies that we'll be seeing more of in the future just as we did with new HTML5 elements a few years ago. @jastanton phrased it nicely in another comment here: https://news.ycombinator.com/item?id=7971847 https://news.ycombinator.com/item?id=7971847
  - Flow 12y ago
    As I see it, the inside of Web Components still need a nice and structured way to function. I'd build my app using ReactJS now, and when I decide to use web components, I can transform each separate ReactJS component into a web component, ReactJS-tag for ReactJS-tag as I see fit. It's much safer to do it this way than rely on polymer. IMHO. When web components really are here for everyone, you are still stuck with polymer libs and tools and all the code is bound to them. Who knows, polymer might be considered bloat then?
    - magicalist 12y ago
      Polymer includes a Web Components polyfill, so you can write raw Web Components if you want to. Polymer is really just some syntactic sugar over that (and other specs thrown in, like html imports, templates, etc). That said, these aren't really the same kind of libraries at all, so I'm not sure why this is such a x vs y thread. Ideally, react and web components are fully composable, and it doesn't really matter where the element came from.
  - hcarvalhoalves 12y ago
    It doesn't matter if they keep pushing a standard no one's using to actually ship. The only people I see excited about Web Components are Googlers.

DCKing 12y ago

> - they interact poorly with requirejs and amd in general. > - the tooling in general is currently rubbish; no way to easily combine sass + jade + coffee into a web component (eg. with gulp, no the dart bindings don't count as tooling). no way to have external resource files. If you use Dart and its Polymer libraries, these two things should not be a problem. Why does that not count? He didn't say he wants to use Sass, Jade or CoffeeScript. IMO, Dart is becoming much more interesting to me as it seems it is the best way to work with Polymer.

rektide 12y ago
Most javascript developers want to use Javascript and want to use what's available in the defacto javascript package manager (npm) and want to use the build tool that works with the javascript packages (browserify). Suggesting using something other than Javascript, it's packages, and it's preeminent packager to get started with Polymer is exactly the problem parent was highlighting, and your suggestion is bloody not well helping.
- DCKing 12y ago
  Why the hostile reaction? Expanding your horizons is not a bad thing. > Most javascript developers want to use Javascript OP mentions nothing, parent mentions CoffeeScript. Dart also has packages and an official package manager. It also has a dogfooded official Polymer library. Setting up a modular toy project with packages was easier to understand in Dart than JS for me. I don't see how I'm "bloody well not helping".
  - deleted 12y ago
    [deleted]
  - rektide 12y ago
    "polymer has these integration pain points" "you should try dart! it integrates well" you definitely told shadowmint to go fuck himself.
- Cthulhu_ 12y ago
  IMHO, if you (nonpersonal you) identify as a Javascript developer instead of a web developer, you're a very limited and narrow-minded developer. Learning a new language is easy, and installing some new tooling shouldn't take more than a minute nowadays. Looks like Polymer is installed using Bower anyway, which is pretty standard.
  - rektide 12y ago
    If you are a webdeveloepr that builds non-Javascript tools that don't integrate with the rest of Javascript tooling, you will have a very isolated, limited, unadopted and narrow-minded niche you carve for yourself.

tinco 12y ago

If you keep everything external it works fine. We have a large project in Polymer, and we use CoffeeScript and Sass, with no problem.

shadowmint 12y ago
got an example? I've not seen any decent 'assembly' tools that pull all the bits together (ie. specifically post compile, turning your separate elements into one self contained .html include)
- tinco 12y ago
  Well we haven't implemented it yet, but we use Gulp. So my plan is to just concat everything together. I've read there's a syntax for defining resources inside html files, which is probably what we're going to do.
- deleted 12y ago
  [deleted]

ahuth 12y ago

For anyone using Rails, I've made a gem which integrates Web components seamlessly into the asset pipeline. This gives you two things: 1. In production, all imports get concatenation into 1 HTML import. 2. Any web component can use assets that need to be compiled, such as SCSS or CoffeeScript. It's called Emcee, and is available here: http://www.github.com/ahuth/emcee http://www.github.com/ahuth/emcee

deleted 12y ago
[deleted]

Flow 12y ago

With ReactJS you get to code as if everything is a component, why use polymer now instead of that?

ffreire 12y ago
ReactJS is a solid solution if you need to ship something _today_, but I think the trend will continue towards WebComponents as they become standardized across vendors (if not Polymer then x-tags, if not x-tags then... etc). In that sense, it's better to familiarize oneself with the technologies that we'll be seeing more of in the future just as we did with new HTML5 elements a few years ago. @jastanton phrased it nicely in another comment here: https://news.ycombinator.com/item?id=7971847 https://news.ycombinator.com/item?id=7971847
- Flow 12y ago
  As I see it, the inside of Web Components still need a nice and structured way to function. I'd build my app using ReactJS now, and when I decide to use web components, I can transform each separate ReactJS component into a web component, ReactJS-tag for ReactJS-tag as I see fit. It's much safer to do it this way than rely on polymer. IMHO. When web components really are here for everyone, you are still stuck with polymer libs and tools and all the code is bound to them. Who knows, polymer might be considered bloat then?
  - magicalist 12y ago
    Polymer includes a Web Components polyfill, so you can write raw Web Components if you want to. Polymer is really just some syntactic sugar over that (and other specs thrown in, like html imports, templates, etc). That said, these aren't really the same kind of libraries at all, so I'm not sure why this is such a x vs y thread. Ideally, react and web components are fully composable, and it doesn't really matter where the element came from.
- hcarvalhoalves 12y ago
  It doesn't matter if they keep pushing a standard no one's using to actually ship. The only people I see excited about Web Components are Googlers.