Things I Regret About Node.js [video] • Hacker News Board

Re: Things I Regret About Node.js [video]

#181

Post by LargeWu » Wed, Jun 06, 2018, 9:28 PM UTC

overcast wrote: post #159

LargeWu wrote: post #150

Earlier quoted context omitted.

But I know lots of languages, and just because I'm using JS on the frontend doesn't mean that's the best backend choice. Whether I'm using React or Angular or Ember or Vue or jquery or vanilla JS on the frontend doesn't have any impact on the code I'm writing on the backend. Because one is concerned primarily with handling UI, and one is primarily for data access. There's just naturally not a lot of overlap between t…

That's awesome you know lots of languages, well done. It's not necessarily about what's the best backend choice, it's about getting shit done as efficiently as possible. For the vast majority of projects, you're never going to reach any type of limitation in Node performance, that you may or may not be suggesting. I'm not sure why you're so hung up on the front impacting the back, it impacts MY workflow. I don't have…

I'm not talking about overlap in simple language features, I'm talking about actual code reuse. It's often touted as the reason to use JS on front and backend, but it's a pipe dream. It almost never works in practice.

If I'm trying to get things done as efficiently as possible, I'm not using Node because the ecosystem is pretty terrible compared to other languages like Ruby and Python. Sure there are lots of libraries available in npm, but I've found that a lot of them are janky or hard to use, missing features, poorly documented, incompatible with each other, etc.

Re: Things I Regret About Node.js [video]

#182

Post by Scarbutt » Wed, Jun 06, 2018, 9:30 PM UTC

repsilat wrote: post #142

lloeki wrote: post #92

Earlier quoted context omitted.

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…

Depends a great deal on what the application is, I think. If you're doing heavy lifting (or anything a bit complicated) in the client and then need to make similar functionality available to APIs offline it's a godsend. My current hobby project is a kind of REPL/programming language that does all of its compute in the client, and being able to hit a button and export a "serverless" microservice is lovely side-effect…

fiasco? isn't '.mjs' still the path forward for them?

Re: Things I Regret About Node.js [video]

#183

Post by __s » Wed, Jun 06, 2018, 9:34 PM UTC

sametmax wrote: post #24

mromanuk wrote: post #4

I was thinking, watching the video "Ryan should fork it, or start over"... until he revealed it: https://github.com/ry/deno :)

My head can't wrap itself around: import { test } from " https://unpkg.com/deno_testing@0.0.5/testing.ts" There is so many issues with that I don't even no where to begin.

What if it said import { test } from "https://npmjs.com/deno_testing@0.0.5/testing.ts" ?

Re: Things I Regret About Node.js [video]

#184

Post by royjacobs » Wed, Jun 06, 2018, 9:37 PM UTC

Arnavion wrote: post #178

royjacobs wrote: post #173

Earlier quoted context omitted.

It's interesting that you mention gulp and webpack when those tools too are now considered too complex and set to be usurped by something like Brunch. It's a shame these tools keep being rewritten because there are definitely good ideas in all of them, but for some reason they can't seem to be unified.

All these tools start off as simple alternatives to the existing bloated tools. Then as they gain more and more features to support real-world situations they end up becoming as bloated as the tools they set out to replace.

Right. I'd just hope that at some point that cycle ends and people try to fix existing tools instead of replacing everything wholesale with something new that will eventually fail again.

Re: Things I Regret About Node.js [video]

#185

Post by tlrobinson » Wed, Jun 06, 2018, 9:42 PM UTC

jonny_eh wrote: post #164

tlrobinson wrote: post #140

Earlier quoted context omitted.

Node 10 has fs, at least: require("fs").promises.readdir(".").then(console.log)

Why not just: require("fs").readdir(".").then(console.log)

That's the legacy callback version.

In practice you'd probably do:

    const fs = require("fs").promises;

    // ...

    fs.readdir(".").then(console.log);

Re: Things I Regret About Node.js [video]

#186

Post by salehenrahman » Wed, Jun 06, 2018, 9:44 PM UTC

jonny_eh wrote: post #164

tlrobinson wrote: post #140

Earlier quoted context omitted.

Node 10 has fs, at least: require("fs").promises.readdir(".").then(console.log)

Why not just: require("fs").readdir(".").then(console.log)

It can potentially break things.

There are legacy code that assume that calling `readdir` will yield undefined, and will have just passed that result to a function, that alters its behaviour based on whether a parameter is undefined.

Re: Things I Regret About Node.js [video]

#187

Post by pknopf » Wed, Jun 06, 2018, 9:44 PM UTC

jonny_eh wrote: post #128

iamleppert wrote: post #78

He talks about not to add in features you think would be “cute” because they are always a mistake.. Then a few minutes later says “I thought being able to specify URLs in import statements would be cute..” Uhh...Houston, we have a problem with this one.

I dunno, importing from a url seems really smart and practical to me. It divorces the run-time (Deno) from a package manager (like npm). I wonder how it handles dependencies though.

It sounded as if he just wants everyone to use Parcel. Even then, you would use npm/yarn to get your dependencies before bundling.

It sounds like he doesn't want me runtime to handle dependencies at all.

You can always reference urls with version numbers present in them.

Re: Things I Regret About Node.js [video]

#188

Post by pknopf » Wed, Jun 06, 2018, 9:45 PM UTC

jonny_eh wrote: post #165

ricardobeat wrote: post #146

Earlier quoted context omitted.

Going from what he said about packaging, every program/module is compiled into a single file, including dependencies.

Wouldn't that lead to even more bloat than what he regretted in the talk?

Runtime dependencies is what he is trying to get ready of.

You will always have built time dependencies with npm/yarn.

Re: Things I Regret About Node.js [video]

#189

Post by Scarbutt » Wed, Jun 06, 2018, 9:47 PM UTC

LargeWu wrote: post #181

overcast wrote: post #159

Earlier quoted context omitted.

That's awesome you know lots of languages, well done. It's not necessarily about what's the best backend choice, it's about getting shit done as efficiently as possible. For the vast majority of projects, you're never going to reach any type of limitation in Node performance, that you may or may not be suggesting. I'm not sure why you're so hung up on the front impacting the back, it impacts MY workflow. I don't have…

I'm not talking about overlap in simple language features, I'm talking about actual code reuse. It's often touted as the reason to use JS on front and backend, but it's a pipe dream. It almost never works in practice. If I'm trying to get things done as efficiently as possible, I'm not using Node because the ecosystem is pretty terrible compared to other languages like Ruby and Python. Sure there are lots of librarie…

Meh, forget about code reuse, its about using only one language for a full stack web app and knowing it well.

I really don't see how python or ruby is any better than nodejs (its more a matter of taste and familiarity and you don't sound that familiar with nodejs/js in general), if anything, nodejs because of v8 is light years ahead of the ruby and python official implementations, and all three communities have lots of bad and good libraries.

Re: Things I Regret About Node.js [video]

#190

Post by pan69 » Wed, Jun 06, 2018, 9:49 PM UTC

I've said it before and I say it again; NodeJS is an infrastructure component, not a general purpose application runtime environment.

I totally recognise the IO problem in our connected world and NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS. In essence (and in my humble opinion) NodeJS is basically a programmable socket server and it's main feature is "websockets".

Writing software applications in NodeJS is the most awkward experience due to it's async nature. Business logic is inherently sync, not async. Most of NodeJS's existence has been trying to find an elegant solution to make this async behaviour look like it's sync, from callbacks, to promises and now actual language features added to JavaScript itself (async/await).

The problem with Javascript on the server is not Javascript, but the runtime in which it's executed.

I think it would be interesting to have an sync version of NodeJS that acts more like traditional Ruby and Python next to the async variant that we currently have. Both types could then be used along side each other, each solving the problem for which it is best suited.