JavaScript in 2015 • Hacker News Board

Re: JavaScript in 2015

#101

Post by chrisdotcode » Wed, Jan 07, 2015, 6:50 PM UTC

zak_mc_kracken wrote: post #99

chrisdotcode wrote: post #95

Earlier quoted context omitted.

That's the magic of monads: the errors are all handled for you (in an encapsulated, lossless way), and you can deal with them (if you choose) at the end of the chain, just the same as promises (because promises are a monad).

The same can be said of exceptions. However, my comment above had nothing to do with how you handle errors, it was about the unsoundness of comparing code that handles errors to code that doesn't.

Right - What I'm saying is that the above former code does handle the error, in the exact same way as the latter code.

For clarification, the error is handled implicitly (but you'd know what kind of error it was due to the type signature), but you can always handle it in manner you choose to at any point.

Re: JavaScript in 2015

#102

Post by sanderjd » Wed, Jan 07, 2015, 7:02 PM UTC

1971genocide wrote: post #78

akanet wrote: post #4

God, he makes it look good. The demo does give me a few of the ol' "too much magic" heebie jeebies, but frontend JS development is so badly lacking in compelling packaage management stories that I'm going to give jspm a shot. Here's to 2015, I suppose. P.S. Glen, if you're reading this, I really would love to see a youtube of a DJ hooked up to automatically synced GIFs. Don't be a tease.

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?

Re: JavaScript in 2015

#103

Post by illicium » Wed, Jan 07, 2015, 7:10 PM UTC

eskimobloood wrote: post #11

I wonder if there is a way to split the build in more then just one big file but in several smaller files then can be loaded on runtime.

Use WebPack and set up code splitting

Re: JavaScript in 2015

#104

Post by BigChiefSmokem » Wed, Jan 07, 2015, 7:12 PM UTC

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.

Re: JavaScript in 2015

#105

Post by tel » Wed, Jan 07, 2015, 7:15 PM UTC

zak_mc_kracken wrote: post #99

chrisdotcode wrote: post #95

Earlier quoted context omitted.

That's the magic of monads: the errors are all handled for you (in an encapsulated, lossless way), and you can deal with them (if you choose) at the end of the chain, just the same as promises (because promises are a monad).

The same can be said of exceptions. However, my comment above had nothing to do with how you handle errors, it was about the unsoundness of comparing code that handles errors to code that doesn't.

It's not really the same as exceptions in a typed language because it's forced to be delimited. Even in Javascript you'll have to do a little ceremony to "escape" the golden path driven by the monad, though you'll have many ways to take short-cuts and forget details.

Re: JavaScript in 2015

#106

Post by benaiah » Wed, Jan 07, 2015, 7:18 PM UTC

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.

Re: JavaScript in 2015

#107

Post by frik » Wed, Jan 07, 2015, 7:23 PM UTC

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 parts" movement lost and Sun/Oracle Java evangelists won.

Hopefully Douglas Crockford updates his "JavaScript: The Good Parts" in time for JavaScript 6.

Re: JavaScript in 2015

#108

Post by hfsktr » Wed, Jan 07, 2015, 7:52 PM UTC

squeaky-clean wrote: post #79

hfsktr wrote: post #43

Earlier quoted context omitted.

I know what the batman example gives but I don't get how it's a WTF? I assume the expected output is "wa" but why should a string less an integer produce that?

There is no expected output. It doesn't make sense to subtract the value 1 from the string "wat". But Javascript will cast both of them to numbers, then try to subtract 1 from NaN. However, if you do "wat" + 1, Javascript will cast both of them to strings, and append "1" to "wat". It's not just the odd behavior, but the inconsistency.

Ok that makes a bit more sense. I didn't even think about how it would be if you tried to add them.

I like javascript but I don't do anything so complicated (or maybe not the right types of things) that I run into many of these situations.

Re: JavaScript in 2015

#109

Post by lomnakkus » Wed, Jan 07, 2015, 8:41 PM UTC

akanet wrote: post #4

God, he makes it look good. The demo does give me a few of the ol' "too much magic" heebie jeebies, but frontend JS development is so badly lacking in compelling packaage management stories that I'm going to give jspm a shot. Here's to 2015, I suppose. P.S. Glen, if you're reading this, I really would love to see a youtube of a DJ hooked up to automatically synced GIFs. Don't be a tease.

If you have new projects you can try this out on with out too much risk, then please do give this a go and report/blog about it!

(I, too, am extremely dissatisfied with the current state of ES5-based JS modularity. Frankly it's incredible that anyone can get anything done at all given the state of tooling for modularity/building/deployment ATM.)

Re: JavaScript in 2015

#110

Post by beejiu » Wed, Jan 07, 2015, 8:41 PM UTC

sarciszewski wrote: post #32

emehrkay wrote: post #31

Earlier quoted context omitted.

The first one is easy to understand though. parseInt takes two arguments: $thing_to_change and $radix; map iterates over an array and feeds it $value and $index. You're getting parseInt("10", 0); parseInt("10", 1) and parseInt("10", 2); The fix would be to partially apply parseInt with your defined radix; var foo = ["10", "10", "10"]; var base10 = function(val){ return parseInt(val, 10); }; x = foo.map(base10) [10, 1…

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