|
neurotech posted:I'm seeing a lot of making GBS threads on node, but not much in terms of advice, suggestions or recommendations about alternatives. Django or Flask are pretty good for Python based web applications, for large large scale web applications then the various big Java frameworks (JEE, Spring, whatever weird enterprise poo poo is here), for smaller scale web applications then Dropwizard for Java, maybe Play on Scala, maybe Clojure has a nice one. One of those is probably good enough. edit: Oh right and C# with ASP.NET MVC or WebApi or whatever that's all called piratepilates fucked around with this message at 16:01 on Aug 8, 2015 |
#
¿
Aug 8, 2015 15:58
|
|
|
|
| # ¿ May 10, 2024 09:53 |
|
|
Is it just me or does Mongoose just kind of suck? Like the last time I used it the TypeScript definitions didn't even fully work, if you attach methods to the schema using schema.method('balls', function(){console.log('fart');}) then you wouldn't be able to access it from an instantiated model, the definition doesn't include the schema types to be on the model.
|
|
#
¿
Aug 9, 2015 00:35
|
|
|
Stoph posted:The biggest issue with Node APIs for me was the miserable stack traces but I'm hoping generators or async/await could fix that? It's been a while since I worked on a production Node app... There was always that package 'longjohn' for pretty printing async stack traces, Chrome does the same thing for the client facing stuff now. edit: Too lazy to check but I really doubt that async/await or generators are native in io.js right now, so the only way of doing it would be through Babel or maybe TypeScript, and that would then as far as I know involve lots of state machines that probably just lead to even more confusing stack traces, but I could be wrong about all of this. piratepilates fucked around with this message at 03:42 on Aug 9, 2015 |
|
#
¿
Aug 9, 2015 03:36
|
|
|
gbaby posted:all web dev languages suck the world is just a terrible place edit: C# is pretty alright aside from that whole Windows thing though
|
|
#
¿
Aug 14, 2015 04:54
|
|
|
let i hug posted:
They figured their way out of that mess by contiuing to use PHP, and then when massive performance problems popped up they started teams to come up with different ways of making their existing PHP codebase faster, such as HHVM (new runtime for PHP), and HipHop (a transpiler that just translates PHP to C++), and Hack (a new dialect of PHP that they've just started using instead of rewriting their codebase).
|
|
#
¿
Aug 14, 2015 21:40
|
|
|
I'm not really sure how much of a help it is to start off with something like Node.js and planning to rewrite it -- unless your long term goal is to be using some messy IBM framework that no one knows how to use then is it really that much more convenient to use Express.js for the first year instead of starting off with Dropwizard or that slim version of Spring?
|
|
#
¿
Aug 14, 2015 22:30
|
|
|
I'll tell you what though -- TypeScript is quite nice, if you're gonna use JavaScript extensively then you should probably be using it.
|
|
#
¿
Aug 15, 2015 17:58
|
|
|
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
|
|
|
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
|
|
|
|
| # ¿ May 10, 2024 09:53 |
|
|
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
|
|