Hacker News Reader

Comment by shadowmint | Hacker News Reader

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.

View on HN

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

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.

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

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.

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.

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

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

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)

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.

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

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

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?

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.

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.

Then you may not be aware of Mozilla's continued interest in WebComponents[0][1].

[0]: http://mozbrick.github.io/ [1]: http://www.x-tags.org/

Reply on news.ycombinator.com