German Joey posted:

Yeah, I just saw that too, and its finally the tipping point for me where I just gave up on node.js completely and go back to Django, or maybe Flask or Mojolicious, I haven't 100% decided yet. But absolutely that blogpost was the moment that I just said "gently caress it, I'm out, I can't deal with this node.js poo poo anymore." I'd rather spend a couple weeks rewriting my entire project then waste one more day fighting with a broken library. Maybe Sequelize is good now (I remember looking at that one specifically a few years ago and it being inadequate, although that was probably an early version because this looks OK), but the trend is pointing to probably not. I'm so sick of every loving javascript library being terrible!!! ARRGHH! Time after time after time, every new thing I look at has some flashy splash page but lovely, outdated, and inconsistent documentation. Every framework has ten trillion pointless preprocessors being stapled to it that otherwise reinvent the same drat wheel. If you need layers upon layers upon layers of build tools for your server-side javascript, then what the gently caress is the point of using javascript on the server side to begin with? Isn't the whole point that both client/server are in the same language, a language that everyone in the entire drat world happens to know and have access to - a language that any ten year old can start playing around with by pressing ctrl-shift-j in their browser? That's why I got into node.js to begin with!

And why is there so many broken rear end libraries/tools in the javascript ecosystem that do the exact same thing and NONE of them work right? It is a pandemic in the Javascript world that completely unlike any other language community I've seen. Even Perl's CPAN, which has shitloads of silly (e.g. the entire Acme:: namespace) and half-baked modules is nowhere near as bad as Javascript's situation because the vast majority of modules there are well-documented, automatically tested, reviewed... and centralized so you can see everything relevant at once. In contrast, new alternatives for the most minor goddamn poo poo are all over the web, especially client libraries. I find that raw jQuery is consistently the only thing I feel I can put my faith in. When I try searching for a new javascript library, I've realized that my initial expectation of *anything* I find is that it will not work or be what I need until proven otherwise. The general trend is to try to make easy poo poo even easier (why? why so much effort on something people can already do just fine?) while very few care about trying to make hard poo poo possible.

Sails/Waterline was the one framework I'd seen that even seemed like it was trying to move in the right direction, and then that turns out to be riddled with mind-bogglingly inane poo poo like this? "mystery 50ms sleep calls in put/post requests" "The .count function used to work by pulling the entire table into memory and checking the length of the resulting array." "table joins randomly deleting tables" "i don't even know what to say about this" I just need code that's supposed to work to just actually work, goddammit!

Odette posted:

Is node.js really that bad?

Just wondering cause I'm trying to learn the MEAN stack as opposed to a standard LAMP stack.

Knifegrab posted:

Speaking of node and js, what is the standard way to declare functions? is it:

code:

function myFunc(poop) {};

OR

code:

var myFunc = function(poop) {};

I've seen both ways, both being used by novice and expert coders alike.

Knifegrab posted:

Speaking of node and js, what is the standard way to declare functions? is it:

code:

function myFunc(poop) {};

OR

code:

var myFunc = function(poop) {};

I've seen both ways, both being used by novice and expert coders alike.

Odette posted:

Is node.js really that bad?

Just wondering cause I'm trying to learn the MEAN stack as opposed to a standard LAMP stack.

piratepilates posted:

As much as we hate on node.js (and I'm pretty sure most of us still have jobs paying us to work with it that we go along with) I feel like it's a way better idea than any LAMP stack.

Node.js has some very boneheaded stuff in it but you can still go pretty far if you pick the things you're using in it right.

Suspicious Dish posted:

Does node.js have sane error handling yet? That's the one thing I've hated, though, to be fair, a lot of other languages and frameworks are also much worse. Promises just made things worse by having things drop errors on the floor by default.

RobertKerans posted:

I'm playing around with the bind operator, and just for the experiment's sake I was trying to figure out how to have an optional first parameter that defaults to this.
So I have lib of a virtual functions, looks something like this:

code:

const List = {
  delete(item) {
    let index = this.indexOf(item)
    if(!index in this) return this

    return this.filter((_, i) => index !== i)
  },

  delete_at(index) {
    if(!index in this) return this

    return this.filter((_, i) => index !== i)
  }
}

Where I can do something like this, ie exactly the same as method chaining:

code:

> [0,1,2,3,4,5]::List.delete(5)::List.delete_at(0)
[1,2,3,4]

Which is cool, but I kinda want this option (like Underscore/LoDash allows), to optionally pass the item to operate on as the first argument or use this, and I'm at a loss:

code:

> List.delete([0,1,2,3], 2)
[0,1,3]
> [0,1,2,3]::List.delete(2)
[0,1,3]

Edit: nevermind, fixing the arity of the functions works.
So if done extremely naively:

code:

function add(a,b) {
  if(arguments.length == 1) {
     b = a
     a = this
  }
  return a + b
}

---

> 1::add(2)
3
> add(1,2)
3

Only thing is, how the hell do I pass the context through a decorator function, I just want to write this once for the entire lib, but I can't get it to give me the right this context

code:

const enforceArity = function(fun) {
  return function(...args) {
    if (wrongNumberOfArgs) {
      throw new Error('yadda yadda')
    } else if(fun.length - args.length == 1) {
      return // various attempts to call the function with the local `this` as first arg
    } else {
     return fun(...args)
    }
  }
}

const add = function(a,b) { return a + b }
const Calc = {
  add: enforceArity(add)
}

---

> Calc.add(1,2)
3
> 1::Calc.add(2)
NaN every time

// Explicitly:
> let c = Calc.add.bind(1)
> c(2)
NaN every time

obstipator posted:

It's all about hoisting. When you type the first one, as the javascript compiles, it notices that there's a function definition and it "processes" it's instructions up before everything else in scope. With the variablized version, it doesn't jump ahead and take care of it's existence until it hits the line it's defined on.

console.log(poo poo());
var poo poo = function(){};
// errors because "poo poo" hasn't been defined yet

console.log(poop());
function poop(){}
// works, because poop's definition gets moved to the top of the current scope.

function poop(){} should be used more for a constant definition that cannot change. The variable'd version should be used when you could possibly want to swap out the function that the variable holds, if that makes sense.

And with a file required by node, you have to do the exports.poo poo = function(){} in order to make the function public to outside files.

Knifegrab posted:

I know they're both valid but is there a "right" way?

pepito sanchez posted:

iirc it makes no difference except without quotes you USED TO be able to iterate over keys easier. now it's all different with ES5

Subjunctive posted:

What was easier about iterating over keys without quotes? They should produce identical objects.

pepito sanchez posted:

also worth noting that you have to use double quotes if you work with JSON, because some parsers are dumb.

pepito sanchez posted:

agh it's been a while. the quotes made it easier to iterate, not the other way around. i should've clarified how. and only for iteration in a certain way (with a for loop) and only if you, for some odd reason give your keys funky numerical names in the first place. this might be desirable for something like pushing new keys into an existing array of objects. i personally never did this that way. it's the way object keys are accessed.

was about to do more [code] but found this very helpful link that answers stuff
https://mathiasbynens.be/notes/javascript-properties

quote:

also worth noting that you have to use double quotes if you work with JSON, because some parsers are dumb.

RobertKerans posted:

I have never encountered this before, and it's breaking a load of my tests, just wondering if anyone could explain it:

code:

> function itself() { return this }
undefined
> e = itself.bind('foo')
[Function]
> e()
{ '0': 'f',
  '1': 'o',
  '2': 'o' }

I don't get it, why can I not just have a string returned back to me instead of a literal representation of a boxed version? I don't see why that's too much to ask for

Edit arrgh FFS course I've encountered this thing before, bind call and apply all convert primitives to objects, it just generally hasn't made any difference to the actual end result

Chenghiz posted:

Quotes also let you define keys with spaces in them.

Sedro posted:

Knifegrab posted:

What kind of monster does this!?

pepito sanchez posted:

also worth noting that you have to use double quotes if you work with JSON, because some parsers are dumb.

Knifegrab posted:

I just tested this in the browser and in node and Json seems to be able to stringify objects whose properties were not declared in quotes no problem...

Knifegrab posted:

I just tested this in the browser and in node and Json seems to be able to stringify objects whose properties were not declared in quotes no problem...

Knifegrab posted:

am I to believe they actually produce different objects?

Subjunctive posted:

No, pepito is making no sense. If it's legal to leave unquoted, then doing so produces exactly the same result as quoting the key. The specification requires it.