Ask HN: How do I inspire my coworkers to adopt new code standards like ES2015?

3 points by lostPixels 10 years ago | 3 comments

We're beginning a new site launch project, and currently in the midst of assembling our strategy around the Javascript architecture.

After so research I opted to vote for using Webpack and BabelJS. Our tech lead is concerned that our team isn't ready to use "advanced javascript" and it will cause issues.

My answer was that ES2015 encompasses a lot of additions to the language, and that we don't have to use all of them. Things like fat arrows would be a quick win. We don't have to start using Classes unless we all agree that it's a good idea. This didn't really seem to sink in though ufortunately.

We're going to have to maintain this site for 4-5 years, and in the near future we'll be required to read/write ES2015 style code if we want to develop apps in React, Angular, etc. because their documentation will be using the new syntax. Backporting things sucks, and will cause more problems than its worth.

These points didn't really seem to sway his opinion, so I'm hoping to get some outside feedback on how you've pitched this topic to your teams and won their approval.

softyeti 10 years ago |

I believe you may not have addressed what your tech lead is worried about. He/She has to make sure that everyone can do what you are trying to do from an architectural standpoint if you are all going to build upon it.

You are outlining the benefits, but JavaScript is very different from other languages and can be hard to understand, let alone master all of the libraries based on it.

If you can address those issues, then you may be able to convince your lead.

I've been on both sides of the coin here. When deciding on a platform or language, I usually choose what is going to be the easiest to use, or what has a high adoption rate which will provide the documentation and Q&A information online.

bevacqua 10 years ago |

Point them to https://ponyfoo.com/articles/es6

lollipop25 10 years ago |

> My answer was that ES2015 encompasses a lot of additions to the language, and that we don't have to use all of them.

Exactly. Valid JS APIs and syntax, no matter what version, unless announced as deprecated, is still valid JS. It's not like if I write using `for` loops in your project, it will totally break.

> Our tech lead is concerned that our team isn't ready to use "advanced javascript" and it will cause issues.

Give or take 5-6 months of development down that route and you'll see more tools-related bugs and workflow problems than problems in your product. Your productivity will decrease as more of these show up. You'll then start to drop priorities and cope up with workarounds. When these overwhelm you, it won't be long before he decides to do a rewrite. Yep, this happens in software development, no matter how you take care of your code.

There's a reason why almost all JS frameworks and tools aren't all 1.0 yet. The API is NOT STABLE if it's not a major release. Node.js, if not for io.js, would still be 0.12 and highly unstable. If not that, then tools are breaking too often. Look at Browserify, it's version 11 already!

You don't want fast-moving tools on a long-term project. Stick with what's proven and stable.

Additionally, it only increases the barrier of entry for your project. A new developer won't know where to start if the tools are relatively new.

> We don't have to start using Classes unless we all agree that it's a good idea.

Classes are just sugar for prototypal inheritance. And even inheritance itself is a problem. There's a saying that goes "Composition over inheritance". Google that and you'll see what I mean. People even go as far as "When to use inheritance: Never".

> we'll be required to read/write ES2015 style code if we want to develop apps in React, Angular, etc. because their documentation will be using the new syntax

Wrong. That only makes copy-paste harder, which is a minor inconvenience. Learn to solve problems, not copy-paste.

> Backporting things sucks, and will cause more problems than its worth.

That's what the tools do for you right? And when they break, it's a bigger headache than backporting, especially when tool/framework developers throw you a "WONTFIX" and closes your bug report because it was not a bug, but a feature.

> These points didn't really seem to sway his opinion

Then let him be. Trust me, give 5-6 months and you'll start to hear WTFs and OMGs, see "what is this crap?!" and "holy !" in your code, a lot of "TODO" and "NOTE", a lot of workarounds and stuff. Yep.