-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting real classes #136
Comments
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 |
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. |
AHHHHHH, gotcha. |
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 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? |
It maybe a better idea to drop the use of classes altogether? see https://davidwalsh.name/javascript-objects-deconstruction |
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. |
I would be interested in hearing why the whole concept of classes is misguided. |
@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. |
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 |
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.The text was updated successfully, but these errors were encountered: