
Ask HN: How do I inspire my coworkers to adopt new code standards like ES2015? - lostPixels
We&#x27;re beginning a new site launch project, and currently in the midst of assembling our strategy around the Javascript architecture.<p>After so research I opted to vote for using Webpack and BabelJS. Our tech lead is concerned that our team isn&#x27;t ready to use &quot;advanced javascript&quot; and it will cause issues.<p>My answer was that ES2015 encompasses a lot of additions to the language, and that we don&#x27;t have to use all of them. Things like fat arrows would be a quick win. We don&#x27;t have to start using Classes unless we all agree that it&#x27;s a good idea. This didn&#x27;t really seem to sink in though ufortunately.<p>We&#x27;re going to have to maintain this site for 4-5 years, and in the near future we&#x27;ll be required to read&#x2F;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.<p>These points didn&#x27;t really seem to sway his opinion, so I&#x27;m hoping to get some outside feedback on how you&#x27;ve pitched this topic to your teams and won their approval.
======
softyeti
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
Point them to
[https://ponyfoo.com/articles/es6](https://ponyfoo.com/articles/es6)

------
lollipop25
> 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.

