Things I Regret About Node.js [video]

Post by jonny_eh » Wed, Jun 06, 2018, 8:21 PM UTC

lloeki wrote: post #92

mrighele wrote: post #82

Earlier quoted context omitted.

Having the same language allows to share some code between frontend and backend. This can be used to prerender your SPA on the server, for example, or to share some logic with the client to enable offline usage.

Being able to share code is really not that great because you don't share that much code between front and back in reality. Being able to share the paradigms , structure , mindset and tooling (like linters, formatters, code generators, packagers, whatever..) is what's awesome. You remove a whole lot of context switches and cognitive dissonance, smoothing the train of thought which greatly eases the expression of idea…

Post by cpeterso » Wed, Jun 06, 2018, 8:23 PM UTC

royjacobs wrote: post #121

I think it's quite interesting to see that originally node.js was presented as a bloat-free alternative to "enterprise languages" like Java, C# or even Python or Ruby. A lot of complexity was subsequently added in an ad-hoc way which has resulted in (for example) a package management system that's wildly out of control. It's very popular of course, so I'm definitely not arguing that metric. However, the stuff that wa…

Post by maerF0x0 » Wed, Jun 06, 2018, 8:24 PM UTC

chrisco255 wrote: post #109

maerF0x0 wrote: post #104

Earlier quoted context omitted.

This fails from the false dichotomy of speed of execution vs speed of development (which includes fixing bugs). Well written languages optimize to a certain weighted preference of the two and some languages deliver more of _both_ than others. For example; Typescript is fast to write. and Golang is reasonably quick to write, _and_ execute. Both should have ~15% less bugs than javascript, potentially making them faster…

Once you've paid the upfront cost of learning Golang, I might agree with you. But then again, in particular when building a full stack app (and not when on a team that has back end and front end specialists), it's helpful to use the same context (JS/NPM) when devving. People are bad at context switching.

Post by brlewis » Wed, Jun 06, 2018, 8:25 PM UTC

mschuetz wrote: post #75

thosakwe wrote: post #21

This was one of the more interesting software talks I've listened to recently. I like that it was very real - there are serious, serious problems with Node.js, and the fact that even the creator acknowledges these problems caught my attention. I'm also a long-time user of Dart, so when he brought that up, and compared TypeScript to its shortcomings, I definitely agreed. That being said, even with the Deno project, I'…

> performance and security from running JavaScript outside of a browser. I'm just now building a node app to filter point clouds, so lots of number crunching. In two days I've got something in javascript that's faster than the C++ solution I've been working on for a week. Mostly because javascript/node makes it trivial to parallelize file IO while doing work in the main thread. This app reads 13 million points from 1…

Post by overcast » Wed, Jun 06, 2018, 8:27 PM UTC

LargeWu wrote: post #77

rb808 wrote: post #64

Earlier quoted context omitted.

> The interfaces between server- and client-side code should be well-defined and language-independent. They dont have to be and that is the point. If you write JS/TS front and back you can make everything much simpler with the associated benefits.

But in what specific way way does it make it simpler? What are the tangible benefits? I've been working in a Node/React environment for the last 2 years and there is virtually no overlap between the code we use on front- vs backend projects.