4 ms·

Well, browser compatibility is still a big problem with Polymer. A simple click-and-select-stuff-quickly-while-moving-mouse-around test can often lead to focus

Well, browser compatibility is still a big problem with Polymer. A simple click-and-select-stuff-quickly-while-moving-mouse-around test can often lead to focus and/or the selection being "stuck" on Firefox -- even on simple widget demo pages. (This was a few months ago, things may have improved.) Probably on other browsers too. React works perfectly today. > I see 2016 as the year that people slowly begin to realize that while components ARE the future, you don't need big frameworks or libraries or 4000 node modules. What would you call Web Components (polymer) if not a "big framework or library"? That's effectively what Shadow DOM, custom elements, &c amount to -- it's just standardized and shipped with the browser. (Yes, that's a massive advantage, but not until we have 100% working shims and/or browsers that comply 99%+ with the specs.) EDIT: I should also say: Polymer itself is quite opinionated about how you should structure your custom components (and thus JS code) and this may be a disadvantage to some. This doesn't seem to affect Web Components per se, so that's something. Also, something like the virtual DOM will probably still be needed for speed.

plexicle 11y ago
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.)
grayrest 11y ago
> This was a few months ago, things may have improved. Polymer improved substantially with the 1.0 release. It was basically a full rewrite so if you checked it out before then, you'll have to re-check.
- lomnakkus 11y ago
  Nah, it was definitely post-1.0. (Don't get me wrong, things have improved massively, they're just aren't quite there yet. :))

plexicle 11y ago

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

grayrest 11y ago

> This was a few months ago, things may have improved. Polymer improved substantially with the 1.0 release. It was basically a full rewrite so if you checked it out before then, you'll have to re-check.

lomnakkus 11y ago
Nah, it was definitely post-1.0. (Don't get me wrong, things have improved massively, they're just aren't quite there yet. :))