Conversation
I like this 👍 I think it could be worth using more ES6 niceties as well such as |
We use template strings everywhere in the Slack Desktop app, to the point that we've rigged ESLint to warn when you concatenate strings manually |
👍 to using new ES6 features wherever we can. |
The reason there is currently no ES6 in the app is because the goal of this is to be as approachable as possible. Using extra libraries that require specialized knowledge or using not widely adopted syntax, I believe, leads us further away from approachability. That being said, this is an application for demonstrating what Electron can do and one of those special things is using ES6 without a pre-compiler. But I want to make sure we keep ourselves in check and don't pepper in things we like because we like them but because they are useful, approachable ways that we can demonstrate what users can do with Electron.
I am 👎 on this sentiment because I don't think it's aligned with the goals of this app in particular. If we feel template strings and |
Are |
To me it's not about are the concepts of EDIT—Also, just to clarify I'm not against adding |
I'm happy to see both sides represented here. From an approachability standpoint, I think there's something to be said for vanilla ES5. More people are familiar with it, and won't be intimidated or confused by code snippets that contain new ES syntax. Flip side: There are number of things in ES6 that actually make code easier to read and understand. I think My vote would be to pepper in the ES6 niceties that we think help improve code clarity, and avoid syntax (like maybe arrow functions, rest, and spread) that might just make the code more confusing to newcomers. |
I do see @jlord's point and honestly I don't really care that much, but here's an example:
Is the first call more approachable than the second? I'd argue it's the opposite. ES5 has major usability issues that could be quite hostile to someone who is coming to Electron with no prior JS experience. I view ES6 as a solution to a lot of these problems, though I do admit there is a subset of its features that fall more on the "bells and whistles" end of the spectrum. All this said, maybe you just keep the examples simple enough to avoid any of these nasty corners. If you do encounter them though, I think you should go with the more readable option for a general audience, regardless of assumptions about past JS experience. But anyway, I trust both of your judgment and see the value of balancing "better" with "more familiar". |
I think certain features are more likely to cause confusion to others - like, people are gonna see template strings and be like "Oh, of course that's what it does". On the other hand, features like destructuring or arrows are I think more likely to cause confusion. ES5 devs who see something like: import { power } from 'electron'; or app.on('ready', (...args) => {
}); are gonna be thrown for a loop, but like: console.log(`the path is ${pathToFile}`); might not be initially familiar, but people will be like, "Oh cool that's a new thing I know now" |
So it sounds like there are multiple potential groups that have conflicting sets of things that are "unclear". Could we use this as an opportunity to educate people? Perhaps for anything that isn't typical ES5 (or anything we want/have to use that we feel might be confusing to one camp or another) we have a section in the demo for, "Hey, what's this strange syntax?" with links to relevant documentation? |
Thanks for the input, everyone. Closing this in favor of #86 |
See discussion in #79 for more context.
I personally like using template strings because it's easier than concatenating strings and variables together, especially when your target string contains quotes. I'm not sure how the rest of the team feels, though, so I changed a few instances here to get a conversation started.
What do you think, @electronjs/core?