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

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.

But still creating domnodes on each invocation. React is shielding the dom

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.

I think they meant that, if you build your stateless web component, you're likely going to have to either recreate DOM elements on every tick (if you're doing something like ng-repeat) or set a bunch of attributes and whatnot... unless you set up some caching mechanism

VirtualDOM is basically that caching mechanism

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

> under-specified, incomplete, undocumented, informal framework.

Sometimes referred to as 'micro framework' architecture in Software Development vernacular. Let the down-votes begin!!

Maybe not. Maybe there is something else on the horizon.

I actually think frameworks are too monolithic, and we feel the pain of that, but no one has figured out how to do something more granular yet. To a large extent that's a community administration problem, not a technical one, which is why you don't see a lot of computer scientists trying to do it. Though it will require some technical chops too.

Node/NPM, and UNIX before it, are attempts in this direction. It's not really gelling yet though. The various component systems are trying, but inevitably fail because they are trapped in a single layer of the framework stack. I think we need a few more breakthroughs in social organizational strategies (things like Flickr, Uber, Bitcoin, etc) before it becomes obvious how to do it.

What we really need is a web standard that allows devs to plug-in a custom templating language extension.

It's dumb that the browser renders HTML, a framework bootstraps, parses the template, then re-renders the view.

90% of the front-end frameworks exist to provide templating + some special set of features.

If we standardize a pre-render hook to plugin custom templating engines then frameworks can shift to focus only on their implementation specific strategies (ex data binding).

This is too damn good!

Thus proving Greenspun's tenth rule [1] also applies to JavaScript:

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

This is beautiful.

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

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.

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.

Amen.

Sounds like a viable strategy. That's basically my device upgrading plan. Wait for three new releases (in the same series) then "Alright, time for a new tablet/phone/laptop!" I haven't quite jumped on the watch bandwagon yet.

Generally I wait for a winner or something I like then stick with it.

I'm still using knockout.js since I've used it for two years, it's maintained and each release is a big improvement in features and recently speed (massive improvements in 3.4).

Its not that react et al don't interest me but the switching costs are real and I'm not sure what they'll look like in a year.

Nah, that's a few years in the future. Typically it takes about 5-10 years for programming trends to reverse themselves.

Yes this may have been true a few years ago but no longer...we are in the of age of programming-trend warp drive where they may reverse every 6 months or less.

another option: a lot gets pushed back to the backend rendering, where it started.

Ummm, no.

How about, everything shifts to isomorphic rendering. Generate an interactive view stub to display on the client while the app bootstraps.

There's no justifiable reason why we should have to refresh and completely re-render the page every time the view changes.

From a 'business perspective' it's worthwhile to have front-end devs build all of the view logic (incl templating, routing, etc) on the front-end while the back-end team focused solely on building APIs, microservices, and data management infrastructure.

If back-end devs are responsible for everything incl templating, the front-end devs responsibilities are limited to... Photoshop, HTML, and CSS?

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

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.

I love mitril so much. It would be soooo much better with a lisp syntax, though.

I wrote a parenscript wrapper for it.

[edit] No time tonight to make it pretty and publish it, but here it is[1]. Usage is identical to my parenscriptx[2] (a React tool I wrote that I based this off of).

1: https://gist.github.com/jasom/4ab84354fda405a8f67a

2: https://github.com/jasom/parenscriptx

I was thinking more along the lines of lispyscript[1]. It's not as good as SPOCK[2], or clojurescript[3], but there's less overhead than clojurescript, and SPOCK is known to stretch your javascript implementation in odd ways.

1: http://lispyscript.com/

2: http://wiki.call-cc.org/eggref/4/spock

3: https://github.com/clojure/clojurescript

parenscript is quite low overhead; it's approximately lispyscript with common-lisp macros instead of whatever lispyscript has (it looks like some kind of pattern-matching style; there's only one macro example on the lispyscript documentation and the link to an article about more details is dead). In any event if you know lispyscript you can probably translate my code; it took me only a couple of hours to write the initial react version, and another 45 minutes or so to translate to mithril.

eslisp[1] might be up your alley

[1](https://github.com/anko/eslisp)

Thanks for the pointer, Leo.

Also, thank you for the mithril blog. It is amazing.

Everybody else, if you haven't read the mithril blog[1], YOU SHOULD BE READING THE MITHRIL BLOG. Even if you never plan to use mithril, you'll probably learn something interesting.

1: https://lhorie.github.io/mithril-blog/

I can't tell if you're joking.

I personally despise Lisp syntax.

...Well then, you probably wouldn't like Mithril.

Typically, Mithril uses raw JS lists, function calls, and objects to create its vdom, which you have to directly manipulate. Like using react without JSX. With a lisp syntax, you might write the end of an expression as )))))), as opposed to in JS, where you might write )])]}); or something similar.

I've actually been considering trying Mithril.

But it's not strictly parenthesis that bother me. You're right in that )]}) is actually far more annoying. I try not to nest that deep in JS if I can help it.

Arrow functions reduce the pain. Not passing array literals in function calls helps as well. Angular seems like the big culprit that injects [] into the middle of an argument list, for me anyway, and using that syntax is optional.

Well, mithril requires a LOT of array literals and object literals in your function calls. http://mithril.js.org/getting-started.html shows todomvc in mithril. That template would be much more compact, uniform, and readable with a lispy syntax.

I see. You're right, that is somewhat ugly.

I've actually considered the idea of hacking a JSX compiler to spit out Mithril output.

If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.

That actually already exists: https://github.com/insin/msx

Awesome! Thanks for the link.

It did seem like an obvious thing to do. I probably would have searched for and found this before doing any actual work on JSX, but I'm glad to know it exists already. :)

Lisp syntax and idioms make mixing markup with code really elegant and simple. That's why I want to write mithril with lisp syntax.

If you want just the vdom model, look at https://github.com/Matt-Esch/virtual-dom I remember at one point mithril's vdom implementation was based on virtual-dom but I can't seem to find any documentation to back this up.

Probably a coincidence. I only found out about virtual-dom after I released Mithril.

Honestly memory is such an untrustworthy thing!

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/

Which two?

It's missing ractive, which is one of the oldest virtual DOM implementations build by the interactive team at The Guardian. I use it daily for CertSimple.

I ran across [1] last week. I saw another (not ractive) a month ago but I've forgotten the name.

[1] https://github.com/Lucifier129/react-lite

>State control

It took me a long time to figure that was the point and it still kind of seems you could write in good old plain javascript:

x = "some state"

if (you want to change it) { x = "some other state"

    DrawThingOneThatDependsOnx()

    DrawThingTwoThatDependsOnx()}

Rather than spending days learning the tons of bloat, tools and tech that effectively does that for you under the hood anyway?

(Plus with vanilla js running up to 40x faster than React https://news.ycombinator.com/item?id=9824884 apparently)

> vanilla js running up to 40x faster than React

That particular link is a strawman argument. React isn't magically fast. Writing a 5 line shouldComponentUpdate would normalize the performance.

If you think you can do better with something else, feel free to ignore the React hype. For my part, I've been doing frontend full time more or less exclusively since 2005 and have tried dozens of libraries/frameworks in earnest. I don't know of a better way to write client side code.

How do you know what things depend on X? if you have Z=Y+X, do you also refresh Z?

State control is not simple when you have many moving parts. A very good solution (which both Angular and React bring to the table without destroying performance most of the time) is to remove all the moving aspects to the parts. This doesn't matter in microbenchmarks, but in real apps, having something be slightly slower but bug-free is better than fast but wrong.

I like Douglas Crockford's "Class Free OOP" approach for managing dependencies and composing functions:

  function constructor(spec) {
    let {member} = spec,
    {other}  = other_constructor(spec),
    method   = function () {
          // accesses member, other, method, spec
    };

    return Object.freeze({
      method,
      other
    });
  }

but prefer to use an immutable data structure instead of Object.freeze().

All application state can be stored in a single "Atom" (i.e immutable data) and all message passing can be achieved through CSP channels.

When dealing with the DOM, 'incremental-dom' is a nice option.

Of course, separating pure functions from side-effects inducing code is key to maintaining control.

This is my approach when going "framework-less".

To add to the Clojurescript point: dead code removal. CLJS uses Google Closure and can take part in it's advanced compilation and dead code removal feature. All of the cruft that isn't used, that is abstracted away in CLJS anyway, can be removed when building your code for production.

https://developers.google.com/closure/compiler/docs/api-tuto...

Not an excuse for baroque frameworks though.

You can manage state like that with web components as well: store state in one root object, only pass state down the tree, only build DOM based on the given state, use events to communicate changes back up the tree.

The end result is very React-like in behavior, but completely interoperable with other web components, and not require a framework at all.

This is what React does if you don't use Flux/Redux/something similar and it don't scale very well to medium sized or larger codebases.

Web Components hasn't been supported by all browsers (and probably still isn't) and has had some problems with grouping components and loading them. I can use React today but Web Components is something I might want to use in 2-3 years.

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

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.

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:

https://www.w3.org/community/nextweb/2013/06/11/the-extensib...

(Of course, higher-level APIs still get added.)

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

I guess this is the real thing:

https://github.com/extensibleweb/manifesto/blob/master/READM...

Perhaps WebAssembly is close to what you think of as a "universal bytecode"?

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 is it (and there's quite a bit of thought in those bullet points), but not sure what you're looking for.

It's a manifesto for how to approach writing standards for the web, not a standard itself.

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.

> Is that the actual manifesto?

No. Actual manifesto:

https://extensiblewebmanifesto.org/

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

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

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

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.

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

Non-comprehensive list of Google properties and Chrome-team efforts using: https://github.com/Polymer/polymer/wiki/Who's-using-Polymer%...

Obviously doesn't include stuff in the works :)

YouTube Gaming & the new Google Play Music are both built with Polymer, both moderately complex consumer facing sites.

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.

Google Play was poorly made

https://play.google.com/store/apps/developer?id=itdisplayswh...

Kinda beside the point, and I'm not sure the play store is using the same tech stack as play music. Two different things

???

https://www.madewithangular.com/#/categories/google

I believe people generally mean that Google isn't using it for any of their core products: Gmail, Search, Google+, Photos, YouTube, Google Play, Calendar, Drive, Maps... none are built with Angular.

adwords is not a google core product? the angular team works together with the adwords team

Adwords was not in that list (madewithangular) so I simply supposed it wasn't made with angular. Neither is Analytics, or any of the tools I use from Google.

If Adwords is Angular then that's one big project on Angular (clap clap clap). However, all I ever heard was that they were planning to move to Angular2 on Dart. I wonder how that worked out.

edit: just editing to add that I´m not doubting that Google is using Angular2 in some projects, like their internal CRM (Green Tea or whatever). I simply wanted to point out that it's not used _extensively_ in their main consumer facing sites - the ones you get links to when you click on their apps dropdown menu.

Pfft, Adwords might be responsible the lion's share of Google's 522 billion dollar market valuation, but to call it "core"? That's a bit of a stretch.

Um, that was sarcasm right? You might want to add a /s then.

It's important to note that Google does give it's developers the freedom to choose their own tools. If a team isn't excited about Angular or Polymer, it's not forced on them.

If I was building a webapp that was going to have hundreds of millions of users, I'd think twice about grabbing an off the shelf JS library.

Google is using (or has used) Polymer in Google Music, Santa Tracker, Google I/O Web App, chromestatus.com, and likely a few others I'm forgetting.

Google has been using Angular 1.x for DoubleClick since 2012 (http://angularjs.blogspot.com/2012/06/doubleclick-super-powe...). I think it's fair to say that it's one of their most important products.

Chrome's PDF viewer is written in Polymer

> Javascript (or framework) fatigue is just a 'transition problem'

Exactly, same thing happened early on in Ruby/rails community.

> 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

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.

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.

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.

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/

EDIT: Added a little more to explain my reasoning.

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.

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

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

Unfortunately it's not so cool now that their GitHub API limit has been reached. That docs page is completely blank for me.

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.

>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

Meanwhile I am quite happy to have returned to native UIs....

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

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.

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.

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.

What do you think about Ember's mobile performance problems?

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/

Disclaimer, I work on & with Ember.js (and I didn't work on 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 (written in TypeScript), V8 with turbofan and the team, working together to improve JavaScript in the browser for everyone.

Thank you! This explains so much. I hope the Android experience gets better but I fear my next phone will have an Apple logo on it.

Have you seen this? https://meta.discourse.org/t/the-state-of-javascript-on-andr...

This problem is not Ember but JavaScript in general.

You can write TypeScript without a big framework around it.

Is there any substantial apps written in Polymer yet?

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.

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.

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.

The Google cloud developers console is most probably built with polymer

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.

Google Play Music and Youtube Gaming are two of the larger ones.

FWIW, part of the reason for Angular2's 'cringe-inducing template syntax' is so that it'll play nice with Web Components / Polymer.

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!

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

More in depth design stuff here: https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG...

Demo: ng2 + google-youtube polymer element : http://plnkr.co/edit/yh0ACeu6g5n8D7YuhJvg?p=preview

Great, looking forward to reading these. Thanks!

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

[2] https://docs.google.com/document/d/1kpuR512G1b0D8egl9245OHaG...

[3] http://genshi.edgewall.org/

[4] https://github.com/angular/angular/issues/133#issuecomment-6...

[5] https://github.com/angular/angular/issues/133#issuecomment-7...

[6] https://github.com/angular/angular/issues/133#issuecomment-7...

[7] https://github.com/angular/angular/issues/133#issuecomment-6...