Speak-Node (Angular, Node, ES6)

[LeChris]

Hey,

Github

You must be registered for see links

Live Demo

You must be registered for see links

 

[MayoMayn]

Please dont...

class Application
{
}
module.exports = Application

needs to be

export default class Application {

}

You're not coding PHP anymore m8.
Over all looks really good, but wouldn't call this ES6 in any way..

Btw you really need to read this documentation

You must be registered for see links

 

[Ecko]

lol

Website.use(Express.static(Path.resolve(__dirname, '..', '..', 'public')))

 

[LeChris]

Please dont...

class Application
{
}
module.exports = Application

needs to be

export default class Application {

}

You're not coding PHP anymore m8.
Over all looks really good, but wouldn't call this ES6 in any way..

Btw you really need to read this documentation

You must be registered for see links

ES6 doesn't mean to export default for everything. I'm not wishing to call a new Class.default for this, as it wouldn't function properly this way. Learn what export default does before saying it's the only es6 style way of doing it.

 

[MayoMayn]

ES6 doesn't mean to export default for everything. I'm not wishing to call a new Class.default for this, as it wouldn't function properly this way. Learn what export default does before saying it's the only es6 style way of doing it.

There's no reason at all to call new Class.default for this, when there's a simple plugin adding the old exports['default'] = ... back to babel, and when the only thing you're really requiring is your "routes", then I don't really see the reason in using es6.

 

[LeChris]

There's no reason at all to call new Class.default for this, when there's a simple plugin adding the old exports['default'] = ... back to babel, and when the only thing you're really requiring is your "routes", then I don't really see the reason in using es6.

ES6 is only there for code-readability, as it doesn't provide much in enhancements of coding speed nor anything else.

If you're suggesting ES6 is a wasted ideology for this project, you'll be right as it's a wasteful thing in any project when ES5 works and ES6 transpiles into ES5 anyways.

 

[MayoMayn]

ES6 is only there for code-readability, as it doesn't provide much in enhancements of coding speed nor anything else.

If you're suggesting ES6 is a wasted ideology for this project, you'll be right as it's a wasteful thing in any project when ES5 works and ES6 transpiles into ES5 anyways.

If it's there for code readability and when it's an open-source project, then why in the hell do you follow PHP coding styles and not the default set by Node themselves?

Brackets on same line, export default, no semicolons and so on, as I've said for weeks.

 

[LeChris]

If it's there for code readability and when it's an open-source project, then why in the hell do you follow PHP coding styles and not the default set by Node themselves?

Due to Node being a construct and not an actual language with the NPM package manager being a helpful tool, but not a requirement (A lot of people actually dislike NPM).

Node is nothing more than Javascript in the back-end and I follow the same procedures I prefer to use in the front-end, except I can actually take advantage of ES6 readability in Node.

 

[MayoMayn]

Due to Node being a construct and not an actual language with the NPM package manager being a helpful tool, but not a requirement (A lot of people actually dislike NPM).

Node is nothing more than Javascript in the back-end and I follow the same procedures I prefer to use in the front-end, except I can actually take advantage of ES6 readability in Node.

Classes is default in ES5, which means the only actual ES6 feature you're using is import...

 

[LeChris]

Classes is default in ES5, which means the only actual ES6 feature you're using is import...

If you knew what ES6 really was, you'd take note of how I use my variables which is (an es6 standard). Classes also are just objects in ES5, but ES6 transpiles it back into the object.

(Classes aren't a ES5 feature, hence why it's converted into an object)

ES6 is for readability, with some new improvements notable with variable handling and declaration. Quit this endless argument based off of opinions, not facts.

 

[MayoMayn]

If you knew what ES6 really was, you'd take note of how I use my variables which is (an es6 standard). Classes also are just objects in ES5, but ES6 transpiles it back into the object.

(Classes aren't a ES5 feature, hence why it's converted into an object)

ES6 is for readability, with some new improvements notable with variable handling and declaration. Quit this endless argument based off of opinions, not facts.

Because I am so nice, I'm gonna clean up your git repository for you, and then do a pull request.

 

[LeChris]

Admin progress

 

[Jaden]

Node doesn't fully support ES6 (especially not features like import/export due how incompatible it is to their current module system, and unnecessary it would be to compromise for such a simple feature). What you guys use just trans-compiles your ES6 back into ES5 like CoffeeScript does to JavaScript, which imo is completely redundant for any project without a massive codebase (and other considerable factors).

More on the subject:

You must be registered for see links

My whole point is, if your JavaScript is just going to trans-compile into JavaScript, then just write JavaScript.

Also, the way you write some of your Node like it'd execute synchronously and compensate for your errors by coming up with a more redundant, complicated approach (callback hell? moving code around?) then what is necessary and could've been avoided easily makes me think you should take a break from ES6 and just write ES5 with minimal objects.

You must be registered for see links

p.s. your extensive modularity / file separation in node.js seems a lil redundant, try to be more compact.
p.s.s think less about how aesthetically pleasing your source code is, and focus more on the execution of the program. In the real world nobody cares about how cute your code looks.







p.s.s.s you're writing JavaScript, just come up with a style guide and follow it. Only thing that really matters is consistency.

 

[LeChris]

Node doesn't fully support ES6 (especially not features like import/export due how incompatible it is to their current module system, and unnecessary it would be to compromise for such a simple feature). What you guys use just trans-compiles your ES6 back into ES5 like CoffeeScript does to JavaScript, which imo is completely redundant for any project without a massive codebase (and other considerable factors).

More on the subject:

You must be registered for see links

My whole point is, if your JavaScript is just going to trans-compile into JavaScript, then just write JavaScript.

Also, the way you write some of your Node like it'd execute synchronously and compensate for your errors by coming up with a more redundant, complicated approach (callback hell? moving code around?) then what is necessary and could've been avoided easily makes me think you should take a break from ES6 and just write ES5 with minimal objects.

You must be registered for see links

p.s. your extensive modularity / file separation in node.js seems a lil redundant, try to be more compact.
p.s.s think less about how aesthetically pleasing your source code is, and focus more on the execution of the program. In the real world nobody cares about how cute your code looks.







p.s.s.s you're writing JavaScript, just come up with a style guide and follow it. Only thing that really matters is consistency.

I keep code consistency, but in the real world the only thing that matters is code readability as I hold a professional level coding job.

It all compiles back into C in the end regardless, and the only thing I see truly fitting in your comment is the the code being ran in sync. I tend to try keeping away from this however for important operations ie the only time I use sync is for loading controllers which is only done once at start.

Ty mare for the stuff, and for correcting Sentinel on es6 support as I tried earlier

 

[Jaden]

I keep code consistency, but in the real world the only thing that matters is code readability as I hold a professional level coding job.

It all compiles back into C in the end regardless, and the only thing I see truly fitting in your comment is the the code being ran in sync. I tend to try keeping away from this however for important operations ie the only time I use sync is for loading controllers which is only done once at start.

Ty mare for the stuff, and for correcting Sentinel on es6 support as I tried earlier

"Code readability"...

You must be registered for see links

Quote straight out of Node.js source code:
"Be warned: the mechanics here are seriously ugly -- and one must always
keep in mind that clean abstractions often require filthy systems."

Sample JavaScript written by Node.js developers and currently in the Node platform.

You must be registered for see links

You can see how their code isn't as modularized as yours, clean, compact, and functional.


Conclusion:
Readability < Functionality.
Readability < Performance.
Readability < Tangerines

 

[LeChris]

"Code readability"...

You must be registered for see links

Quote straight out of Node.js source code:
"Be warned: the mechanics here are seriously ugly -- and one must always
keep in mind that clean abstractions often require filthy systems."

Sample JavaScript written by Node.js developers and currently in the Node platform.

You must be registered for see links

You can see how their code isn't as modularized as yours, clean, compact, and functional.


Conclusion:
Readability < Functionality.
Readability < Performance.
Readability < Tangerines

Pretty good thing my code isn't designed to be ran at industrial levels of performance. At that point in development throwing out readability for performance means that the task isn't efficient for Node regardless