13 ms·

To me it really feels like Polymer is taking all of the pros from both of these "libraries" or "frameworks" or whatever you want to call it and none of the cons

• lucidrains 11y ago
  Is there any substantial apps written in Polymer yet?
  • sehr 11y ago
    https://gaming.youtube.com https://gaming.youtube.com is probably one of the bigger ones, but of course it doesn't support mobile so you can only check it out on desktop.
  • plexicle 11y ago
    That's exactly the wrong question. The right question is: "are there any substantial apps that take advantage of native Web Components (polyfill or not)?" The answer to that is: "yes, a lot." Polymer is just one way to write the components. X-Tag is another. Pure JavaScript is another. Use one of them or use them all. No big overarching framework required.
    • elsigh 11y ago
      But it's not just about writing individual components when you build an app (you need something like a router still for instance). I say this as someone who rather likes the model Web Components espouses. Developer ecosystems matter a lot - for development, debugging and hiring. At present you have a great many more resources/communities to reach out if you go with React. When you get stuck with Web Components or polymer, and you will get stuck, you are a lot more on your own. Also, for building you are, at least presently afaik, limited to vulcanize instead of the richer set of tools out there for more typical patterns. Vulcanize is cool, but again - if you get stuck, and you will if you do something complex - you have to rely on a much smaller community to help you out.
  • fouadf 11y ago
    The Google cloud developers console is most probably built with polymer
    • brandonhall 11y ago
      I just looked at the source and it's built with Angular and Angular Material. The UI for the Cloud Console app is incredible work.
  • rictic 11y ago
    Google Play Music and Youtube Gaming are two of the larger ones.
• lomnakkus 11y ago
  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. :)
• Kwastie 11y ago
  Why did Google create Polymer? Google isn't using it. This is almost the same 'problem' with "AngularJS by Google", it's almost never used by Google. Edit: The reason I like React more is the fact that Facebook uses it in a high traffic production setting. Edit 2: I think the whole Javascript (or framework) fatigue is just a 'transition problem'. Old tools are getting replaced by new tools, causing confusion..
  • butabah 11y ago
    Chrome's PDF viewer is written in Polymer
  • sehr 11y ago
    YouTube Gaming & the new Google Play Music are both built with Polymer, both moderately complex consumer facing sites.
    • ihsw 11y ago
      I have been extremely impressed with Google Play Music, I use their web client on a daily basis. I did not know about YouTube Gaming, it looks very interesting.
    • mkawia 11y ago
      Google Play was poorly made https://play.google.com/store/apps/developer?id=itdisplayswhateversattachedtheid https://play.google.com/store/apps/developer?id=itdisplayswh...
      • sehr 11y ago
        Kinda beside the point, and I'm not sure the play store is using the same tech stack as play music. Two different things
  • debaserab2 11y ago
    ??? https://www.madewithangular.com/#/categories/google https://www.madewithangular.com/#/categories/google
• grayrest 11y ago
  > React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For what? State control. The most important thing about a React app is that you can write your code to have every bit of application state inside a single variable. It gets you hot code loading, trivial testability, and session recording/replay. I can actually test the app without having to use selenium (which I hate). These aren't really benefits from React per se but from the vdom approach. My apps are in Clojurescript and don't use the majority of React's features so replacing it with an alternative vdom implementation is on my todo list for this year. I haven't used it in anger, but Polymer is at the top of my list if I needed to write an app to integrate with a third party or something where I didn't have app state control.
  • plexicle 11y ago
    Re: state control. The "mediator pattern" is a cool way to write some apps and it addresses a lot of these concerns (with a parent app-element). It's not Polymer specific, but here's a cool video going into a little more detail: https://www.youtube.com/watch?v=ZDjiUmx51y8 https://www.youtube.com/watch?v=ZDjiUmx51y8
  • aidenn0 11y ago
    Note that mithril is much more lightweight than react, offers a similar vdom model, but has a completely different algorithm for deciding when to redraw. I actually think that mithril's redraw algorithm is less intuitive to use than react, but it is way simpler, which has its own advantages.
    • grayrest 11y ago
      There are a bunch of alternative implementations. The vdom benchmark [1] is a fairly good list but I've run across at least two more that aren't tracked there. [1] http://vdom-benchmark.github.io/vdom-benchmark/ http://vdom-benchmark.github.io/vdom-benchmark/
      • knite 11y ago
        Which two?
• deleted 11y ago
  [deleted]
• ralmidani 11y ago
  There is more to web development than building components. There are also things like accessing a backend, building authentication services, etc. that developers need to worry about.
  • plexicle 11y ago
    Are you under the impression these things aren't possible (or even easier?) with web components or vanilla JS? You don't need a big framework for any of that.
    • ralmidani 11y ago
      I'm building an app with Ember, and I like how it abstracts away the more tedious aspects of web development without preventing me from moving to a lower level of abstraction when I need to. I've built a small app in vanilla JS, so I know what the alternative to using a framework is like. Doing XHR by hand is not easier than using Ember-Data. Writing custom JS components is not easier than extending Ember's Component class.
      • voltagex_ 11y ago
        What do you think about Ember's mobile performance problems?
        • lightblade 11y ago
          Have you seen this? https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889 https://meta.discourse.org/t/the-state-of-javascript-on-andr... This problem is not Ember but JavaScript in general.
        • iamstef 11y ago
          First of all, let me share a wonderful (and performant) mobile app, written in ember. It uses ember-data to connect/normalize the iTunes api, and provide a slick fast mobile experience. https://fnd.io/ https://fnd.io/ Disclaimer, I work on & with Ember.js (and I didn't work on https://fnd.io https://fnd.io) I've worked on several mobile web apps using ember, and performance did require being careful, but often "being careful" was nicely aligned with the mobile UX people expect. Small screen, put less stuff on it. etc. Often times, we do see issues with ember on mobile, typically this is due to deeply nested loops of UI components being rendered. And most often, performance on mobile was an after-thought. PSA: Regardless which framework (or no framework) you use, if you are shipping to mobile. Test/develop on your target mobile devices from day 1, you will not have any surprises, and you can catch performance related issues before they fester. As for the discourse post, there are some issues ember is working to improve. If one reads further, it outlines the largest concern being the growing gap between JSC (Safari, which offers near desktop performance for discourse on mobile) and V8 (which doesn't do so well on mobile for discourse) performance. Year over year, the iOS experience is improving, but the android/v8 experience does not appear to. The TL;DR of the issue (as is currently understood), is JSC handles dynamic code better, whereas v8 does not (yet) and Ember should both reduce the dynamism and continue to do less work. Which will continue to improve the experience for all consumers. This is actually quite an interesting issue with lots of details, I could go on, but this is likely not best place for anything in depth. The important part being, all parties involved are working towards (and together) on a better faster more wonderful future. Ember with another (faster) iteration if its rendering engine: https://github.com/tildeio/glimmer https://github.com/tildeio/glimmer (written in TypeScript), V8 with turbofan and the team, working together to improve JavaScript in the browser for everyone.
• munro 11y ago
  Polymer is a polyfill for web components, which is an imperative way to sandbox JS/CSS/DOM. It's a very useful tool. Poylmer doesn't simplify UI development like React does, the components have to be statefully managed, and always will be because creating/destroying polymer/web components is expensive. The beauty of virtualdom is the previous state doesn't matter in deciding what the new UI should look like, or if a component should be added/removed. Simply render off the current state, which is cheap, and then the previous & current virtualdom is diff'd and applied to the real DOM. Web components are exciting, and React can leverage it to do CSS sandboxing, though people are already effectively doing this [1]. And the cool thing with declarative programming is we can swap out implementations with more performant ones. [1] https://github.com/gajus/react-css-modules https://github.com/gajus/react-css-modules
  • spankalee 11y ago
    To clarify, Polymer relies on web components polyfills. The polyfills are separate and usable by any other project. Also, components don't have to be stateful. An element can be viewed as a function invocation which accepts attributes, properties and children and returns DOM. An element which deterministically renders some DOM based only on those inputs is very much like a pure function.
    • neoeldex 11y ago
      But still creating domnodes on each invocation. React is shielding the dom
      • spankalee 11y ago
        React still eventually creates DOM nodes eventually, so I'm not sure what you mean. How a custom element produces its DOM nodes are entirely up to it, and several approaches fit with a pure functional view of elements: 1) re-render and replace the entire component DOM, 2) Use a VDOM to patch the component DOM, 3) Use incremental-dom to update the component DOM, and yes 4) template systems like Polymer's can be easily used in a pure functional approach. The key to being "stateless" isn't in abstracting away the DOM, it's in only using the inputs (attributes, properties, and children) to determine the DOM structure, and only allowing the host of an element to modify inputs so that the element behaves more like a function. It's similar to mutable object that never modifies its own state, only has public state, and whose methods are pure. Method behavior is fully determined by state that the owner controls.
• Svenskunganka 11y ago
  I think you're gonna like Aurelia[1]. It's badass compared to Angular 2, React & Polymer. You get this really, really nice feeling of writing pure Javascript. It's smaller than Angular, strictly follows Javascript standards which is soooo nice. No {{bindingVariable}} but instead: ${bindingVariable} // Just like in Javascript template strings! Binding? Sure: <input type="text" value.bind="variable"> Two-way? Of course: <input type="text" value.two-way="variable"> One time? Yep: <input type="text" value.one-time="variable"> The templating is so simple, as it follows the APIs as well, for example - how would you bind markdown to the innerHTML of an element? Well, just pass the variable through a ValueConverter in your bind: <div inner-html.bind="variable | markdown"> It is also pluggable. You can replace almost everything in Aurelia with your own implementation very easily. [1] - http://aurelia.io/ http://aurelia.io/ EDIT: Added a little more to explain my reasoning.
  • voltagex_ 11y ago
    On a fast i7 and a 50 megabit connection I get: * A flash of unstyled content * No text on first load for 5 seconds * A one second delay switching between pages on the docs page. Bring back text/plain.
  • blackkettle 11y ago
    Are there any examples using this in the wild? I couldn't find any 'Sites powered by Aurelia' page on the site. Would be interesting to see some full fledged sites (besides the project site).
    • Svenskunganka 11y ago
      Well the docs[1] are built using Aurelia, and it's really cool as it fetches the framework API directly from their GitHub repos via GitHub API and caches it on clients computers. I am currently in the process of re-building our company website with Aurelia (previously Angular 1.X). [1] - http://aurelia.io/docs.html http://aurelia.io/docs.html
      • exogen 11y ago
• bryanlarsen 11y ago
  One thing I like about both Polymer & React is that they encourage you to treat your apps as a composition of components, as opposed to each page being a wall of HTML with a few variables substituted in. That being said, React really makes it easy for those components to be tiny little things that do only one thing, that compose nicely, and that are easy to understand. There's a heuristic in programming that if a function is more than a page in length, it's probably too complicated. The same heuristic applies to React: if your component (JS, JSX & CSS together) is more than a page, it's probably too big. Just the act of splitting apart the JS, JSX & CSS encourages the components to become much larger.
• kbenson 11y ago
  This will only happen when there isn't a significant portion of new programmers entering the field/language/type of work. As long as there are people that don't know how to write pure, well-written and fast web apps, large frameworks will have a place. This is a good thing, because the more new programmers that try to figure this stuff out themselves the more clusterfuck projects we have. Frameworks allow for an easy onboarding process, where the people that need to reach deeper to accomplish something then look how to do that, and learn as they go. There are parallels here with languages. Perl, which garnered a reputation as a write-only language, has seen a dramatic increase in the quality, legibility and effectiveness of modules over the last decade, and this corresponds well with the lack of an influx of new programmers (but with a minimum core of users still present to implement new modules). That said, there are many, many other problems when you don't have enough new blood flowing into your ecosystem, so I don't recommend it.
• vikingux81 11y ago
  At work we are using Polymer / Web Components since version 0.5 and have been enjoying it's structured approach. I was skeptical at first to use html tags to add data models, AJAX requests and non-visual parts of a web app. After the initial shock though it does result in more declarative code and helps our codebase stay organized. Long term, the investment in web components makes sense as they become standard and native to most web browsers.
• JDDunn9 11y ago
  I've been using just the custom elements polyfill (6KB gzipped) and love it. I definitely think web components will do to React what querySelector did to jQuery. It's so nice to get rid of the bloat of these libraries, get out of dependency hell, and just write pure javascript again.
• qwertyuiop924 11y ago
  >Polymer is a fraction of the size <laughs> Polymer is a whale. And after Angular, I am NOT getting on another Google-funded hype train
• pjmlp 11y ago
  Meanwhile I am quite happy to have returned to native UIs....
• mambodog 11y ago
  > This is the year of framework fatigue. This is the year of the framework fatigue meme. Next year is the year everyone realises why we had frameworks and tries to salvage the mess they made last year, when they wrote an app 'without a framework' and ended up with an under-specified, incomplete, undocumented, informal framework.
  • ykka 11y ago
    This is beautiful.
    • noir_lord 11y ago
      It's the circle of life. I've been programming since I was a kid in the 80's, after a while you learn to stand back sometimes and let the bandwagon roll on past or as I've joked in the past "these days I simply get on every third bandwagon".
      • at-fates-hands 11y ago
        Yes, it would seem as a developer there is a certain amount of bandwagon jumping going on in the last few years. You're very right, you really have to pick your battles. It's interesting since I'm doing more contract work and finding out that one shop uses Angular and another Backbone and a third React. Which one should I really learn and focus on, when nearly every shop has a totally different philosophy?? Even trying to pick the winners in these framework battles is getting exhaustive.
        • 91bananas 11y ago
          Truth is, it doesn't fucking matter. People are still building jQuery apps. The key is solving real world problems with nicely designed solutions. Doesn't matter what you do it in, how you do it. Just solve a problem.
          • noir_lord 11y ago
• voltagex_ 11y ago
  You can write TypeScript without a big framework around it.
• robwormald 11y ago
  FWIW, part of the reason for Angular2's 'cringe-inducing template syntax' is so that it'll play nice with Web Components / Polymer.
  • plexicle 11y ago
    Hey Rob- that was probably unfairly harsh of me. I have tried to like the syntax for the last year and I've had trouble. Anyway, I know you are a big contributer, do you mind showing me the discussion where we determined '*ngFor=' and '[(two-way)]=' was implemented to play nicely with WC? I would be interested in reading. Thanks!
    • robwormald 11y ago
      seriously, not offended :) you get used to it working on frameworks :D The longest (heated) discussion ever covers a lot of the reasoning: https://github.com/angular/angular/issues/133 https://github.com/angular/angular/issues/133 More in depth design stuff here: https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG0cFh0ST0ekhD_g8sxtI/edit#heading=h.xgjl2srtytjt https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG... Demo: ng2 + google-youtube polymer element : http://plnkr.co/edit/yh0ACeu6g5n8D7YuhJvg?p=preview http://plnkr.co/edit/yh0ACeu6g5n8D7YuhJvg?p=preview
      • plexicle 11y ago
        Great, looking forward to reading these. Thanks!
  • DonHopkins 11y ago
    No, it doesn't play nicely with HTML or XML. It's arbitrarily and pointlessly incompatible with HTML for no good reason, which is a huge easily avoided mistake, that makes me question the judgement of the people who designed (and evangelize) Angular 2. Please see my other posting about that. [1] My simple question that nobody's been able to answer yet: Name any benefits of the broken Angular 2 template syntax, that couldn't easily be achieved with a non-incompatible, HTML-friendly syntax. The "Databinding with Web Components" design document [2] makes the dubious claim that "The HTML attribute name of a databound attribute must be escaped in some way." That is precisely what namespaces are for, so why not simply use namespaces for the purpose they were meant to be used, the same way any well designed standards compliant template languages like Genshi [3] does, instead of inventing a new, non-standard, incompatible syntax? The entire point of the design of the XML namespace prefix syntax was so that it was compatible with XML syntax. Why do the Angular 2 designers think that was such a bad idea? I'm not the only person to point this out and have it brushed off and ignored by the Angular 2 team. "Regardless, it is inappropriate for the angular team to take a hard anti-xml stance." [4] "I wonder why ngnl presentation and current docs about templates still promoting []()# as parts of new syntax, when opening post in this thread contains 'element.setAttribute('[foo]', 'exp') does not work' and, especially 'SVG requires valid XML and []()# is not valid XML.' If these problems are solved somehow and we just don't know - please let us know." [5] "Given the lack of xml/SVG compatibility, I would say that the []()# syntax simply fails to meet the constraints, and should be eliminated altogether in favor of the prefix proposal." [6] "Please don't break HTML syntax :( I love Angular because I can write templates for it in any templating language like SLIM or HAML or Jade (you can't do it in Ember or React, for example). Introducing non-standard characters in attributes makes templating languages unusable (as well as syntax coloring and introspection in IDE)." [7] [1] https://news.ycombinator.com/item?id=10842902 https://news.ycombinator.com/item?id=10842902 [2] https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG0cFh0ST0ekhD_g8sxtI/edit# https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG... [3] http://genshi.edgewall.org/ http://genshi.edgewall.org/ [4] https://github.com/angular/angular/issues/133#issuecomment-66803057 https://github.com/angular/angular/issues/133#issuecomment-6... [5] https://github.com/angular/angular/issues/133#issuecomment-74645366 https://github.com/angular/angular/issues/133#issuecomment-7... [6] https://github.com/angular/angular/issues/133#issuecomment-74791116 https://github.com/angular/angular/issues/133#issuecomment-7... [7] https://github.com/angular/angular/issues/133#issuecomment-61248467 https://github.com/angular/angular/issues/133#issuecomment-6...
• thedufer 11y ago
  > React's perverted DSL and crazy toolchain JSX is very much optional, despite what the docs imply. I've had good luck with converting a DSL that I was using to spit out HTML to React components that made the transition fairly painless: https://www.npmjs.com/package/recup https://www.npmjs.com/package/recup
• deleted 11y ago
  [deleted]
• barrkel 11y ago
  Polymer doesn't work on IE9, much less IE8; banks pay the company I work for millions to produce software that works on the browser they have today.
• woanversace 11y ago
  Yes, you can do it without `polymer`. But I wanna work with it. `polymer` will give more free times to do something funny more than think about, how to expand this app, how to control all states... In my opinion, walk on BigBoy's shoulder will faster, and get wider vision