Skip to content
This repository has been archived by the owner on Dec 31, 2022. It is now read-only.

ES6'ify the code #1

Open
getify opened this issue Oct 14, 2015 · 7 comments
Open

ES6'ify the code #1

getify opened this issue Oct 14, 2015 · 7 comments

Comments

@getify
Copy link
Owner

getify commented Oct 14, 2015

Produce ES6 versions of the code and ES5 transpilations (for feeds.js and ui.js). Include a script for using babel to reproduce these. Have both sets of scripts listed in the HTML, with one set commented out.

TODO: decide if ES6 or ES5 should be default. Probably ES5.

@d6u
Copy link

d6u commented Oct 14, 2015

Do you also plan to use some kind of bundle system, e.g. browserify, to bundle things? Benefits: more clear entry point for each app.

@getify
Copy link
Owner Author

getify commented Oct 14, 2015

hmmm... not sure what you mean. can you give more detail?

@d6u
Copy link

d6u commented Oct 14, 2015

For example, currently the JS files run like this

// dummy-data.js
(function () {
  // Some code
})();

// ui.js
(function () {
  // Some code
})();

// feeds.js
(function () {
  // Some code
})();

So when people read the code, it's hard to know which part of the code starts the app. I have to go through all the codes and look for signs. But with module system (e.g. AMD or CommonJS) enabled and some modification, we can see:

// dummy-data.js
module.exports = {};

// ui.js
module.exports = {};

// feeds.js
var ui = require('./ui.js');
var data = require('./dummy-data.js');

module.exports = {
  start: function () {}
};

// app.js
var feeds = require('./feeds.js');

feeds.start();

by looking at your build script, I know immediately app.js is the entry point, feed.js is the dependency and how things depends on each other.

Another benefits of modules system is to require the same file if they are the same (you can do that with HTML script tag too, but it's more obvious this way), e.g. same dummy-data.js instead of copy dummy-data to all the examples.

@getify
Copy link
Owner Author

getify commented Oct 15, 2015

hmmm... i'm not sure that will help get people to the main point of this project, which is to compare async patterns. they all start the same way (in ui.js), but that detail is kind of irrelevant to the main mission.

I'll consider this, but my instinct is to say it may just be added noise.

@d6u
Copy link

d6u commented Oct 16, 2015

That makes sense. Thanks for considering that.

@GramParallelo
Copy link

@getify Thanks for the project. I think @d6u has a good point. I'm still a noobie guy and came hoping to see clear comparisons but I got something a little more complicated than I expected. Or I'm just lost.
Although I do like the clarity of modules, I get that it adds stuff.
You mention they all start the same way in your comment above (in ui.js) but not in the readme.
It would help me to see mentioned in the readme where to look for the patterns and extra awesome to see the patterns in the readme compared side by side.

@getify
Copy link
Owner Author

getify commented Nov 15, 2016

i have thought about creating some sort of interactive diff too that you could view the diffs between any two (or more) of the implementations. wish i had time to build that.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants