ES2015 vs ES5

[tritao]

I am opening this issue to continue the discussion from https://github.com/openhardwarecoza/LaserWeb3/pull/97.

Since we're starting a new version of LaserWeb, I feel it's important we discuss a few options so we do not end up having to rewrite parts of the code in the future again.

So for some context, ES2015 is the new version of JS that was published and is starting to be supported my the major browsers. It brings some significant changes from previous JS, the ones I find more important to writing complex apps are modules and classes. I think LaserWeb codebase would greatly benefit from using the new module system. It basically allows each file to declare and explicitly import its dependencies which makes the code much easier to reason about.

I am suggesting we adopt this standard. It's already 1 year old so it's not like it was just released. While it's not the most well supported standard now, but it will in a couple of months once people start upgrading to newer browser versions. We can use a ES6 to ES5 JS compiler like Babel until that happens. It generates code that works under all browsers.

@arthurwolf brought the point that it will drive contributors away. Due to cleaner architecture and syntax, people used to pretty much every other programming language than front-end JS will feel more at home and since code will be much easier to reason about people will understand the code faster and contribute more. Besides most JS devs are already used to the export/import pattern from Node.

Aside from modules, classes would also help. The model that @lautr3k is proposing is using class inheritance under the hood anyway, but instead of being explicitly specified in the code it's using jQuery helper methods. It's not the most easy to understand model, I've had to reach out for the jQuery docs multiple times to understand what it really does.

I've pushed the first version of the conversion to es6 branch at: https://github.com/openhardwarecoza/LaserWeb4/tree/es6

@lautr3k The only real change I had to do from your architecture was to get rid of the dependency on the lw.get_module from the dock code and replace it with pub/sub pattern. That way the dock code does not depend directly on its parent, but the other way around.

Let me know what you guys think. If you still feel ES5 is the way to go then I will get rid of this branch, but if you agree it's the best way to future-proof LaserWeb code, then we can decide on the best way to generate the ES5 from ES6 to make it the least intrusive way on development possible.

By the way, I've not coded JS in years, so it's possible I might have messed up something.

[arthurwolf]

The problem is "most browsers are starting to support" is pretty much right away disqualifying ... This sort of large scale, widely used project really needs backwards compatibility, you can't afford to use something that new .. 1 year old is insanely new ...

And yes, you are right that it's technically better, but I assure you it IS going to drive lots of contributors away. Something that is one year old is scary. If you can't see that, you have a lot to learn about massively collaborative projects. Lots of folks can barely code, but still contribute very useful code. It's extremely easy to scare those away. Your proposal would.

A project like this really really is not the place to use language features that young.

"Normal" JS works. If you really want classes, use a "normal" JS implementation of that, we do that in fabrica and it works fine. And doing that still allows you to easily transition to something else later on.

Laserweb has been rewritten 3 times in less than a year already, it's definitely going to happen many times again, so you really don't want to worry about making anything "future proof".

On Tue, Aug 30, 2016 at 11:39 PM, João Matos notifications@github.com wrote:

I am opening this issue to continue the discussion from openhardwarecoza/LaserWeb3#97 https://github.com/openhardwarecoza/LaserWeb3/pull/97.

Since we're starting a new version of LaserWeb, I feel it's important we discuss a few options so we do not end up having to rewrite parts of the code in the future again.

So for some context, ES2015 is the new version of JS that was published and is starting to be supported my the major browsers. It brings some significant changes from previous JS, the ones I find more important to writing complex apps are modules and classes. I think LaserWeb codebase would greatly benefit from using the new module system. It basically allows each file to declare and explicitly import its dependencies which makes the code much easier to reason about.

I am suggesting we adopt this standard. It's already 1 year old so it's not like it was just released. While it's not the most well supported standard now, but it will in a couple of months once people start upgrading to newer browser versions. We can use a ES6 to ES5 JS compiler like Babel until that happens. It generates code that works under all browsers.

@arthurwolf https://github.com/arthurwolf brought the point that it will drive contributors away. Due to cleaner architecture and syntax, people used to pretty much every other programming language than front-end JS will feel more at home and since code will be much easier to reason about people will understand the code faster and contribute more. Besides most JS devs are already used to the export/import pattern from Node.

Aside from modules, classes would also help. The model that @lautr3k https://github.com/lautr3k is proposing is using class inheritance under the hood anyway, but instead of being explicitly specified in the code it's using jQuery helper methods. It's not the most easy to understand model, I've had to reach out for the jQuery docs multiple times to understand what it really does.

I've pushed the first version of the conversion to es6 branch at: https://github.com/openhardwarecoza/LaserWeb4/tree/es6

@lautr3k https://github.com/lautr3k The only real change I had to do from your architecture was to get rid of the dependency on the lw.get_module from the dock code and replace it with pub/sub pattern. That way the dock code does not depend directly on its parent, but the other way around.

Let me know what you guys think. If you still feel ES5 is the way to go then I will get rid of this branch, but if you agree it's the best way to future-proof LaserWeb code, then we can decide on the best way to generate the ES5 from ES6 to make it the least intrusive way on development possible.

By the way, I've not coded JS in years, so it's possible I might have messed up something.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFYJXZikxYQqaaddX29EQQZDZRauvks5qlKL3gaJpZM4JxAbh .

Courage et bonne humeur.

[tritao]

@arthurwolf Latest released versions of Chrome, Firefox and IE already support >90% of ES6 and like I said there are ways to support ES2015 code in older browsers. This is how things have been done in the JS world for years (polyfills for older browsers) and people have been coping fine with the model. In the branch I posted it already generates ES5 that works with older browsers with no extra effort.

I'm having a hard time understanding your argument. Are you opposed to using the ES2015 module system or class system (or both?)? If it actually made things harder to understand I would agree with you, but that is not the case. It's an easier model to understand, and how pretty much every other programming language already works. People are used to the import/export model, it's how Node works (require).

I would understand if I was suggesting some radical cutting-edge features, but this is some relatively simple model that can be learned in less than an hour. If it does drive contributors away, then in my opinion, so be it, a project can't make its technical decisions solely based on the fact that some people will not want to learn new stuff. Besides once the architecture is set, most changes will not need to touch any of the import/export model and people will just be able to write regular JS.

I took a quick look at Fabrica, and it seems its using something called js.class which is some kind of explicit class system for JS. If someone has never used this js.class then he would also need to learn it, and the exact same argument you're using could be applied to it. I think even worse since it's something that is pretty much obsolete today, I'd rather people learn the standard JS class model that will surely be common place soon.

JS is language that historically leads to "bad" code being written due to having no standard way to structure code (which ES2015 solves). There's no reason for LaserWeb to need to be rewritten so many times if solid engineering choices are made in this new version (and code is carefully reviewed, which sometimes is easier said than done in practice, but we can try).

[arthurwolf]

Again : you are absolutely correct it is the right technical choice, it's just not the best one if you want contributions. It's not something I can easily demonstrate, it's just coming from ( a lot of ) experience of open-source projects. This is a psychological issue not a technical one.

On top of that, the comment about "laserweb doesn't need to be rewritten if we make the right choices right now", essentially show me you are aiming for a development model for laserweb that just won't work ... again for psychological reasons. There is a reason laserweb was rewritten this many times already, and this is very common in open-source projects at the frontier like this one : doing things right is boring. contributors do this on their free time. if they get bored, they will stop doing this ( I'm oversimplifying here but I hope you can see what I'm trying to tell you ).

You don't want a shiny perfect system that will work forever using the latest standard. You want something that allows users to get to exiting things fast, and as easily as possible. This is going to involve a lot of very dirty code. If you want to be the guy who comes and cleans after the people who just had fun, that's great, lots of projets have that guy, and they are lucky to have him. But you are not going to get the other coders to become clean. Because : volunteers.

The change you want to do is one that will come progressively. Be patient. If you want to do it right away in a major rewrite like this one, YES it is the right thing to do technically, it's what you would do at work. It's also going to kill the project. Because : volunteers.

On Wed, Aug 31, 2016 at 12:33 AM, João Matos notifications@github.com wrote:

@arthurwolf https://github.com/arthurwolf Latest released versions of Chrome, Firefox and IE already support >90% of ES6 and like I said there are ways to support ES2015 code in older browsers. This is how things have been done in the JS world for years (polyfills for older browsers) and people have been coping fine with the model. In the branch I posted it already generates ES5 that works with older browsers with no extra effort.

I'm having a hard time understanding your argument. Are you opposed to using the ES2015 module system or class system (or both?)? If it actually made things harder to understand I would agree with you, but that is not the case. It's an easier model to understand, and how pretty much every other programming language already works. People are used to the import/export model, it's how Node works (require).

I would understand if I was suggesting some radical cutting-edge features, but this is some relatively simple model that can be learned in less than an hour. If it does drive contributors away, then in my opinion, so be it, a project can't make its technical decisions solely based on the fact that some people will not want to learn new stuff. Besides once the architecture is set, most changes will not need to touch any of the import/export model and people will just be able to write regular JS.

I took a quick look at Fabrica, and it seems its using something called js.class which is some kind of explicit class system for JS. If someone has never used this js.class then he would also need to learn it, and the exact same argument you're using could be applied to it. I think even worse since it's something that is pretty much obsolete today, I'd rather people learn the standard JS class model that will surely be common place soon.

JS is language that historically leads to "bad" code being written due to having no standard way to structure code (which ES2015 solves). There's no reason for LaserWeb to need to be rewritten so many times if solid engineering choices are made in this new version (and code is carefully reviewed, which sometimes is easier said than done in practice, but we can try).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243603006, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFUVKsm5_Fjo-NhOGnK4xuR6i8Pv6ks5qlK--gaJpZM4JxAbh .

Courage et bonne humeur.

[tritao]

@arthurwolf I do understand where you're coming from. And in fact I had already factored the contribution factor in the decision to try to use new JS features. If I was doing something just myself I'd not even consider JavaScript (if I wanted to run on the browser I'd use something statically-typed like TypeScript). But I'd rather work with the community, and make sure contributions are accessible to everyone.

You are right that doing things the "technically correct" way takes a lot more effort and time, but also leads to a more solid product. For instance, I've been following Smoothie development and it seems to strongly follow this model. I've seen plenty of pull requests either rejected or asking the users to rework it because it doesn't follow the guidelines or technically best solution. In fact, it's the reason I use and follow the project, as opposed to other community firmwares that don't have a strong technical leadership and end up with spaghetti code.

You are also right that we can't expect code to remain super clean over time due to contributors (well, in practice you can with strong technical leadership, but takes a ton of effort and you will potentially piss some people off), but using language constructs that lead to better code or make refactoring easier is a good first step to make it easier to remain that way.

Something that I've found to greatly help is setting up a CI system to make sure pull requests at least compile, and having an extensive test suite. I don't have much experience in medium to large projects with JS, but I guess some sort of linting system would also help. I've also found through personal experience that if you take the time and guide contributors they will most of the time follow your suggestions and and learn to write better code.

The reason I am putting effort on this is that I am planning to use LaserWeb's code for some automation purposes so I have a personal interest to help with what I can and make sure we end up with something that is dependable.

I think the way to get there is to keep the UI code/logic separate from the backend so that one can be modified without impacting the other. Then people can build on the backend (controller communication, CAM module, cost estimation) without having to pull the whole UI code.

The same logic can be applied to each component individually. It should for instance be possible to use the "visualizer UI component" to visualize a rendered SVG on a grid in an independent webpage, without bringing the whole dock code.

Anyway just some thoughts, hopefully made sense, getting late over here :smile:

[krolco]

I like the idea of changing over to ES2015 for LW4. I looked at the contributors list for LW3, and there are only 11 contributors, with 249/322 commits coming from @openhardwarecoza and @lautr3k. It seems to me that the LW3 codebase suffers from old JS structure more than it benefits from a large pool of contributors. I think if the main developer wants to work in ES2015, that's going to generate much more development on the project than anything else. I don't understand @arthurwolf's reservation for choosing a newer language for this size project -- this is small, well-contained project, and it seems like a great place to try a new version of the language to me. And as a software developer, I'd rather see better structure in the project anyway. I would make the same choice that @tritao is making.

Because I didn't know much about it, I looked up ES2015. It turns out that the ECMAscript committee is going to a yearly model, so the changes to the language will be coming more frequently anyway.

I found this page that lists browser compat by feature for ES2015:

http://kangax.github.io/compat-table/es6/

The big browsers and Node 6 have 92%+ compat with the feature set. That looks pretty good to me.

[ghost]

Interesting conversation :) Sorry I have been offline last week and what looks to be most of this week too. Work work work.

From feedback I get most of the serious developers are actually appalled by my amateur code and thus scaring off people I really want to have working with us like @tbfleming etc

So a switch to something better is fine with me.

I had to do with what I had. When in Nov last year I couldn't get Visicut to work for me, I took to what was easiest to learn and since i had basic front-end skills, jquery was the easy way to get productive and start doing things. All over the last three versions my goal has been just to make it work. If that means I use a setinterval because I can't get a callback to work (would make most of you shudder) I didn't mind: it got the job done. Keep in mind I am self taught on all of this and rely heavily on easy to read code, detailed, smaller commits from contributors so I can also learn and understand (so please rather let me give you push access and get to see each step of your development than a single nicely rolled up and finished feature which I learn nothing from)

I guess what I am saying is, whatever you all decide (I am going to step back a little since I do believe LaserWeb is becoming bigger than me alone. NB You really should get the Darkly labs and Fabcreator folks in here too since their hardware projects depend on LaserWeb eventually) as long as it doesn't become over complicated and undocumented I am fine. Please just keep it simple to understand and add comments and examples and links to documentation as far as possible. We can always hand hold and teach someone something new. But let's not make it impossible to transition from what people like me and the average Joe knows, to get to where you are heading

To reiterate:

• I dont mind "new" (the three rewites in 8 months prove that I am happy to go crazy when I learn a new skill)
• I DO mind shorthand, hard to read, single line code
• I do love and already use ES6 templates (:
• Please add comments and commit often (even in progress work)
• If we are scared of loosing "amateur" developers I do feel we can approach that risk with a healthy dose of non-judgemental, eager to teach, team members. Make it very clear in our readme that we are happy to show people the right way, and help them do it. Even it means they can contribute ideas and we need to rewrite it

[ghost]

Oh another note: We already force users to use Chrome and threejs often needs "latest" anyway (:

[ghost]

I'll be honest though, I looked over the commit on the es branch. And I have no idea what half of that means (:

[ghost]

From my point of view "classes" in JavaScript is a non sense, it's just a wrapper around the prototype chain which is a common source of confusion. The latest ES versions provides full of great stuff that I use some time. But as long I have to compile my JS (interpreted language) code to be compatible, I think I would not make the transition.

I agree with what @arthurwolf said. For now, I really think we just need a simple, accessible and modular base without adding complexity and the contributors list will grow rapidly.

Sorry for the brevity, I struggle to express myself in English.

[tbfleming]

This project has the potential to replace jscut with a more convenient UI and more flexible feature set. The main reason I don't get involved is time. If I was heavily involved I'd push for ES2015 with Babel, switching from jquery to one of the many good libraries which support the virtual DOM approach, and maybe adding typescript. I switched to that combo at work and it produces much more maintainable code than old JS + jquery + MV\ frameworks. As a bonus, the code looks much more like the bazillion non-JS c-style languages on the planet. Yeah, the prototype system sucks and the class syntax is just sugaring that, but most of the time I'm working with ES2015 classes I can forget prototypes and get the job done. Every once in a while I hit a case where I have to stop and think about how the classes translate to prototypes for compatibility with existing libraries, but it's not often. I wish I had that combo back when I developed jscut.

Right now though, the main contributors are more comfortable with the traditional approaches, and that's what really matters.

[tritao]

@openhardwarecoza Since you mention three.js because they recently also made a big move to ES modules. If you any of their files (say https://github.com/mrdoob/three.js/blob/dev/src/animation/AnimationMixer.js) you will see the import statements right away.

And the main idea for ES modules is that each file in the codebase will export the types that are defined in it that are meant to be accessible from other files, while at the same time importing the types that it depends on. It works like 'require()' system from Node.

So at the top of a file, you will see things import Module from '../core/module' which imports the default exported type from the referenced file. Exporting is just a matter of prepending each type in a file with export keyword.

The main idea behind this is to migrate from the old browser JS model where you can just reference files and variables that were defined in previously interpreted JS files, and force each file to really say what it depends on.

@lautr3k We don't need to use "classes", but you are using them in your proposed architecture. The only difference is that you are using an homebrew version of them, where each file has to have an extends variable and then use some jQuery helpers to clone the prototype chains. Since this is not a standardized approach it is harder to understand than ES classes.

lw.modules.module = $.extend(true, {}, lw.modules.core, {
        // Extends
        extends: ['core'],
}

vs.

class Module extends Core {
}

I think we also cannot use the same system for backend and frontend code, since it uses jQuery for dealing with prototype chain and jQuery only works on browser I think.

Do you oppose moving to ES2015 features like modules? Or just ES classes or both?

[ghost]

This project has the potential to replace jscut with a more convenient UI and more flexible feature set.

@tbfleming , coming from you: me and every other contributor can take that as the ultimate compliment! Thank you!

[Cinezaster]

My experience with ES2015. Go for it, and use a compiler like babel.js if needed My team used ES2015 from the beginning. Why, because we have a compiler like babel.js. Why the switch ES2015?

• Because it has nice features.
• It has better ways to modularize code.
• Some developers like to be challenged and want to be on top of it, meaning now the last things happening with their favoured language.
• In a lot of cases you can write less code.

[ghost]

@tritao I am not against a move to ES6 or using classes. I just want to be sure everyone is okay with that, and those who want it assumes that choice by being active in the development and maintaining the code base. Anyway we will do the best for LaserWeb.

[arthurwolf]

On Wed, Aug 31, 2016 at 1:10 PM, Sébastien Mischler (aka skarab) < notifications@github.com> wrote:

@tritao https://github.com/tritao I am not against a move to ES6 or using classes. I just want to be sure everyone is okay with that, and those who want it assumes that choice by being active in the development and maintaining the code base.

Pretty much my whole point. Use whatever technique you want, but most of the potential contributors to laserweb WILL need handholding ( understand heavily commented code, documentation OF THE CODE in the wiki, and actually talking to them ) to do anything but "basic" JS. As long as you are ready to do that job, which is much more work than just doing proper design, then that's fine.

But if you are just saying "we should switch to x", and then you leave the rest of us to deal with it, that's just going to be a loss to the project, even if the code is better.

Anyway we will do the best for LaserWeb.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243732514, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFXYbM7jp8SyIiJyk9b9HMIdUuolEks5qlWExgaJpZM4JxAbh .

Courage et bonne humeur.

[ghost]

Second in Arthur and Sébastien's sentiments. 'Contributor' here has a heavier community workload than most

On Aug 31, 2016 1:19 PM, "Arthur Wolf" notifications@github.com wrote:

On Wed, Aug 31, 2016 at 1:10 PM, Sébastien Mischler (aka skarab) < notifications@github.com> wrote:

@tritao https://github.com/tritao I am not against a move to ES6 or using classes. I just want to be sure everyone is okay with that, and those who want it assumes that choice by being active in the development and maintaining the code base.

Pretty much my whole point. Use whatever technique you want, but most of the potential contributors to laserweb WILL need handholding ( understand heavily commented code, documentation OF THE CODE in the wiki, and actually talking to them ) to do anything but "basic" JS. As long as you are ready to do that job, which is much more work than just doing proper design, then that's fine.

But if you are just saying "we should switch to x", and then you leave the rest of us to deal with it, that's just going to be a loss to the project, even if the code is better.

Anyway we will do the best for LaserWeb.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment- 243732514, or mute the thread https://github.com/notifications/unsubscribe-auth/ AAGpFXYbM7jp8SyIiJyk9b9HMIdUuolEks5qlWExgaJpZM4JxAbh .

Courage et bonne humeur.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243734284, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2xKhO2qioOE7nelLxzwW6FbX64mUks5qlWM-gaJpZM4JxAbh .

[emteeoh]

Coming from a person who feels he doesn't actually know how to code in JS, moving straight to ES6 sounds like a fine idea. Syntatic sugar is mostly good: if all it did was enable more obfuscated code competitions, we'd stop adding it to serious languages.

On a not entirely unrelated note, coming from someone who knows C, Smalltalk, Basic, Pascal, FORTRAN, COBOL, Bash, AWK, SED, and a few different assembly languages, can anyone recommend some tutorials or books on learning JS and/or ES6? It might be old-age, but I'm finding it hard to get into anything because its mostly starts so low-level I get bored and fall asleep.

[ghost]

So. Can we push this into a final direction (: seems we have lots of eager hands onboard. Lets get going. Instead of stalling weeks on this

Keep in mind going heavy es2015 we may loose @lautr3k from this work and @arthurwolf support (since Fabrica wont be going full es2015) (so i'd say the existing bigger code contributors and friends off the project, above voiced their concerns (: - read through once more before voting.

I guesa if we do end on a es5 majority some modules can always be es2015?

I vote we modularise, refactoring etc but not go to es2015 classes etc and all the other complications. So in short, my vote is

ES5

[ghost]

ES5 too :P

[ghost]

I just want to clarify, if were going on ES6, I will not quit the project, but I'd probably less active on the establishment and maintenance of the heart.

[emteeoh]

I think I'd rather ES6, but I think that, at least in the short term, keeping lautr3k and arthurwolf happy&contributing is more important than using ES6.

[tritao]

I would obviously prefer if we adopt ES6 due to much increased modularity of code allowed by language which is the main goal of rewrite.

But I need to ask: if the goal for going with ES5 is really to make contributions easier, than what is the logic for developing a custom class/inheritance system inside LaserWeb core? No JS dev will know how it works.

For example, we can use ES5 with class system like @arthurwolf is using in Fabrica (see https://github.com/arthurwolf/fabrica/blob/gh-pages/src/core/js.class/), Arthur, what have been your experiences with such a system?

@lautr3k I am curious, why do you prefer ES5 to the point of being less active if we go with ES6? Is it just because you think the code is more complicated?

As long as code-reuse is possible through good design, I am fine with ES5, but do think it's a technically obsolete approach and will make project maintenance harder long-term.

[ghost]

I expect cross origin warnings in file://

On Aug 31, 2016 5:51 PM, "Richard Betel" notifications@github.com wrote:

I think I'd rather ES6, but I think that, at least in the short term, keeping lautr3k and arthurwolf happy&contributing is more important than using ES6.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243809053, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2_2DWYJy5cIJXlx69MrJNd-Xhfi4ks5qlaLlgaJpZM4JxAbh .

[arthurwolf]

For like the third time : this is not a technical issue, it's a psychological one. You have to know the kind of persons who are likely to become contributors to this project, at this point, to understand this, I think. ES6 is new, so it's scary. class.js-like-stuff is less so.

It doesn't matter what is actually true, what is actually technicall better ( ES6 is ) what matters is what people will "feel" before even deciding to contribute.

I really think that finding a compromise is very easy here. Let's have more modular code, but keep ES6 for later ...

On Wed, Aug 31, 2016 at 6:29 PM, João Matos notifications@github.com wrote:

I would obviously prefer if we adopt ES6 due to much increased modularity of code allowed by language which is the main goal of rewrite.

But I need to ask: if the goal for going with ES5 is really to make contributions easier, than what is the logic for developing a custom class/inheritance system inside LaserWeb core? No JS dev will know how it works.

For example, we can use ES5 with class system like @arthurwolf https://github.com/arthurwolf is using in Fabrica (see https://github.com/arthurwolf/fabrica/blob/gh-pages/src/core/js.class/), Arthur, what have been your experiences with such a system?

@lautr3k https://github.com/lautr3k I am curious, why do you prefer ES5 to the point of being less active if we go with ES6? Is it just because you think the code is more complicated?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243821216, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFfDufffd0RLl3nR0V1NG6wQAYqnGks5qlavlgaJpZM4JxAbh .

Courage et bonne humeur.

[emteeoh]

+tritao : in https://github.com/openhardwarecoza/LaserWeb4/issues/1 , it was suggested that there are opportunities to share code with fabrica. As a first cut, sharing modules between ES5/Fabrica and ES6/LW4 will be non-trivial.

But this is rev4 of a program that is all of 10 months old. In fact, I just looked at the code, and realized its V0.4.0, not even the V4.0.0 that the name kinda implies. I think there will be ample opportunities to re-factor again! Also, if we have a working code-base with shared fabrica modules, it'll be much easier to figure out what it takes to make the two language versions co-exist.

[arthurwolf]

On Wed, Aug 31, 2016 at 6:42 PM, Richard Betel notifications@github.com wrote:

+tritao : in #1 https://github.com/openhardwarecoza/LaserWeb4/issues/1 , it was suggested that there are opportunities to share code with fabrica. As a first cut, sharing modules between ES5/Fabrica and ES6/LW4 will be non-trivial.

I think the basis of sharing here is not really to share modules as-is, but more to turn things into libraries, and which will allow both projects to use them.

But this is rev4 of a program that is all of 10 months old. In fact, I just looked at the code, and realized its V0.4.0, not even the V4.0.0 that the name kinda implies. I think there will be ample opportunities to re-factor again! Also, if we have a working code-base with shared fabrica modules, it'll be much easier to figure out what it takes to make the two language versions co-exist.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243824963, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFTADaxCJt4QthwzZJycANDAipum1ks5qla7cgaJpZM4JxAbh .

Courage et bonne humeur.

[emteeoh]

I think the basis of sharing here is not really to share modules as-is, but more to turn things into libraries, and which will allow both projects to use them.

Does that really change my argument? Basically, I don't know what the calling conventions are, so if we take a chunk of code from ES6/LW4 and make a library, will you be able to use it? I assume the other way around will be trivial.

[tbfleming]

It's interesting that at the same time less-experienced developers are saying that they prefer ES6, some of the more experienced developers are saying that it would scare the less-experienced developers away. It's also interesting the claim that custom class systems are OK but ES6's class system is too new.

[arthurwolf]

I didn't expect something as simple as the kind of library we'll be writing for lw4 to need anything ES6 related ...

On Wed, Aug 31, 2016 at 6:51 PM, Richard Betel notifications@github.com wrote:

I think the basis of sharing here is not really to share modules as-is, but more to turn things into libraries, and which will allow both projects to use them.

Does that really change my argument? Basically, I don't know what the calling conventions are, so if we take a chunk of code from ES6/LW4 and make a library, will you be able to use it? I assume the other way around will be trivial.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243827690, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFd0ECu6u7NCfgbyIhdMNu3DfxnLqks5qlbD7gaJpZM4JxAbh .

Courage et bonne humeur.

[ghost]

@tritao I'm not a professional but I code for years, I have some logic that I struggle to change. If I have to spend time to learn a new syntax and all its subtleties, I do not have time for that, I have many others projects that demand my attention. And that's why I'd probably less active. BTW I did not do a class system but just a front-controller to add module (object) to LW which has an "option" to extends the added module (just a shortcut).

[tritao]

@lautr3k Makes sense, and I think it's totally valid reason.

Also while you might not see your custom module system as a class system, it in fact shares most of the characteristics of one (inheritance being the main one), it's just not integrated at language-level.

Since you and @openhardwarecoza are the biggest actual code contributors and you both preferred ES5 I will close the issue.

Either way, I hope you in the future take a few hours to learn ES6 classes and modules, you will find it makes code actually easier to write, it's just a different way of thinking. I had not used them before and learned how to use them just in a couple hours yesterday.

[ghost]

Thanks Joao (: . Definitely soon. Hope we can still count on some contributions from you (: . This conversation though a little heated was very interesting and enlightening

On Aug 31, 2016 7:06 PM, "João Matos" notifications@github.com wrote:

Closed #2 https://github.com/openhardwarecoza/LaserWeb4/issues/2.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#event-773966774, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2_oDW_Dvqi3tBQ2x6nU47b7zVeGSks5qlbSZgaJpZM4JxAbh .

[tritao]

@openhardwarecoza Sure, as long as code re-use can happen I will help. Will open a new issue so we can discuss the "backend" design decisions. Hopefully should be less controversial than this one :+1:

[ghost]

Hehe we had quite a lot of controversy on the serial backend fight in the past already :) . Read through https://github.com/openhardwarecoza/LaserWeb2/issues/52

On Aug 31, 2016 7:42 PM, "João Matos" notifications@github.com wrote:

@openhardwarecoza https://github.com/openhardwarecoza Sure, as long as code re-use can happen I will help. Preparing to open a new issue so we can discuss the "backend" design decisions. Hopefully should be less controversial than this one 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243842582, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2-_aqe3ynuAaFbl2u8hJWkb4IHMpks5qlb0NgaJpZM4JxAbh .

[ghost]

And https://plus.google.com/+PetervanderWalt/posts/RJbNqjxDyiZ was the thread where I said 'fuckit' on SPJS and went back to node.

On Aug 31, 2016 8:06 PM, "Peter van der Walt (Gmail)" < peter.plaaswerf@gmail.com> wrote:

Hehe we had quite a lot of controversy on the serial backend fight in the past already :) . Read through https://github.com/ openhardwarecoza/LaserWeb2/issues/52

On Aug 31, 2016 7:42 PM, "João Matos" notifications@github.com wrote:

@openhardwarecoza https://github.com/openhardwarecoza Sure, as long as code re-use can happen I will help. Preparing to open a new issue so we can discuss the "backend" design decisions. Hopefully should be less controversial than this one 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243842582, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2-_aqe3ynuAaFbl2u8hJWkb4IHMpks5qlb0NgaJpZM4JxAbh .

[ghost]

And this was a good overview at the time of the three flavours (yet how far beyond the goals we already came) https://plus.google.com/+PetervanderWalt/posts/92UgmMpHWKT

On Aug 31, 2016 8:11 PM, "Peter van der Walt (Gmail)" < peter.plaaswerf@gmail.com> wrote:

And https://plus.google.com/+PetervanderWalt/posts/RJbNqjxDyiZ was the thread where I said 'fuckit' on SPJS and went back to node.

On Aug 31, 2016 8:06 PM, "Peter van der Walt (Gmail)" < peter.plaaswerf@gmail.com> wrote:

Hehe we had quite a lot of controversy on the serial backend fight in the past already :) . Read through https://github.com/openhardwar ecoza/LaserWeb2/issues/52

On Aug 31, 2016 7:42 PM, "João Matos" notifications@github.com wrote:

@openhardwarecoza https://github.com/openhardwarecoza Sure, as long as code re-use can happen I will help. Preparing to open a new issue so we can discuss the "backend" design decisions. Hopefully should be less controversial than this one 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243842582, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2-_aqe3ynuAaFbl2u8hJWkb4IHMpks5qlb0NgaJpZM4JxAbh .

[arthurwolf]

On Wed, Aug 31, 2016 at 6:51 PM, Todd Fleming notifications@github.com wrote:

It's interesting that at the same time less-experienced developers are saying that they prefer ES6, some of the more experienced developers are saying that it would scare the less-experienced developers away. It's also interesting the claim that custom class systems are OK but ES6's class system is too new.

I'm not pulling this stuff out of my ass ... This is not some abstract theory in my brain, this is stuff I've been told privately ( this sort of heated thread is not something everybody wants to post in ) by potential contributors, on the subject of both fabrica and lw4.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb4/issues/2#issuecomment-243827794, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFXzamCEB0qcMdIsB0g-NJlDUzQreks5qlbESgaJpZM4JxAbh .

Courage et bonne humeur.

[ghost]

MEACULPA I began to learn ES6 and it rocks ! After setting up some tools (like watch module) transpilation was easy as hitting ctl+s in your code editor ;)