Super interesting the part about converting to SSR and React synchronicity. Thank you!
Hard-won lessons: Five years with Node.js
41–50 of 365 posts
Re: Hard-won lessons: Five years with Node.js
#42I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?
I'm the biggest JS-on-the-server sceptic of them all, given my past experiences. But this was pre-typescript.
If a TypeScript ORM with automatic schema migrations and decent expressiveness comes around, I'd be willing to give NodeJS another shot.
But so far, nothing comes even close to the productivity of Django + ORM + Django Rest Framework. For your typical CRUD app, this will walk circles around any current JS solution. Even if the lack of static typing eventually becomes a bit of a pain.
Re: Hard-won lessons: Five years with Node.js
#43I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?
I've got over a decade of professional experience in C#, Python, and Java. I'd consider myself a Java developer before all else, yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Here's the major caveat, out of, say 100+ PoC/prototype projects I've ever done, I've taken two to 'production'. I put production in quotes because they were actually internal ser…
Can you elaborate on the "major pain in the butt to monitor and keep Node.js running production-like" What sorts of issues did you face? Certainly .NET and Java have more tooling, but I haven't noticed a difference between keeping a Node process up as opposed to a Python one. Hard to compare to stateless PHP.
Re: Hard-won lessons: Five years with Node.js
#44Reading up on all these Node.JS posts I'm surprised at just how many gotchas the platform has and how there's no single standardized way to solve them. It's not encouraging stuff. On paper the platform looks decent but aside from a few use cases it seems that there's more hype than it merits.
[deleted]
Re: Hard-won lessons: Five years with Node.js
#45I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?
I've been using NodeJs for about 4 years now. It really lends itself to the microservice paradigm. It makes great networking glue as you can handle many simultaneous connections without using many resources and since most web server operations are just fetching/updating data between databases or other services this works out well in NodeJs. The trick is to use it for this purpose only. Long running computations should be offloaded to the database or workers running in another process or machine.
A lot of the problems mentioned in that article are the author misunderstanding libraries and not actual issues with NodeJs itself. For instance the problem with the Postgres library was that he didn't read the docs. The lib uses a session pool by default. You have to release the session when your done or else it will not become available again until the default session timeout is passed, which is quite large in Postgres. In respect to using Coffeescript "Classes", forcing JS to work like other languages will create unexpected behavior. It uses prototypical inheritance, not class inheritance.
Re: Hard-won lessons: Five years with Node.js
#46I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?
I've never run a javascript server in production, but if I do the main reason would be to take advantage of the huge ecosystem. Since js works on both the client and server side, you end up with a lot more programmers hacking on it.
If you check http://www.modulecounts.com/ you can see that npm has as many modules as all the other package repos combined. And it only seems to be gaining momentum. (screenshot: http://imgur.com/a/adqNJ)
Meteor has more stars on GitHub than any other web framework: https://github.com/search?p=3&q=stars%3A%3E1&s=stars&type=Re... Nodejs, socket.io, and express all appear on the first few pages.
Re: Hard-won lessons: Five years with Node.js
#47spent 2+ years learning js/nodejs etc I finally turned to PHP for server side, it just seems easier for me to get the job done with php, or it's just me.
Re: Hard-won lessons: Five years with Node.js
#48I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?
V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. (Pypy is a good match for it but it's not main street and you can't just use any module.) in terms of performance and popularity, v8/node stand pretty much alone as far as dynamic non-compiled environments.
JavaScript has a lighter weight feel than Java and the jvm stack. Single threaded with a top notch event reactor. You can write just a few lines in node and have a web server serving some json.
There are a ton of JavaScript coders. There is something to be said for having a common technology throughout your stack and you ui is almost certainly in js.
It's easy to get something simple going quickly, there are tons of libraries and you're going to need to write go, Java or .net to out perform it.
The big downsides, imho, v8 is designed for client side stuff. Both it and dart vm are limited to relatively small memory footprints (think 1GB) which just isn't good for some workloads and problems. Likewise a lot of server tasks can make good use of real threads, you're out of luck with node, you can have child processes and send messages but if they have to share big amounts of data the marshaling becomes a bit of a bottleneck. If you work is database crud, or light weight, or horizontally scalable, or able to be modeled as streams then node isn't that bad. Js feels kind of limited in how certain things are modeled, there isn't much data hiding or abstraction; the extreme simplicity almost creates more complexity for some things. There are lots of different opinions on basic code behavior, some node modules do work on import, some need explicit initialization, some alter prototypes and it's a concept that seems to be lost on many js devs; I've burnt hours debugging something because someone reordered the imports and it screwed init logic. And you'll completely screw yourself if you don't stay up to date with your depends, things change fast and sometimes they change a lot. Both node and dart vm seem really well equipped for tooling type things that are usually done in bash, Python or perl but that doesn't seem to be as popular.
It's definitely not for everything but it's worth a look. It is really popular.
Re: Hard-won lessons: Five years with Node.js
#49Earlier quoted context omitted.
That's not Node.js. That's Express or a similar abstraction. You can execute everything inside a promise like with Koa, which amounts to something like: http.createServer((req, res) => { handle(req) .then((response) => res.send(response)) .catch(() => res.send(500)) }) Where `handle` is an async function and thus all your application logic is in async/await space.
It's Node.js - the root of the problem is also Node's strength, which is that there's effectively no stack. You can manage zillions of concurrent connections, but there's no easy way for the system to unwind bad behavior by one of those connections. In a Java app you except all the way to the request response. In a Go app you return all the way to the request response. In a Node app, you have to call your way back to…
Domains were Node's answer to that, and it seemed to work pretty well. I adopted the approach for my own web framework (not JS based) and it has been an extremely useful abstraction.
They're soft-deprecated in Node now though, and AFAICT work on a replacement has stalled.
Re: Hard-won lessons: Five years with Node.js
#50Earlier quoted context omitted.
So I'm curious as to the reasons people chose Node.js Javascript of course ;) You can leverage the same language for server side stuff and browser programming.
But how valuable is that? I hear this a lot but is it really that much of an inconvenience to write backend code in a different language? Especially if there are different engineers working on the frontend and backend.
It's very valuable if you are bouncing back and forth between frontend and backend. There's no context switching as you do that. The cognitive overhead of context switching is higher than people generally accept. This is why stacks like the MEAN/MERN stack get used in hackathons. You've got a JSON-inspired database (Mongo) with a minimal server-side framework (Express) feeding a React/Angular front-end. You can use the same libraries client/server side like Mocha for unit testing, Lodash for collection manipulations, you can even share the same validation files for server & client.