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

91–100 of 129 posts

Re: JavaScript in 2015

#91

Post by tabrischen »

tabrischen wrote: post #90
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.

'I really would love to see a youtube of a DJ hooked up to automatically synced GIFs. ' Yes, this please !

( and if not, an invite to your next rooftop party would probably suffice )

Re: JavaScript in 2015

#92

Post by danabramov »

Bahamut wrote: post #87
hij1nx wrote: post #76

Earlier quoted context omitted.

npm is not just a server side package manager. It handles package management for the front-end very well and has for a long time, learn more here -- http://browserify.org/ .

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 better than Bower if your app is moderately complex.

Re: JavaScript in 2015

#93

Post by zak_mc_kracken »

chrisdotcode wrote: post #85
_greim_ wrote: post #81

Earlier quoted context omitted.

> Async actions as a language-level construct, as opposed to a syntactic abstraction has always been A Bad Idea. Are you saying that the upcoming async/await features of JS are a bad idea? Or maybe I'm not following; can you give an example?

This: images is objectively easier to reason about than: var images; get("http://example.com/images.json", (err, resp) => if err throw err; images = resp; even though the former might be internally implemented as the latter. In addition, the former doesn't give the programmer the 'opportunity' to cause a race-condition, and encapsulates the failure entirely for you (automatically and defaultly); If `images` ends up e…

It's mostly easier to read because it no longer deals with error cases. All code becomes easier to read if you ignore errors.

I can make my code arbitrarily short if it doesn't have to be correct.

Re: JavaScript in 2015

#94

Post by nwienert »

lucian1900 wrote: post #58
chrisdotcode wrote: post #52

What's interesting is that all of the 'niceness' seen is the result of a switch to the functional style. Excluding the singleton class (which could have been a single function itself), you've got your map/filters in the gif processing, and encapsulation of async activities[0] through monads via promises. Seems like JavaScript got good when it started embracing what functional programmers have been drowned out saying…

Except for immutability. It's still nowhere near the norm.

I'm working on a JS stack that leverages React, es6, functional style programming, and immutable data. Check my profile for more info.

Re: JavaScript in 2015

#95

Post by chrisdotcode »

zak_mc_kracken wrote: post #93
chrisdotcode wrote: post #85

Earlier quoted context omitted.

This: images is objectively easier to reason about than: var images; get("http://example.com/images.json", (err, resp) => if err throw err; images = resp; even though the former might be internally implemented as the latter. In addition, the former doesn't give the programmer the 'opportunity' to cause a race-condition, and encapsulates the failure entirely for you (automatically and defaultly); If `images` ends up e…

It's mostly easier to read because it no longer deals with error cases. All code becomes easier to read if you ignore errors. I can make my code arbitrarily short if it doesn't have to be correct.

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

Re: JavaScript in 2015

#96

Post by woah »

linhmtran168 wrote: post #38
danabramov wrote: post #13

What will SystemJS+JSPM give me over Webpack? Just curious. Webpack also supports ES6 modules (as well as CJS and AMD) when used with 6to5 transpiler, and has a lot of great features like splitting code into bundles, figuring out the best way to split dependencies based on module size, and asynchronously loading missing chunks.

Haizz, I've just learned to use Webpack. Now comes SystemJS+JSPM. There are just too many new tools, workflows and different ways of doing things in Javascript world.

It's just not that hard. Try it and see if you like it.

Re: JavaScript in 2015

#97

Post by peferron »

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 by many developers of varying experience levels. The nice things about smaller languages is that there's often only one way to do something, so when you write code or review other people's code, your mind is free from the minutiae and you can focus on the big picture instead.

It's a bit funny that it's when JS is, from the general consensus, finally getting "better" that I'm actually considering more and more switching to a small but well-built compile-to-JS language. I guess smallness and simplicity just matter a lot to me.

Re: JavaScript in 2015

#98

Post by serve_yay »

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.

Re: JavaScript in 2015

#99

Post by zak_mc_kracken »

chrisdotcode wrote: post #95
zak_mc_kracken wrote: post #93

Earlier quoted context omitted.

It's mostly easier to read because it no longer deals with error cases. All code becomes easier to read if you ignore errors. I can make my code arbitrarily short if it doesn't have to be correct.

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.

Re: JavaScript in 2015

#100

Post by nawitus »

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 would think that most languages suffer from this at least as much as JavaScript. The solution is to have guidelines and enforce them through code reviews. Linters can also catch some of the rules.

I'd say that JavaScript's benefit is that it's so simple that there are not too many solutions to do the same thing, unlike massive enterprise languages like C# and Java.

Post reply on HN