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