|
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.
|
# ? Aug 17, 2015 16:57 |
|
|
# ? May 9, 2024 23:13 |
|
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. Node is not at all good for prototyping or anything else. I don't think libuv is bad, but libv8 is .
|
# ? Aug 18, 2015 01:21 |
|
It's as good for prototyping as anything else you already "know." What will be the "best" for prototyping depends on what you're prototyping. If all you have is a hammer...
|
# ? Aug 18, 2015 03:09 |
|
Getting a bit into doing TypeScript for Angular and it's pretty useful with all the definitions already out there and made, and the new Visual Studio Code IDE. Seems VSC is pretty much made for work with node and express too from all this code completion and intellisense. I mean I don't know if this improves on Node at all, since the main complaint and downside I keep seeing is the obvious fact that it's somewhat "new" in the bad constantly changing way and probably going to be something completely different in a year, but at least it's nice to learn for front-end development, and finally have something like a type system and OOP for JS. Sadly this thread has made me lean away from leaning JS-based backend, or maybe not so sadly? Either way I've been focusing more on what Java has to offer. I would probably go back to .NET MVC, but I initially learned MVC4, then MVC5, and now it's MVC6, and from what I've seen on articles quite a bit's changed, and it's just grown a bit tiresome sticking to that. I don't know.
|
# ? Aug 18, 2015 05:14 |
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. It's probably misplaced nostalgia, but oh for the days when there were tons of dedicated desktop applications communicating over protocols other than HTTP.
|
|
# ? Aug 18, 2015 22:38 |
|
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. *cough* COM+
|
# ? Aug 20, 2015 17:09 |
|
I've been doing a lot of work with AWS Lambda lately. Node on that is an incredible fit. I would still use PHP for a normal CRUD application or something but then I'm more pragmatic than the average COBOL poster. Or maybe it is only my prototypes that always end up in production. Who knows?
|
# ? Aug 21, 2015 17:01 |
|
You could just do your prototypes with a good language
|
# ? Aug 22, 2015 00:39 |
|
more like dICK posted:You could just do your prototypes with a good language 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.
|
# ? Aug 22, 2015 03:38 |
|
pepito sanchez posted:ES6 does prototypal inheritance pretty easy and straightforward, i think. http://www.python.org
|
# ? Aug 22, 2015 19:21 |
|
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. Also, async.js solves every problem I've ever had with unruly callbacks.
|
# ? Aug 23, 2015 01:24 |
|
async.js looks really good. thanks.
|
# ? Aug 23, 2015 01:55 |
|
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. 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?
|
# ? Aug 23, 2015 02:19 |
|
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.
|
# ? Aug 23, 2015 02:33 |
|
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? I dunno, it's got its cons but it's strange that people just blankly won't admit that it's got one or two pros as well.
|
# ? Aug 23, 2015 02:54 |
|
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). I hate to sound like a dick, but based on your comments in this thread I have a hard time believing you have much more than a quite narrowly bounded understanding of web development. What "consequences" in Rails applications are you referring to? There is still a very sizeable community of rails shops that run successful businesses. Aside from an internet rumor mill that got out of control, there haven't really been any fatal downsides that would block every sane business from ever using Rails in prod. That doesn't mean that the framework solves all web dev problems; just that it's flaws are often grossly overstated without a shred of evidence to back up their claims. How much actual experience with Node in production do you have? I'm not denying that there are a ton of idiots in the world doing terrible things with Node, but we use it at work in prod, and it has proven to be far easier to develop with and maintain than our legacy js/django software.
|
# ? Aug 23, 2015 02:59 |
|
locally here in south america i can say the the biggest (and international) web-dev companies use ruby on rails, and angular, so that must be working somehow despite the critics. and they're always looking for people skilled in either newer tech. at the same time, some large companies use node and mongodb. maybe it's all like facebook and companies adapt? i don't know. in COBOL or YOSPOS you'll find people that give a bad impression about any language or framework. you just have to do your own research and make up your own mind. web development seems pretty easy to me because of the magic behind modern frameworks. .NET's MVC is pure magic, and i've worked front-end with angular. Spring so far from what i've been learning is nearly as magical as MVC with everything simply being done for you. i'm sure Django must be a similar experience. maybe even easier if not as robust. it's to come down to what gives you (me!) the least headaches in the long run. learning angular was a loving headache but i think worth it. since i've only done tiny projects with node/express i imagine it might be the same headache there. or just learn PHP and do the tried and trusted.
|
# ? Aug 23, 2015 04:02 |
|
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.
|
# ? Aug 23, 2015 04:19 |
|
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. This doesn't answer any of my questions. I didn't ask whether/or but how much prod node experience do you have? Were you involved in deciding to use the tech? Seen a wide range of applications or taken the time to become familiar with current best practices? Or are you a lost Java dev thrown into a node project because that's your job and you have to live with it? You also totally ignored the Rails comments, an omission which speaks volumes. As previously mentioned, I can't defend an entire army of idiots writing lovely libraries, 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.
|
# ? Aug 23, 2015 05:57 |
|
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. That seems like a kind of bizarre conclusion to draw, as we can easily use the same 'well they're doing it wrong' response as you're using to defend node as a technical choice. You seem to be in some confusion as to what developer I am and dismissing my views because of it so: I'm a front end developer who focusses on client side web applications backed by thin application servers. Tech I've used to write the backend include Python & Django, Scala, dabbled in Haskell, brief stopover in Ruby & Rails, and yes, Node & Express too. (Oh and Node & Sails) The majority of which were my decision to use, except for one Node app where the decision was made before I came in to work front end. In the cases where I've decided to use Node, it has specifically been for its ability to share render tech via React, and in that role it is very effective. In the instances where node is responsible for all application logic, I have found the benefits touted, like shared code between client/server, or performance, or ease of writing, to be thoroughly overrated. Couple the fact that the benefits don't deliver, with immaturity of the libraries upon which you depend, and it doesn't actually end up being a solid choice for prototyping or production. Put simply, my opinion is Node has a place in the stack, but not as all of it. This is all opinion mate, but it's the same on your side of the fence, we only have our experiences to draw from and we argue our opinions as best we can. I don't believe anything I'm saying here is particularly outlandish - as for Rails, it's been a fair while since I've done work with it (mainly during 1.8-1.9), and the ecosystem felt an absolute mess at that point, poor documentation, unwieldly Unicode behaviour, a love of monkey patching and DSLs, a heavily coupled framework that makes for great business for Rails consultants, but leaves you up poo poo creek if you don't have the resources to write your way out of it. If you're measurement for tech is that SOMEONE has made it work, every framework and language is good. Maybe things are much better in Ruby land these days, just like PHP frameworks have come a long way, but there are a lot of little things in every language that will likely never change. There is no reason why you have to accept those problems in a technology for a greenfields project, so just because someone chose one way and made it work, doesn't make it a good choice for the rest of us.
|
# ? Aug 23, 2015 07:38 |
|
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?
|
# ? Aug 25, 2015 02:03 |
|
Stoph posted:The error handling really is poo poo in Node.js. Clojure is a cool idea but debugging it was printlns and dark magic a few months ago when I was messing with it. I might try a project using scala/spring mvc just to see how that works out.
|
# ? Aug 25, 2015 02:51 |
|
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?
|
# ? Aug 27, 2015 03:08 |
|
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? 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. piratepilates fucked around with this message at 03:34 on Aug 27, 2015 |
# ? Aug 27, 2015 03:17 |
|
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. Oh, Typescript looks cool, I'll check that out more. Is it possible to have typescript and vanilla JS in the same Node app? 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, 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". 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.
|
# ? Aug 27, 2015 03:58 |
|
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? Check the API docs, just like any other library for any other plang.
|
# ? Aug 27, 2015 03:59 |
|
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:
quote:
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. Keep functions small, use promises, use Flow or TypeScript, alternatively use Babel and all the language goodies in there to help your code look better, embrace functional programming -- try to make as much as possible about inputs -> outputs with as little state as possible -- embrace closures and functions that return functions for anything that will help you do this, look at how Facebook does it (Relay, React, Immutable.js, Flux, Flow) and try to mimic them. And of course JavaScript is a very loose dynamically typed language, but that doesn't mean you can or should treat everything in a loose dynamic style. Embrace constructors to make objects as much as possible, use ES6 symbols and fake enums as much as possible for identifiers that are shared instead of using strings or magic numbers. If you're making a class then put every field that will be used in the constructor, even if you're just setting it to null (helps with performance too, since changing the underlying structure of an object tends to be expensive). Look at what a good statically typed language like C# or Rust does to ensure that you don't do something stupid, and then embrace that. Don't try to do things magically -- don't have a function that can take a string, or it can take an object, or it can take an array of objects, or whatever, if it's not a reasonable thing for the function to take care of (like maybe a single string being passed in gets turned in to an array of strings, while otherwise it will expect an array of strings) then throw an Error -- don't try to adapt the arguments to what you want it to be.
|
# ? Aug 27, 2015 04:24 |
|
I don't think I would ever actually use node for a server of any kind, but i do like node and the whole FE tooling scene...it's a mess and it has warts and the fashions change every other hour, sure, but npm/node make a lot of things real easy and nice for FE tooling for sass/react/es6 type things and handling JS libraries I think. I'm also thinking electron might be a cool thing; it seems ok-ish for atom and slack's windows (and other OSs?) desktop clients at least. I guess what I'm saying is I like node and it is cool but please keep javascript in the FE*, thanks * actually, prerendering a JS thing on a node server I can see being useful in scenarios; i haven't personally ran across them yet though.
|
# ? Aug 30, 2015 11:09 |
|
As I've said earlier I've used node like that. Actually works pretty well, our front end tooling lines up with our final 'view-layer' server, and the API for that server is just a route per template with JSON as the data. The proper server handles everything other than templating, right at the end it just calls the node server to render a JSON payload to a template and then returns the result in the response. Always gives us the option to render some views client side or server side without writing much if any new code, and we still keep a proper backend framework so all the stuff you take for granted 'just works'.
|
# ? Aug 30, 2015 12:21 |
|
I'm trying to set up vhosts so I can have local.poopybuttwhole.biz go to one nodejs app and local.bigbootybutts.biz go to a different nodejs app. The goal is for me to be able to quickly switch between the many apps I have to build with nodejs without having to stop all the various processes used by one app to free up 127.0.0.1 for use on another. The problem is I can't seem to get node to create a listen server on anything other than "127.0.0.1". Trying to get it to listen on "127.0.0.2" or a hostname that dns's to 127.0.0.2 makes it throw a hissy fit about EADDRNOTAVAIL. Is it possible to setup vhosts with node without jumping through hoops? I don't want to have to use a billion different ports because that becomes super tedious. I want to be like, here is my /etc/hosts file with a new 127.* IP, and have it magically have everything else just work with "local.example.com" filled in for the domain in my node code, nginx, etc. e: nvm, it was a mac thing or something. the various loopbacks need to be setup manually using sudo ifconfig lo0 alias 127.0.0.2 up obstipator fucked around with this message at 16:22 on Oct 9, 2015 |
# ? Oct 8, 2015 19:04 |
|
I used node.js a few months ago for a pet project to see what it was like and it seems surprisingly nice for the presentation part of the web stack. It's probably not the best for dealing with tons of data, but most other options in common use are also bad for that.
|
# ? Dec 19, 2015 13:54 |
|
Whats the vibe on the loopback stuff? The hand-holding command line stuff seems nice. The use of javascript makes me want to die a little bit every time I use it, but I'll admit loopback seems like a useful way to throw together a fast api without having to spin up and configure a django-rest-framework stack
|
# ? Jan 21, 2016 10:59 |
|
dbcooper fucked around with this message at 18:38 on Feb 28, 2016 |
# ? Feb 28, 2016 18:36 |
|
lol
|
# ? Feb 28, 2016 19:11 |
|
I have a node project that is a webserver. It uses grunt and express. I'd like to interactively debug it. I have node-inspector installed and it connects at first but it doesn't hit breakpoints on subsequent http requests. How do I get this to work??
|
# ? Jun 14, 2016 21:36 |
|
|
# ? May 9, 2024 23:13 |
|
lol at how dead this thread is. I just came across some buggy rear end behavior and wanted to ask wtf am i doing wrong this doesn't work, my strategy never gets called code:
code:
|
# ? Sep 1, 2016 02:42 |