Transition codebase to ES2015? about samsara HOT 11 OPEN

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.

from samsara.

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:

import { Surface } from 'samsara'

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.

from samsara.

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.

from samsara.

@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

from samsara.

@dmvaldman

systemjs can use babeljs to transpile on the fly.
The magic is setup via a config script that is loaded in index.html immediately after systemjs.

Here's a systemjs config I'm fiddling with at the moment

`
System.config({
baseURL: '.',
transpiler: 'babel',
babelOptions: {
'optional': [
'runtime',
'optimisation.modules.system'
]
},
map: {
'babel': 'node_modules/babel-core/browser.js',
'fastclick': 'node_modules/fastclick/lib/fastclick.js',
'image': 'node_modules/system-image/image.js',
'j2c': 'node_modules/j2c/dist/j2c.global.min.js',
'lodash': 'node_modules/lodash.js',
'mithril-infinite': 'node_modules/mithril-infinite/lib/mithril-infinite.js',
'mithril': 'node_modules/mithril/mithril.min.js',
'mmsvg': 'node_modules/mmsvg.js',
'samsara': 'node_modules/samsarajs/samsara',
'text': 'node_modules/system-text/text.js',
'verge': 'node_modules/verge/verge.min.js'
},
meta: {
'app/*.svg': {
loader: 'image'
}
}
});

System.config({
packages: {
// meaning [baseURL]/local/package when no other rules are present
// path is normalized using map and paths configuration
'image': {
defaultExtension: 'false'
},
'samsara': {
defaultExtension: 'js'
},

},
});
`

from samsara.

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!

from samsara.

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.

from samsara.

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.

from samsara.

Here's a chart http://kpdecker.github.io/six-speed/

This will be looked at closely when the es6 migration happens

from samsara.

Sorry all, looks like I was a bit quick off the mark.

Eating humble pie.. yum yum ;-) <<

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!

from samsara.

just to let others now, you can already use it in your es6 application like this

// first I added it via: npm install --save samsarajs
import * as Samsara from 'samsarajs';

// use it directly
let block = new Samsara.DOM.Surface({...});

// or via helper - needs to be defined on every import
const Surface = Samsara.DOM.Surface;
const View = Samsara.Core.View;
let block = new Surface({...});

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

from samsara.