I should say, my post was more about web components and less about Polymer. Polymer is just one way to do it right now, and you're right, it is opinionated.
You don't need a library at all if that's what you prefer.
The polyfills are there now and they are solid. Webcomponents.js is small and effective. The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.
> The polyfills are there now and they are solid. Webcomponents.js is small and effective.
This leads to a tangential point which I find somewhat interesting to ponder: If the polyfills are good enough... then why does this actually need to be a browser standard?
I'd really like to get to a place where we (collectively) find some sort of minimal API-type "thing" that browsers need to support such that everything else can be polyfilled. I would even go so far as to include things like future ES standards in that, such that you could just "plug in" (in the page, not the browser per se) a shim for ES2015 and it would work near-natively. I know Microsoft Research had at least one project going in this direction -- unfortunately its name escapes me at the moment.
> The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.
FWIW, that may very well be true. AFAIR all my tests were done with the paper elements.
I definitely agree that Web Components in some form is the future of application development for the web -- unless we're talking stuff that mostly just wants to use the browser as a delivery platform like WebAssembly. Of course that may change if/when WebAssembly can interface well with the GC/DOM/etc. (Well, come to think of it Web Components might also be massively useful for authoring documents sanely using custom components for higher-level semantic elements, but that's a digression.)
Just FTR as well, I have actually implemented a small application using Polymer just to get a feel for what it's like. Overall it was reasonably pleasant as Web development goes, but it's really disconcerting that all the state[1] passed down to sub-components gets represented using attributes-but-not-really-because-they're-not-primitive-types-any-more.
[1] At least, that's the idiomatic way, AFAIUI from Polymer documentation.
EDIT: I should edit while I can: I semi-believe that Web Components is sort of along the right lines wrt. what needs to be standardized (and perhaps WebAssembly + an interface to the WebComponents API can do the rest?), but frankly I probably don't have nearly enough expertise in this field to even have an opinion. So there. :)
This is what the Extensible Web Manifesto is -- an agreement from browser vendors to build in low-level primitives so that things can be implemented in user space:
Thanks for pointing this out. I (as I'm sure many others) was not even aware that such a thing existed.
Having said that...
- Is that the actual manifesto? I couldn't find any link to any more detailed document, but maybe it's a browser/adblock thing.
- If yes, then... I agree with nearly all of it (having just skimmed it), but it seems a bit... bland and fluffy (as opposed to concrete).
That's not exactly what I was imagining with my ever-so-specific "API/thing" nomenclature :) I was thinking more along the lines of a "universal bytecode for web", but a) not just for code, and b) one that actually works. Maybe Java 25 will get us there, who knows :)
That's a little closer, but AFAICT it's just a bunch of added "signatories" -- again from a skim-read.
In the long run, WebAssembly may be it. As of the promised-1.0 it's just a way/excuse to run C/C++ code on the browser's VM with some GL/Canvas mixed in there. I mean, I understand marketing a FPS-game-in-the-browser as the be-all and end-all thing, but that's not my market or end game :).
It'll be really interesting to see what happens with WebAssembly 1.1, 1.2, 2.x... Will they be the ones to surmount the insurountable obstacles?
(I've been around for quite a long time in the industry, so... having learned things and just how much the last 20% takes, I tend to temper my optimism quite a bit.)
That's fair enough, but I guess I just don't think there's enough... commitment in that?
I appreciate the point about meta-standards vs. standards. I think I'm more looking for concrete technical standards (to obviate all others before them![1]) than meta-standards. The web has advanced significantly in the last few years, perhaps even as a result of this meta-standard, but ultimately I'm skeptical that competition between entities that don't have the same goal will "succeed"[2] in any objective sense. The point me be a a bit muddled at this point, but think "principal agent problem".
[1] Because that always works! (Find your own XKCD)
[2] Yeah, I know. Everybody has a different idea of what that means.
> but it's really disconcerting that all the state[1] passed down to sub-components gets represented using attributes-but-not-really-because-they're-not-primitive-types-any-more.
React, Angular 2, and probably most other frameworks with templates do the same thing.
If it makes you feel any better, the key point for me is that these are not HTML, they're templates embedded in HTML via a DSL. This DSL is valid HTML, but it's necessarily interpreted and modified by the template system.
Also, it's great that these values are not primitives. One of the persistent detractions (made by a core React dev I think) against Polymer is that "everything is a string because attributes", which is just wrong. As you note, Polymer uses attributes in template to declare binding to properties in the resultant DOM, which can be of any type. I think it's great that you understand this distinction, even if you don't like it :)
You don't need a library at all if that's what you prefer.
The polyfills are there now and they are solid. Webcomponents.js is small and effective. The simple click-and-select-stuff(...) that you are referencing about are probably specific to some bloated Paper elements. That's not what I'm talking about here.