-
Notifications
You must be signed in to change notification settings - Fork 75
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
Transition codebase to ES2015? #18
Comments
My only hesitation has been the build step requirement. I agree with all your points though, and think I should "see the light" as so much of the modern web has moved to the babel approach. Getting new contributors is a huge thing for the project right now, as I'd like it to include the voices of others. Currently I only use webpack to build the bundles, which is something that only happens on release, and is not a dependency of setting up a development environment. You don't need to start a server, npm install anything, have a file watcher etc. I really like the simplicity of that. That said new es6 features are great and I can't ignore them, so migrating to them sooner than later is a good idea. It will definitely happen. It's on the roadmap, but it's not the current top priority. If there's a way you think I could better organize samsara to support the es6/webpack/babel developer workflow, please let me know. For one, I could provide a CommonJS version for each file, and not just the samsara.js bundle. |
I am not very familiar with Samsara and its structure, nor with how developers would benefit from importing only a few modules and not the whole library, but the ES2015 syntax for modules allows the importation of specific object inside modules:
Is this what you mean? Regarding the implications of moving to ES2015: it would indeed probably mean adding a 'tasks' folder, with the webpack config file and a basic express server. But in my opinion, it isn't too bad of a requirement / feature. The dev workflow with webpack, especially when combined with hot reloading and eslint, is really nice and productive. I have set up quite a few projects with webpack / babel lately, so I could help you moving forward with it if you want. |
I agree with vkammerer. Also from a development perspective, it's not hard to wire up babeljs to transpile in the browser. So no build step. |
@culyun could you link me to a place that describes the process you mention? After the node removal API is set (sometime this week), the next priority will be migrating to es6 |
systemjs can use babeljs to transpile on the fly. Here's a systemjs config I'm fiddling with at the moment ` System.config({ }, |
Not necessary to migrate the entire source to es6 because there's no benefit and gives less speed transpiled. However, the biggest benefit is migrate to using the import/export es6 module syntax for tree-shaking to shave unused exports. I was a big user of the Famous library. Hope you're continuing that path with solid devs. You guys implementing repulsion physics/gravity fields? Has so much use! |
I wouldn't be so sure about the less speed point. From what I've read babeljs uses things like Object.defineProperty. This will actually speed up code in some instances since it allows the runtime to replace slow dictionary-based property lookups with pointer dereferencing. |
The transpilation of calling super() in es6 has up to 16x degraded speed in some browsers like Firefox I think as well as some other things that don't match native by 2-4x. It won't matter in the future but as of now at initialization time you take the biggest hit using classes. There's are charts for this floating around. It's why the Famous team decided to stick with es5 because when building the foundation of an engine you want to squeeze every bit of performance you can from widely used functionality. |
Here's a chart http://kpdecker.github.io/six-speed/ This will be looked at closely when the es6 migration happens |
Sorry all, looks like I was a bit quick off the mark.
I remember reading a bit of guff from Andreas Rossberg where he was advocating Object.createproperty in the context of runtime optimization. Looks like I took 1 +1 and came up with 42. Thanks for the links! |
just to let others now, you can already use it in your es6 application like this
doing it like this you will always use the full samsara so it is probably not as perfect as it should be - anyway still better then without es6 :) |
Hello David,
Thank you for the great work, it's really inspiring and I hope the project will keep growing.
I was wondering if you plan to move the codebase to ES2015?
That would have the advantages to:
Moreover, since you are using webpack as a build tool, the refactor would not have to happen at once but could be progressively done.
The text was updated successfully, but these errors were encountered: