Highland.js(highlandjs.org)
highlandjs.org
Highland.js
http://highlandjs.org/
44 comments
RxJS author here. Right, an advantage is if you know the Java, .NET, Python, C++ version, etc, then you know the JavaScript version. That and we try to adhere to an Array#extras style following all of ES2015/ES7 Array methods.
Another advantage is that many frameworks such as Angular 2.0 are shipping with support for Observables, so that's a huge win for users of RxJS that it automatically just works.
Another advantage is that many frameworks such as Angular 2.0 are shipping with support for Observables, so that's a huge win for users of RxJS that it automatically just works.
Yep I'm confused why Highland exists. Maybe if it was a sugar layer over Rx?
Nice library, but please don't use the underscore variable (_). So many people use Underscore.js and Lodash.js that it makes reading your docs confusing.
You can name it whatever you want. That's one of the benefits using a module system.
So why do we have this trend of using meaningless and ambiguous identifiers, and in particular, why would you do it in example code? I thought that as an industry, we'd moved past the folly of giving things terse and unhelpful identifiers in order to save a few bytes or keystrokes.
I think the example code is written using _ to convey the similarity for those familiar with underscore/lodash. In 2015, that's most JS developers.
Just hazarding a guess.
Just hazarding a guess.
You notice that all the libraries that do this (underscore, jQuery, Lodash, et al.) offer features that are almost language features. Things so useful but generic that they could almost be integrated into the language syntax.
In this case, there's also the problem that 'Stream' is already used by node.
In this case, there's also the problem that 'Stream' is already used by node.
> In this case, there's also the problem that 'Stream' is already used by node.
Haha, well, your grandparent would like you to know that's no reason to avoid a particular name. Module system! ;)
Haha, well, your grandparent would like you to know that's no reason to avoid a particular name. Module system! ;)
> var BoringStream = require('stream');
> var Stream = require('highland');
> var $tream = require('highland');
[deleted]
Just as you wouldn't use multiple libraries that bound a CSS selector function to the $ variable, I don't think you'd use underscore and lodash in the same javascript code. Similarly, highlandjs looks to supplant the underscore idioms with stream semantics, and you wouldn't mix both libraries in the same codebase.
Yeah that's basically what his point is. Except you misunderstood to interpret any suggestion that people use underscore and lodash together.
While I can grant that it does seem to solve a lot of the same problems as underscore and lodash, this is just asking for confusion and complication down the road. You shouldn't make a decision that makes things hard for people to deal with in the future if they choose to use your product. There is well established meaning now to $ and _ in js land, pick another identifier.
I still think the collision with underscore and lodash is intentional and appropriate. It makes a statement saying, "this library is designed to supplant underscore. Do not use underscore and this library together".
> Do not use underscore and this library together
Together in the same module. One can port one module at a time. It's what I do in my current job, each module can use a different set of technologies and we don't have to port everything at once.
Together in the same module. One can port one module at a time. It's what I do in my current job, each module can use a different set of technologies and we don't have to port everything at once.
I'm not certain I understand how their use of _ is any different from Lo-dash or Underscore's use of the variable. Just because they're not first to the party doesn't mean they can't hop on the established semantics.
Their use of _ actually made it easier for me to follow their examples.
Their use of _ actually made it easier for me to follow their examples.
I think that it's pretty reasonable for a similar library to use the same character if the syntax is similar. As an example, the Domtastic library copies the jQuery syntax literally, allowing an easy transition for new users.
It also makes users aware that the library is likely to cover aspects of the other, so they should carefully consider if they really want to include the new one.
It also makes users aware that the library is likely to cover aspects of the other, so they should carefully consider if they really want to include the new one.
$ is used for doc.QS or doc.QSA pretty frequently these days
I agree with not using the underscore character, while Underscore/Lodash are still popular. Personally, I do `H = require('highland')`, whenever I'm using it.
For real. Highland should just use an H.
That's exactly what I use, var h = require('highland');
Or a Greek capital letter Lambda: Λ
Λ(['1', '2', '3'])
Λ(['1', '2', '3'])
Is that a valid variable name? Would that mean Λ is unicode?
It is a valid Unicode letter so should be acceptable in EcmaScript 5.
Looks similar to Lazy.js (to my uneducated eyes) and also rx.js. To the author: Why should I use Highland.js instead of either of these?
RxJS authoer here. Instead, here are the reasons you may want to consider RxJS instead of Highland https://github.com/Reactive-Extensions/RxJS/blob/master/doc/...
Very interested as I use Async.js in virtually all of my node projects. I'm liking the idea of a 'toolkit' approach more than Async (which just feel like a monolithic lib), will definitely be trying it out soon.
async.js changed my life, async programming can get out of hand in a hurry.
So what's the benefit of using streams instead of a normal array?
Processing data as it becomes available instead of waiting for the whole thing, amongst other things (that's what we do in Scala anyway.)
If you're just mapping an array to double each element, there is no benefit.
Which is another way of saying that the examples in this doc are not very good, unfortunately.
Which is another way of saying that the examples in this doc are not very good, unfortunately.
Is this similar to what transducers do in Clojure? My understanding there is that they allow you to do things like map over core.async channels.
According to my understanding of transducers (warning: possibly inaccurate), that's one use-case of transducers. Transducers are a way to let you map over anything, including (but not limited to) channels, streams, etc.
I love highland one of my go to libraries these days.
[deleted]
"This site or app is sending too much traffic to rawgit.com. Please contact its owner and ask them to use cdn.rawgit.com instead, which has no traffic limit."
[deleted]
If it's not a drop in replacement for underscore or lodash, please don't use "_".
I see nothing wrong with using "_". It's just a variable name. The first snippet of code and preceding paragraph are:
> If you prefer using highland under the name _ like is done in the examples below, you can then simply use: > > var _ = highland
So it's not like you are required to use "_". And if it is a local variable, there is no risk of colliding with Underscore.
> If you prefer using highland under the name _ like is done in the examples below, you can then simply use: > > var _ = highland
So it's not like you are required to use "_". And if it is a local variable, there is no risk of colliding with Underscore.
" If you prefer using highland under the name _ like is done in the examples below, you can then simply use:
var _ = highland"
No. No, no, no. Goodness me.
var _ = highland"
No. No, no, no. Goodness me.
Re: Highland vs. RxJS, RxJS operates at a lower level interface [0]. As a plus for RxJS, Reactive Extensions are available for multiple languages, not just JS [1].
[0] https://twitter.com/_ericelliott/status/551814104231723009 [1] https://github.com/Reactive-Extensions/RxJS/blob/master/doc/...