Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ES6 Classes

javascriptjanuary.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: ES6 Classes

#31

Post by matthewmacleod »

wanted2 wrote: post #24
Waterluvian wrote: post #17

Earlier quoted context omitted.

This is... puzzling. Where do you see these attitudes? Both ways are perfectly cromulent and it's fine for people to have opinions. In my years of JS dev the main thing I've seen from the community is "pick a style and stick to it. Be consistent." And that's pretty typical and sage advice of all programming. The reason to downvote parent is that it's bringing up a tired debate. We may as well discuss tabs vs. spaces…

> The reason to downvote parent is that it's bringing up a tired debate. Do you mean that even when it is scientifically proved that your code is more readable when using more white space like in: console.log( "Hello world!" ); we are not even allowed to mention that because some random dudes decided we have to adhere to the "airbnb" settings? I bring this up because I think it's pathetic, like many other things in t…

No, you’re free to talk about whatever you want. But don’t expect pointless bikeshedding to be well-received.

First, it’s not a real problem. The JS community is pretty much equivalent to any other of this matter.

Second, it’s not a big issue. Use a code formatter to make sure shared code is in the agreed style for whatever project you are contributing to.

Third, this does not affect your own code. You are free and encouraged to use whatever formatting convention works for your own teams. Just make sure it’s consistent and enforced.

Keeping consistent style is anything but a “silly rule” and it’s essentially no effort.

Re: ES6 Classes

#32

Post by labster »

ronilan wrote: post #14
runarberg wrote: post #4

Earlier quoted context omitted.

From MDN[1]: > JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Calling something “syntactical sugar” makes it sound unhealthy. I found the ES6 classes to be very helpful in conceptualizing stuff. When I started playing with them I’ve built myself a demo https://codepen.io/ronilan/pen/PObzew as a clone of same done previously in Ruby. Then I found classes to be very useful for bigger “vanilla” projects ( https://github.com/ronilan/BlockLike ) I’d call them “syntactical vitamins”.

There's no alliteration there. I'd go with syntactic soylent.

Re: ES6 Classes

#33

Post by kowdermeister »

ChrisSD wrote: post #30
kowdermeister wrote: post #28

Earlier quoted context omitted.

It's "javascript classes" why should it 1:1 copy Java or other languages? Just for the sake of people coming from other language background I don't see it justified. Do people complain about differences between C++, Java, C# classes?

Because it uses a fundamentally different model to C++, Java and C# classes?

But it's also used for kinda the same thing. Besides the naming I find it a very welcome addition to the language.

Re: ES6 Classes

#34

Post by gedy »

dmitriid wrote: post #22
gedy wrote: post #11

Earlier quoted context omitted.

I think the point was to simplify the JS Prototype syntax to be more "normal-looking" and less confusing to devs, not some rich OOP model compared to true OOP languages.

> I think the point was to simplify the JS Prototype syntax to be more "normal-looking" and less confusing to devs So they bolted on an incompatible thing that hides prototypes and is confusing to devs: class C { y = 10; // this fine. "methods" defined as class properties // have access to proper `this` due to how class properties work // and scoping rules x = () => if(this.y > 10) this.y = 10; constructor() { // if…

Sure, but this is being addressed in: https://github.com/tc39/proposal-class-fields

And available now as: https://babeljs.io/docs/en/babel-plugin-proposal-class-prope...

Re: ES6 Classes

#35

Post by seekbeak »

nightski wrote: post #21
_31 wrote: post #16

I'm happy about the class syntax additions that came with ES6, especially the method definitions. It's increased my productivity (and happiness) when working with js.

My only complaint is having to manually bind methods in the constructor. I understand why it's necessary but it is tedious. I suppose the answer is to just use TypeScript but we are talking about ES6 here.

Can't the majority of that manual binding be done by good 'ol fat arrows?

Re: ES6 Classes

#36

Post by wanted2 »

matthewmacleod wrote: post #31
wanted2 wrote: post #24

Earlier quoted context omitted.

> The reason to downvote parent is that it's bringing up a tired debate. Do you mean that even when it is scientifically proved that your code is more readable when using more white space like in: console.log( "Hello world!" ); we are not even allowed to mention that because some random dudes decided we have to adhere to the "airbnb" settings? I bring this up because I think it's pathetic, like many other things in t…

No, you’re free to talk about whatever you want. But don’t expect pointless bikeshedding to be well-received. First, it’s not a real problem. The JS community is pretty much equivalent to any other of this matter. Second, it’s not a big issue. Use a code formatter to make sure shared code is in the agreed style for whatever project you are contributing to. Third, this does not affect your own code. You are free and e…

It is a real problem, I've seen heated discussions in a few companies, and it can take out a big part of the fun you have in your work.

We really need to write an editor plugin/solution for this. Your editor should show the code in your preferred style, but saving it in the team's agreed style. And then a local-style.js for your own settings, and a team-style.js for the team settings. local-style.js in the .gitignore. Should be possible though?

Re: ES6 Classes

#37

Post by Waterluvian »

wanted2 wrote: post #36
matthewmacleod wrote: post #31

Earlier quoted context omitted.

No, you’re free to talk about whatever you want. But don’t expect pointless bikeshedding to be well-received. First, it’s not a real problem. The JS community is pretty much equivalent to any other of this matter. Second, it’s not a big issue. Use a code formatter to make sure shared code is in the agreed style for whatever project you are contributing to. Third, this does not affect your own code. You are free and e…

It is a real problem, I've seen heated discussions in a few companies, and it can take out a big part of the fun you have in your work. We really need to write an editor plugin/solution for this. Your editor should show the code in your preferred style, but saving it in the team's agreed style. And then a local-style.js for your own settings, and a team-style.js for the team settings. local-style.js in the .gitignore…

You could absolutely make that. It sounds neat.

Re: ES6 Classes

#38

Post by oklahoma »

dmitriid wrote: post #22
gedy wrote: post #11

Earlier quoted context omitted.

I think the point was to simplify the JS Prototype syntax to be more "normal-looking" and less confusing to devs, not some rich OOP model compared to true OOP languages.

> I think the point was to simplify the JS Prototype syntax to be more "normal-looking" and less confusing to devs So they bolted on an incompatible thing that hides prototypes and is confusing to devs: class C { y = 10; // this fine. "methods" defined as class properties // have access to proper `this` due to how class properties work // and scoping rules x = () => if(this.y > 10) this.y = 10; constructor() { // if…

You don't have to bind 'method' in the constructor to access 'y'. Just put 'this.y = 10;' in the constructor. Your example isn't legal JavaScript.

Re: ES6 Classes

#39

Post by dmitriid »

oklahoma wrote: post #38
dmitriid wrote: post #22

Earlier quoted context omitted.

> I think the point was to simplify the JS Prototype syntax to be more "normal-looking" and less confusing to devs So they bolted on an incompatible thing that hides prototypes and is confusing to devs: class C { y = 10; // this fine. "methods" defined as class properties // have access to proper `this` due to how class properties work // and scoping rules x = () => if(this.y > 10) this.y = 10; constructor() { // if…

You don't have to bind 'method' in the constructor to access 'y'. Just put 'this.y = 10;' in the constructor. Your example isn't legal JavaScript.

It's perfectly legal Javascript. Why would I put this.y = 10 in the cinstructor? Do you even understand what this code does?

   const instance = new C();
   for(let i = 0; i
If you don't bind `this` to `method` in the constructor, when you call `instance.method()`, `this` will be whatever (window, IIRC).

Don't believe me? Try a more complex example like React's event handling with `this.setState()`: https://reactjs.org/docs/handling-events.html

Re: ES6 Classes

#40

Post by dmitriid »

gedy wrote: post #34
dmitriid wrote: post #22

Earlier quoted context omitted.

> I think the point was to simplify the JS Prototype syntax to be more "normal-looking" and less confusing to devs So they bolted on an incompatible thing that hides prototypes and is confusing to devs: class C { y = 10; // this fine. "methods" defined as class properties // have access to proper `this` due to how class properties work // and scoping rules x = () => if(this.y > 10) this.y = 10; constructor() { // if…

Sure, but this is being addressed in: https://github.com/tc39/proposal-class-fields And available now as: https://babeljs.io/docs/en/babel-plugin-proposal-class-prope...

No, it's not addressed. And you can see me using class fields already in `x = () => ...` The fact that arrow functions declared as class fields get access to the proper `this` in the class instance is just a happy(?) coincidence with its own downsides. For example, class fields can't be inherited in the child class. So this adds a yet another layer of confusion for devs.

And as you see in the example at the link you provided, you still need to `.bind(this)` the actual methods.

Post reply on HN