TodPunk posted:

I have always felt Node.js is a nice toy that got taken way too seriously. I get it as a prototyping platform or something, just like I write my prototypes in flask or (if I need some more structure) pyramid, but only because I know python. You CAN take those to production I guess, as they're just tools albeit poor ones, but I don't know why people get all googly eyed over any of them unless that's literally all they know.

"Oh but this fits our needs in production!" I hear this all the time, especially at meetups and such, and invariably if you ask in earnest it just turns out they know how to use thing X and they can solve the problem in thing X with a healthy dose of googling "How do I do <part of X>" so they do that and it displays on the page. That's fine, good for them for building a thing, but if they knew more about the landscape they'd know why it causes headaches in the long run and why its less efficient than any number of other things for their specific needs. Granted, on the other end of the spectrum, if more senior programmers weren't such asshats about the "hipster javascript enthusiasts" and instead were more accepting of their strictly beginner-with-potential status, we'd be helping rather than creating camps at war.

Webdev is just terrible all around. It pays the bills, but having done embedded dev, application dev, systems dev, and FAA bureaucracy laden versions of some of that, web dev is definitely the more clown shoes of the bunch. It also requires the most oddball knowledge set to really do it well. For instance, you CAN setup a website with both backend and frontend in Javascript without knowing what an IP address is (I'm serious, I see it done all the time) but when something breaks (it always does) it's going to be a "learning experience" to be sure. Most other programming requires you know things like that up front before you can even code the solution to your problem. Web dev has abstractions upon abstractions hiding virtually everything from you unless you know how it works behind the walls.

Essentially, web dev is to most programming what interior decorating is to most construction. I say this as a terrible interior decorator.

TodPunk posted:

Webdev is just terrible all around. It pays the bills, but having done embedded dev, application dev, systems dev, and FAA bureaucracy laden versions of some of that, web dev is definitely the more clown shoes of the bunch.

Jo posted:

It's probably misplaced nostalgia, but oh for the days when there were tons of dedicated desktop applications communicating over protocols other than HTTP.

more like dICK posted:

You could just do your prototypes with a good language

pepito sanchez posted:

ES6 does prototypal inheritance pretty easy and straightforward, i think.
https://www.youtube.com/watch?v=CozSF5abcTA

i just use typescript to transpile into es5 but i'm sure there must be some alternative out there.

I'm Crap posted:

I think people are being unnecessarily negative about node in here. It's great for toy-size apps and prototypes where the problems (potentially unmanageable code, crap debugging, slightly "ehh" performance) aren't going to bite you.

piratepilates posted:

I'm not sure there's a much (reasonably) lower bar than that for a piece of technology. At that point what is it even doing in these toy-size apps and prototypes that any other language isn't doing for you?

Maluco Marinero posted:

Yeah, the issue is today's prototype is tomorrow's production. PayPal essentially transitioned from prototyping in node.js to deploying production in node.js. Whether this choice holds up in the long term remains to be seen, but we've seen the consequences of such a choice before in Rails applications. Facebook gets by with PHP via a furious case of digging up (optimisations, compilers and what not).

Also, as said there are far better languages to do these prototypes in, with far healthier ecosystems for back end tech. I have no idea when a decent SQL Statement Mapper will come existence, maybe follow a relation or two.

Prototypes are best built with stable reliable libraries & frameworks, not a house of cards that sends you error chasing all the time.

Maluco Marinero posted:

You'll have to qualify narrowly bounded I'm afraid. Turns out I do use node in production, however I try to restrict that to what it's best at, rendering templates, forming the basis of a front end build system, sharing the render code for client and server code.

In cases where I have worked beyond that I find its error handling disappointingly leaky, it doesn't lend itself well to larger teams because of that, and the libraries it's built upon are immature, meaning wheel reinvention is often needed, including downright bizarre behaviours in even simple cases like trying to set a cookie in express + passport. (passport would override what I sent previously and change parameters on it).

Of course, everyone's development scenario is different, but there's a lot of things that are taken for granted in more mature languages that just can't be in Node. Anything can be used in production if you spend enough time papering over the problems to avoid abandoning your existing code, but that doesn't mean it's a good foundation to build new stuff on.

Hegel posted:

but the overbearing problems from things like a Java server-side application or the downright deplorable hell of maintaining inherited templates in Django are enough to convince me that any judicious dev team can deploy node effectively with greater efficiency than other pieces of tech for particular problems.

Stoph posted:

The error handling really is poo poo in Node.js.

Clojure seems like a better full stack language if that's the reason you're picking Node.js. Anyone tried that?

Tao Jones posted:

With Node, I often feel like I have no earthly idea in advance what a function is going to be returning. Is it going to be a promise? Is it going to be an object that isn't a promise? A string? Undefined because something got hosed up?

Similarly, I find I'm often in situations where if I try to deviate slightly from a provided example -- ie, in the tutorial everything is just mashed into one large function but in my code I want to break each piece into smaller functions -- I particularly hit this snag where async fucks things up or there's some weird promise interaction or something.

Is there any kind of cheat sheet or quick and dirty guide to where some common minefields are, or is this just the kind of stuff I just have to bang my head against?

piratepilates posted:

For the function returning types in advance thing, check the API docs. If the API docs don't give you a good sense of it then post an angry message on their Github and choose a better library, if there isn't a better library then you're screwed.

Not sure exactly what you mean by the second thing though.

edit: It may help to dig in to the internals of what the API is doing if you don't understand it. Set a breakpoint and step through it a bit and see what's in each object, maybe that'll help you figure out what they return.

edit: Oh how could I forget, just start using TypeScript. TS has definitions for types in the major NPM libraries so you'll have a much easier time figuring out what things are expecting.

Tao Jones posted:

With Node, I often feel like I have no earthly idea in advance what a function is going to be returning. Is it going to be a promise? Is it going to be an object that isn't a promise? A string? Undefined because something got hosed up?

Similarly, I find I'm often in situations where if I try to deviate slightly from a provided example -- ie, in the tutorial everything is just mashed into one large function but in my code I want to break each piece into smaller functions -- I particularly hit this snag where async fucks things up or there's some weird promise interaction or something.

Is there any kind of cheat sheet or quick and dirty guide to where some common minefields are, or is this just the kind of stuff I just have to bang my head against?

Tao Jones posted:

Oh, Typescript looks cool, I'll check that out more. Is it possible to have typescript and vanilla JS in the same Node app?

quote:

The second thing is that, and maybe this was more when I was first learning node, I didn't always understand async and promises (and neither did anyone else on my team) so we tended to make these monstrous endpoints where the validations and all of the data massaging before calling an external API and then all of the data munging and doing what the function's real work was were all in one function in one file. Later on, when we got to the point where we had 400-line callback hell functions, we started trying to abstract out the parts that could be separated into other functions and then just call them. In Rails this was relatively[*] safe[**] to do,

quote:

but in node we found that it was a good way to introduce more async-related bugs or accidentally start mixing up "callback style" and "promise style".

quote:

So I guess what I'm asking for is whether or not there are a collection of Good Opinions about how to write node.js out there that can help keep teams from accidentally doing something in a weird way because they found some 2 year old article from Stack Overflow saying to do it in this one esoteric way.

dbcooper posted: