4 ms·

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

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.

lomnakkus 11y ago
> 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. :)
- spicyj 11y ago
  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: https://www.w3.org/community/nextweb/2013/06/11/the-extensible-web-manifesto/ https://www.w3.org/community/nextweb/2013/06/11/the-extensib... (Of course, higher-level APIs still get added.)
  - lomnakkus 11y ago
    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 :)
    - magicalist 11y ago
      > Is that the actual manifesto? No. Actual manifesto: https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/
    - spicyj 11y ago
      I guess this is the real thing: https://github.com/extensibleweb/manifesto/blob/master/README.md https://github.com/extensibleweb/manifesto/blob/master/READM... Perhaps WebAssembly is close to what you think of as a "universal bytecode"?
      - lomnakkus 11y ago
        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.)

lomnakkus 11y ago

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

spicyj 11y ago
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: https://www.w3.org/community/nextweb/2013/06/11/the-extensible-web-manifesto/ https://www.w3.org/community/nextweb/2013/06/11/the-extensib... (Of course, higher-level APIs still get added.)
- lomnakkus 11y ago
  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 :)
  - magicalist 11y ago
    > Is that the actual manifesto? No. Actual manifesto: https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/
  - spicyj 11y ago
    I guess this is the real thing: https://github.com/extensibleweb/manifesto/blob/master/README.md https://github.com/extensibleweb/manifesto/blob/master/READM... Perhaps WebAssembly is close to what you think of as a "universal bytecode"?
    - lomnakkus 11y ago
      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.)