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

JavaScript in 2015

glenmaddern.com

Post reply on HN
Print view View original

111–120 of 129 posts

Re: JavaScript in 2015

#111

Post by lomnakkus »

peferron wrote: post #97

My biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing. Iteration: for (var i = 0; i Comparison: == === Object.is() (would have been a good laugh if introduced as ==== instead) Of course, this doesn't matter much if you're a single developer. I've started writing a bit of ES6/ES7 and it's pretty cool. But it's going to be a PITA for projects built…

Just looking at your example:

    for (var i = 0; i
None of the "for" variations are considered good practice in ES6. You should be using "let" (or "const" if it's allowed here) to avoid var-hoisting of "i".

Personally, I'd advocate using "for" if you have a need for early return/break/continue -- otherwise I'd go for the first forEach() variant. Or, even better, use "map" and avoid side effects in the function you're mapping over the collection. Unless of course you're doing something imperative.

The fact that the last forEach() variant is possible is a good thing, though I wouldn't recommend its use in this case because it's needlessly complex -- it shows that the language/stdlib is becoming more compositional.

Re: JavaScript in 2015

#112

Post by riffraff »

frik wrote: post #107
peferron wrote: post #97

My biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing. Iteration: for (var i = 0; i Comparison: == === Object.is() (would have been a good laugh if introduced as ==== instead) Of course, this doesn't matter much if you're a single developer. I've started writing a bit of ES6/ES7 and it's pretty cool. But it's going to be a PITA for projects built…

I am unsure about some ES6 additions. Thanks to Crockford we got a decent ES5. Remember that several syntax changes got postpones to ES6. And don't forget about "E4X", a beast that was supposed to be JavaScript 2? http://www.ecma-international.org/publications/standards/Ecm... It got similar traction as XHTML 2. Both had no backwards compatibility - an insane idea. Some new features in ES6 look like Crockford "good p…

I really wish E4X had gotten traction. I wrote a firefox extension using it and it was awesome to do XUL + JS with it.

Years later

  var foo = {item};
is the new hotness in facebook's JSX.

Re: JavaScript in 2015

#113

Post by sarciszewski »

beejiu wrote: post #110
sarciszewski wrote: post #32

Earlier quoted context omitted.

A lot of the ones he presented are easy to understand. It's still a WTF when you run into it though.

All you have done is used a function without understanding what it was doing, or reading the documentation. Most JS developers know how parseInt works, and even if they run into this problem, would quickly discover the cause. I don't see how this is a flaw of Javascript; it could happen to a developer of any language, if their strategy is 'well, it looks like it'll work'.

> All you have done is used a function without understanding what it was doing, or reading the documentation

These aren't my examples. I haven't done anything. I credited the person who provided them: Gary Bernhardt.

https://www.destroyallsoftware.com/talks/wat

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Next time before you make an accusation, reread the post before pressing the reply button.

Re: JavaScript in 2015

#115

Post by _random_ »

benaiah wrote: post #106
BigChiefSmokem wrote: post #104

Instead of creating yet-another-library, yet-another-framework or superset (TypeSscript, etc.) of it we should try to fix JavaScript itself. Why companies don't push for this even if it's in all their best interests is beyond me.

They are . That's what ES6, a major focus of TFA, is .

They are not fixing JS, they are extending it. That's a different thing. Because backwards-compatibility.

Re: JavaScript in 2015

#116

Post by _random_ »

oneeyedpigeon wrote: post #8
collyw wrote: post #3

Still has more WTF moments than any other language I have used so far.

Your comment might be useful or interesting if you explained which WTF moments affected you in particular, or even just which other languages you've used. As it is, it's not adding much to the conversation which is why you've been downvoted.

Here you go: http://wtfjs.com

Re: JavaScript in 2015

#117

Post by _random_ »

pestaa wrote: post #24
lordbusiness wrote: post #18

Earlier quoted context omitted.

I'm really late to the JS party, having just picked it up a month or so ago. node.js and Meteor are my current tools of choice; it's a rather super environment to get stuff done in. It's nice to see JS get some positive press.

In fact, JavaScript is the one late to the party, having developed some rudimentary tools only recently. There's nothing exciting about redoing old mistakes in a new ecosystem.

Don't say things like that on HN. Say "Wow, amazing! I did not know this is possible in JS! JS is the future, other languages are not needed!"

Re: JavaScript in 2015

#118

Post by ender7 »

serve_yay wrote: post #98
peferron wrote: post #97

My biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing. Iteration: for (var i = 0; i Comparison: == === Object.is() (would have been a good laugh if introduced as ==== instead) Of course, this doesn't matter much if you're a single developer. I've started writing a bit of ES6/ES7 and it's pretty cool. But it's going to be a PITA for projects built…

Object.is is a very silly addition to the language. It does the same thing as === except in the case of NaN and positive/negative zero. I mean if you read a polyfill for it, it's such a silly bit of "functionality". And of course the name is terrible. Argh.

The new Map and WeakMap classes use Object.is() to determine if two keys are the same (otherwise it would be impossible to use NaN as a key to a map).

Whether this algorithm should have been exposed to users is debatable, but it exists for a good reason.

Re: JavaScript in 2015

#119

Post by pcthrowaway »

peferron wrote: post #97

My biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing. Iteration: for (var i = 0; i Comparison: == === Object.is() (would have been a good laugh if introduced as ==== instead) Of course, this doesn't matter much if you're a single developer. I've started writing a bit of ES6/ES7 and it's pretty cool. But it's going to be a PITA for projects built…

> My biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing

To be fair though, this has been an issue with Javascript since its creation (and has been getting worse as the language has been expanded while maintaining backwards-compatibility).

Many other languages have similar problems (Ruby is an offender that comes to mind, though it's perhaps not on the level of ES6+)

I'm not much of a polyglot, but one language which seems to have "one obvious way" as part of its design choices that springs to mind is Python. I have a hunch that pure-functional languages would be less choicy as well, though I have no familiarity with any.

Re: JavaScript in 2015

#120

Post by peferron »

lomnakkus wrote: post #111
peferron wrote: post #97

My biggest issue with the recent additions to the language is that there's now a thousand different ways to do the same thing. Iteration: for (var i = 0; i Comparison: == === Object.is() (would have been a good laugh if introduced as ==== instead) Of course, this doesn't matter much if you're a single developer. I've started writing a bit of ES6/ES7 and it's pretty cool. But it's going to be a PITA for projects built…

Just looking at your example: for (var i = 0; i None of the "for" variations are considered good practice in ES6. You should be using "let" (or "const" if it's allowed here) to avoid var-hoisting of "i". Personally, I'd advocate using "for" if you have a need for early return/break/continue -- otherwise I'd go for the first forEach() variant. Or, even better, use "map" and avoid side effects in the function you're ma…

Yes, "let" is better than "var". I could also have used a fat arrow in the forEach(). But my point was to list iteration variations, so outside of that I wrote traditional ES5.

This illustrates the issue though. "var" is like "let" but without block scoping, so you should almost never use "var", but it's still there to trip newcomers. The fat arrow is like the "function" keyword and most of the time you can use them interchangeably, but if you rely on "this" they're not interchangeable anymore.

This growing laundry list isn't exactly thrilling. I'm glad to have map(), filter(), every() and friends, though.

Post reply on HN