Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
ExcessBLarg!
Sep 1, 2001
There's a particular fondness for it in the coding horrors thread.

Adbot
ADBOT LOVES YOU

ExcessBLarg!
Sep 1, 2001
sarehu already covered the gamut is his rebuttal, but here's more.

pigdog posted:

I don't know much of Node but the tech lead of quite a successful local startup gave a talk about why they use it,
So first off, node has only been around in a useful form (one that you would consider building an extensive platform on, if you're willing to consider that in the first place) since 2011. So I imagine that said startup is only 3-4 years old, or their core platform isn't based on node. Either way, that's not really long enough for a startup to feel the pain of maintenance burden and code bases exceeding the size and scope for which they were originally designed.

pigdog posted:

Most developers need to know Javascript anyway these days, so why not use it on server.
Front-end web developers need to know JavaScript, yes, but not general software engineers. Also front-end and back-end engineering are fundamentally different, so it's not clear that the same people should be involved in both aside from lack of resources.

Also, JavaScript is a terrible language. It's tolerated on the front-end due to necessity and the fact that there's nothing that can replace with the same degree of browser compatibility. That said, it's been around long enough in web browsers that frameworks have sprung up to make it suck less. In contrast, there's few constraints on which language/framework to use on the server, and thus, there exists a variety of mature, well-thought-out language/framework combinations. Here, node doesn't provide anything fundamentally new at all, aside from the novelty of "having the front-end and back-end in the same language!"

pigdog posted:

Very easy to create and integrate with JSON/RESTful services, because duh.
I assume "duh" is based on the fact that JavaScript interpreters "natively" interpret JSON. Except that JSON isn't a subset of JavaScript, and even when we can pretend it is, evaling JSON is a massive security hole. Thus JSON is parsed in JavaScript the same way it is in every language, by using a dedicated parser.

pigdog posted:

Compile times don't exist, so devs are more productive and deployment is easy.
There's a lot more to proper release engineering than compiling code. Usually the compilation stage is a short and uneventful anyways, and where it's not, it's for good reason (there's a bug in your program).

pigdog posted:

NPM is pretty cool.
Package management is cool. It's not cool when the npm package registry is down.

pigdog posted:

It's single-threaded but asynchronous, so you get many benefits of multithreading but without the complexity and caveats.
Except complexity like trampoline code and caveats like deadlocks and jittery response times when your blocking I/O (it's still blocking even if node pretends it's not) gets delayed for whatever reason.

So, the deal here is that mature languages support both threading and event-driven models, so you can write code using whichever approach is better suited for your purpose. Node only supports the event-driven model because V8 doesn't support multiple threads. Node hipsters spin the "async sauce" as an advantage, but honestly it's a major limitation of the platform that is, at best, a neutral point for folks who really believe that event loops are always superior to threads.

ExcessBLarg! fucked around with this message at 01:20 on Feb 19, 2015

ExcessBLarg!
Sep 1, 2001

Bruegels Fuckbooks posted:

Node.js is stupid and the community is poo poo.
That's the other problem. New node releases regularly break code, and stupid drama has already resulted in the platform being forked.

ExcessBLarg!
Sep 1, 2001

Deus Rex posted:

This issue is a doozy.

tjfontaine posted:

The way readFile works is to first to stat() the file and then read that size,
:stare:

So at first I was worried (hoping) they actually do a stat on the file, then open it. But it turns out they were doing it the (kind of) right way from the beginning. Except, if they used to have a "slow", but compatible version of readFile, why did they dump the slow path?

ExcessBLarg!
Sep 1, 2001

pepito sanchez posted:

What's so wrong with node?
It's covered in the first few posts of the thread.

In short, though, JavaScript isn't a very good language. It was an acceptable language in the mid-90s as its design goal of providing "light scripting" for largely static webpages didn't necessitate a more complex language. However, over the past decade it's been pretty clear that it's outgrown its scope as a frontend language for highly-dynamic sites, but folks still use it because it's the one language (or compile target) that all browsers support. But honestly, dragging it into the server-side where we've long had better languages of all sorts, doesn't make sense. Hence, benchmarks are a major selling point of node because, honestly, there's not many others.

It's hard to explain (beyond what we've already done) where node falls short in practice. In my opinion, its three biggest flaws are: complicated code (due to forced async with no threading and many callbacks), performance issues (where blocking I/O introduces jitter to the event loop), and a relatively immature community and collection of third party libraries. On the surface, node might look great, but anyone who uses it for large/complicated projects ends up feeling the compounded effects of those flaws.

I'm sure there's limited-scope use case for node that are just fine. Prototyping, templating, use as a test framework, simple proxies, can all be done in node quite manageably. But I'd really hesitate to use it as the basis of a large project with a 10+ year expected lifetime.

Adbot
ADBOT LOVES YOU

ExcessBLarg!
Sep 1, 2001

pepito sanchez posted:

What's the difference between using Django with a RESTful API in mind, and a fully JS app? Apart from the obvious.
Don't discount the obvious. Python is a mature server-side language with fantastic libraries and great community support. Comparing the perfect (well, bug free) Python-based implementation with the perfect node one, it's probably a wash. The problem is obtaining "bug free" with node, especially, with third party libraries. And then maintaining it.

pepito sanchez posted:

Would you recommend someone learn Spring instead for server-side code?
Java is the opposite end of the spectrum. It's quite ceremonial and, at times, heavy-weight. It's not necessarily a terrible thing with large projects (in terms of code or number of contributors), but it can still feel like being too much for a prototype where the advantages of being statically typed doesn't have as much immediate benefit. It's worth looking at though, just to see what's going on there. I'd start by looking at the JAX-RS/Jersey tutorials.

pepito sanchez posted:

I don't even care what kind of database it uses as long as it's secure.
The vast majority of web apps get by absolutely fine doing CRUD with relational databases. There's a reason the relational model has been around for so long, it works really well for data that most folks deal with. As a bonus, it helps that everyone is familiar with SQL and relational databases, and there's plenty of resources on how to manage them should your application grow large enough that you actively have to start thinking about managing a database.

NoSQL databases may have their place in providing solutions to specific problems. But I wouldn't use Mongo "by default", but only when you have data sets that really don't mesh well with the relational model.

pepito sanchez posted:

Obviously for small projects I could just use anything, but I like imagining everything might become something huge.
You're far more likely to be stuck maintaining something of moderate popularity for a long time, than you are maintaining something of immense popularity for a small amount of time. There's no perfect solution, but generally consider when building a system what technologies will enable it to be maintained at reasonable cost for a period of 5-10 years.

  • Locked thread