Echo JS 0.11.0

actually my boss forces me to use Angular

Exactly. I found the article content to be technically low and sometimes incorrect, yet I can't help but upvoting this because I totally share the feeling of dispair and distress of the author. 

I work on a large Angular 2 project for a year now and the development has been chaotic compared to my previous experiences with Angular 1. At the time, we decided to go with ES6 instead of TypeScript as the Angular team made this promise that we could have the choice of the language. The truth is, there is no documentation and tooling for non-Typescript users and migrating from ES6 to TypeScript on big projects is much more complicated than expected.

Currently we have major issues such as the bundle size (1.7 megabyte only for angular and related dependencies) and render performance in our views (fixed by changing ChangeDetectionStrategy and manually updating the view, which makes angular zones mechanism almost pointless). Debugging is also terrible since angular and zone call stacks are hiding all the valuable information in the exceptions.

Today I bitterly regret this choice and would not recommend Angular 2 to anyone. I worked with dozens of JS frameworks in the past but none of them has leaved me to such a state of mind of frustration and discouragement. I know it sounds like whining and my testimony may not be very constructive but it needed to be told. Angular 2 is terrible.

Official documentation already provides JSFiddle starters : http://vuejs.org/examples/index.html

gtfo with your fake accounts

I don't understand why ES2015 classes suddenly become mandatory. They have been described as syntactical sugar over the prototype-based OO pattern and are already massively transpiled to ES5. If classes are absolutely mandatory for custom elements v1, how does Polymer manage to polyfill this specification while supporting IE11 ?

You can use both babili and es2015 presets, this is what makes babel awesome :)

I contacted them and asked them to stop. They say it's a mistake, we'll see: https://twitter.com/jsrepublic/status/761619085121687552

IMO the JS module situation has always been terrible, and ES6 modules are the best way out we have. What made the situation complicated is not only the fight between AMD and CommonJS, but also the differences in the libraries implementations and the arbitrary use of global keywords such as "require". Picking one of these implementations wouldn't help at all, it would break backward compatibility and would result in even more confusion.

Once we have browsers native support (which should happen soon based on the recent announcements), AMD and CommonJS will no longer be needed and will probably disappear in a few years. That should be enough to convince people to bet on ES6 modules for their next project.

Thank you, I appreciate the effort and the documentation. If you want to propose a full-polyfill behaviour, you could make a new module for that. Then you won't have to worry about the code size when adding the missing parts of the standard like valueAsDate: https://gist.github.com/sylvainpolletvillard/0aa9df9c180cd007e5e1

Maybe you can use rollup or similar to bundle moment inside this lib and use tree-shaking to reduce the final size ?

About the polyfill, of course it is more complicated than that. There's no test of support, the value formatting is different, the optional HTML attributes are not handled etc. This would imply major changes in your library to mimic the standard.