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

121–129 of 129 posts

Re: JavaScript in 2015

#121

Post by lomnakkus »

peferron wrote: post #120
lomnakkus wrote: post #111

Earlier quoted context omitted.

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…

Have a pre-commit linter disallow "var". (etc. for everything else.)

In a language like JS you cannot have it all, but at least appreciate the improvements! ;)

Re: JavaScript in 2015

#122

Post by lomnakkus »

riffraff wrote: post #112
frik wrote: post #107

Earlier quoted context omitted.

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.

AFAIUI from the React people E4X had a lot of incidental complexity and extraneous stuff relative to JSX. So there's that.

I'd argue that with ES6, JSX could just reserve the "jsx" prefix for interpolated strings and go with

   jsx`blah`
but that's a typical hindsight-is-20/20-thing.

Re: JavaScript in 2015

#123

Post by 1971genocide »

sanderjd wrote: post #102
1971genocide wrote: post #78

Earlier quoted context omitted.

Do you have time to hear about our lord and saviour browserify ?

I thought jspm looked like a direct browserify competitor/replacement. Is that an incorrect interpretation?

I am not sure familiar with jspm or bower. In the limited 60 second window that i researched their site it seems jsmp doesn't have as much documentation as broswerify. If jspm comes up more often in npm then I will think about it.

Re: JavaScript in 2015

#124

Post by endemic »

danabramov wrote: post #92
Bahamut wrote: post #87

Earlier quoted context omitted.

I'm a bit torn over using npm this way. On one hand, being able to use tools already built in Node land such as the EventEmitter is nice. On the other hand, having to use Browserify and navigating the mess of node modules is a pita. If the dependency structure with Node modules for npm dependencies were handled better, I would likely be all for it, but it is a major negative for me, especially if a quick project star…

I happily use Webpack and NPM and have no problems with it. NPM is in fact fine for frontend package management, it's not just about being able to use "Node land tools". All my frontend deps are on NPM, I published some NPM packages myself, and I don't even use Node. Yes there are small issues (like wanting to be able to specify non-dupe requirement for some libraries) but overall NPM works fine for frontend. Much be…

Agreed. I never saw the point of Bower, since it requires Node itself anyway. With tools like Browserify (and, I assume, Webpack... haven't had a chance to use it yet), you can load dependencies into your project extremely easily: `npm install backbone --save-dev`, then `var Backbone = require('backbone');` in your code.

Re: JavaScript in 2015

#125

Post by insin »

lomnakkus wrote: post #122
riffraff wrote: post #112

Earlier quoted context omitted.

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.

AFAIUI from the React people E4X had a lot of incidental complexity and extraneous stuff relative to JSX. So there's that. I'd argue that with ES6, JSX could just reserve the "jsx" prefix for interpolated strings and go with jsx` blah ` but that's a typical hindsight-is-20/20-thing.

This blog post - "JSX: E4X The Good Parts" - covers what's in and out for JSX:

http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts...

Re: JavaScript in 2015

#126

Post by path411 »

lmkg wrote: post #88
untog wrote: post #39

Earlier quoted context omitted.

While these are WTF moments, when is anyone actually going to run [] + [] in a real project? The map to parseInt is the only one that's even close to something you'd actually write.

Writing literal [] + []? No. Writing x + y where x and y are both arguments to a function, and some call site was passed an (empty?) array of integers instead of an integer? Believable.

So the real problem is passing wrong parameters to a function? Sounds like you should swap to something like TypeScript for strict typing then.

Or you know, stop acting like JavaScript is unique in that improper function calling breaks your code.

I can't believe in 2015 there are still people who follow the "JavaScript equalities are WTF" mentality. If you are running into equality operator problems in JS, you are probably going to run into a myriad of problems in any language.

Re: JavaScript in 2015

#127

Post by untitaker_ »

path411 wrote: post #126
lmkg wrote: post #88

Earlier quoted context omitted.

Writing literal [] + []? No. Writing x + y where x and y are both arguments to a function, and some call site was passed an (empty?) array of integers instead of an integer? Believable.

So the real problem is passing wrong parameters to a function? Sounds like you should swap to something like TypeScript for strict typing then. Or you know, stop acting like JavaScript is unique in that improper function calling breaks your code. I can't believe in 2015 there are still people who follow the "JavaScript equalities are WTF" mentality. If you are running into equality operator problems in JS, you are pr…

Except in any decent language, however typed, improper function calling creates errors.

I can't believe in 2015 there are still people who follow the "invalid input should produce invalid output" mentality.

Re: JavaScript in 2015

#128

Post by wal0 »

untog wrote: post #89
lmkg wrote: post #88

Earlier quoted context omitted.

Writing literal [] + []? No. Writing x + y where x and y are both arguments to a function, and some call site was passed an (empty?) array of integers instead of an integer? Believable.

I've been writing JS professionally for, what, a decade now - and I've never once had this issue.

It's not about this causing issues IMO. It's just.. why? Why would '+' not be commutative? Why not throw an error? What is the use-case for "adding" '[]' and '{}'?

Or, put another way: why would a programmer want to have this "feature" instead of being notified: "hey, you're adding '[]' and '{}', that doesn't make any sense, fix that!"

Sure you can work with a language like that. But it sure doesn't feel like somebody thought all of this this through.

Re: JavaScript in 2015

#129

Post by prezjordan »

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

Nope. Behavior should be pretty straight-forward, I shouldn't have to load up the docs to convert something to an integer.
Post reply on HN