Supporting real classes

[knownasilya]

From our spike on microstates/ember#69

Basically, you have to include IE11 as a target for microstates to work, because the way classes are used doesn't work with Babel (Using a class without the new keyword). Many people are building apps that don't include IE11, so this is a big issue for performance.

[Robdel12]

Many people are building apps that don't include IE11, so this is a big issue for performance.

Hm, wonder what we can do here. We should absolutely keep supporting IE11 until those who rely on assistive tech upgrade and stop using it. Otherwise a ton of people won't realize their app is broken & unusable

[knownasilya]

The issue is that it only works if you build your app with the IE11 target. If you build it with evergreen browser targets only it won't work.

[Robdel12]

AHHHHHH, gotcha.

[taras]

We have an open PR #124 where changes to the build files are made to accommodate this problem in Node.js environment. The issues revolves around the fact that babel transpiled classes are not compatible with native classes.

When you configure ember-cli to target IE11, you're telling babel-env to target IE11 which causes's Ember app's classes to be transpiled. The right solution to this would be for ember-cli to actually build the src directory and allow it's rollup to take care of correctly tree shake and configure the environment.

We have the same issue in Funcadelic.

@knownasilya do you want to try another pairing session to try to figure out how we can get ember-cli to build from source?

[boazblake]

It maybe a better idea to drop the use of classes altogether? see https://davidwalsh.name/javascript-objects-deconstruction

[taras]

This article is from 2013. I think we can allow our industry to move forward without doubting fundamental conventions of application design.

Please forgive me if I sound dismissive but the whole concept that classes are bad is misguided.

[boazblake]

I would be interested in hearing why the whole concept of classes is misguided.
Did you even read the article or just look at the date? The age of the article is irrelevant as the premise is still correct. JS does not have inheritance as it has behavior delegation.

[taras]

@boazblake my point is that arguing against the use of classes in JavaScript is unhelpful. Classes have their benefits and tradeoffs. Unstructured POJOs have their benefits and tradeoffs.

Microstates APIs were designed to make working with immutable data feel similar to working with mutable data. Classes are a convenient way to assign names to shapes of data and provide an initialization life cycle event to plain objects.

The problem with using classes in JavaScript is not the language primitive but how this primitive is polyfilled for browsers that don't support classes. Babel transpiration of classes doesn't work with native classes. The classes transpiled by the library are not compatible with the non transpiled classes from the application.

[taras]

The problem boils down to the fact Babel-transpiled class can't extend from native class. One work around for this is to not transpile classes in Microstates but that breaks Microstates for projects that use Webpack and need to support IE11, because most Webpack projects assume that dependencies in node_modules are in ES5 and can be excluded from transpiration. This results in shipping class syntax to browsers that don't support it.

@ef4 has a great explanation of this problem in his comment about transpilation of ember-auto-import.