Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

Post reply on HN
Print view View original

161–170 of 502 posts

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

#161

Post by chrisco255 »

notdonspaulding wrote: post #155
chrisco255 wrote: post #109

Earlier quoted context omitted.

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.

I've heard this argument several times now and it finally hit me what I dislike about it. If you aren't context switching between your backend code and your frontend code (even when both are JS), you're probably incurring technical debt in your architecture to be paid in even greater numbers of dev hours down the road. When you are writing an all-JS full-stack app, do you really feel like you're only working on a sin…

It's not even likely they're in the same repo when working with Node (although possible). The context switch between apps is one cost you have to pay (surely your backend will differ from frontend in architecture). However, the costs of switching languages is higher. Golang / JS conventions are very different. It is possible to share some common libs front end / back end (lodash, validation logic, etc) and that helps too.

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

#162

Post by weberc2 »

cpeterso wrote: post #133
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…

That's a good example of the Innovator's Dilemma: the enterprise incumbent is unseated by some "crappy" lightweight solution that is easier to get up to speed and solves enough of the problem. The complexity, accidental and essential, comes later.

Nevertheless, people who need a lightweight language are always able to find one because there is always a new language at that point in its lifecycle. Further, there are languages like Go which seem to be determined to remain easy to get up and running, and don't seem likely to change anytime soon (for better or worse).

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

#163

Post by ramses0 »

munificent wrote: post #85
pvsukale3 wrote: post #60

Can anyone explain why he called Dart a complete failure? https://youtu.be/M3BM9TB-8yA?t=19m55s ps: I am a junior developer. I am taking up Dart to learn Mobile apps development using Flutter.

I'm on the Dart team (but I don't speak for the entire team here). Dart had two initial goals: 1. Get a native Dart VM into Chrome and eventually other browsers. 2. Get a significant number of client-side web developers that were using JavaScript to move to Dart. It's probably not obvious, but these goals are in tension with each other. In order to motivate adding a giant new VM to a browser, you need to make the lan…

Please reconcile Dart with Haxe. Why should both exist?

https://haxe.org

My previous question in 2016 was "Reconcile Dart and Go", the best answer I got was: """This isn't true; they're both general purpose programming languages with strong static type systems and decent async I/O stories. You can write a web app or a server in either language, though Dart has a better ecosystem for frontend development, and Go has a better ecosystem for backend development.""" https://news.ycombinator.com/item?id=12131397

It would be great if you could give a new comparison (post-Dart-pivot) as to how you differentiate between Dart and Haxe when both (apparently) have similar goals.

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

#164

Post by jonny_eh »

tlrobinson wrote: post #140
jonny_eh wrote: post #130

Earlier quoted context omitted.

I find it really bizarre that Node still doesn't have full promisified built-in libraries. It's not like it'd break existing APIs.

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

Why not just:

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

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

#165

Post by jonny_eh »

ricardobeat wrote: post #146
jonny_eh wrote: post #129

Earlier quoted context omitted.

Dependencies, especially for dynamic imports?

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?

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

#166

Post by weberc2 »

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.

Right, but the cost of learning Go is ~1 afternoon :p Anyway, I don't really buy the argument that there are efficiencies from using the same language on the backend and frontend. I think there are efficiencies from using a language you're more familiar with or languages that are less error prone or more ergonomic or which have better tooling/ecosystem/etc, but I've never had a problem I would chalk up to context switching.

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

#167

Post by mschuetz »

ex3ndr wrote: post #158
mschuetz wrote: post #75

Earlier quoted context omitted.

> 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…

Can you share some sources? I tried to process simple CSV files in a very straight forward (but async) way and got reading 200mb CSV and just splitting it to columns (with simple split by comma) takes ~10 seconds. Also simplest HTTP request in express is handled in several ms and that's A LOT in my opinion.

I don't really have any explanatory sources at hand, just the source code here: https://github.com/potree/PotreeServer/blob/redo/src/Regions...

Points of interest:

Schedule files to be loaded. This will usually load around 1000 files: https://github.com/potree/PotreeServer/blob/redo/src/Regions...

Whenever a file is loaded, iterate through the points in it, do the filtering and write the results to the output file: https://github.com/potree/PotreeServer/blob/redo/src/Regions...

Wait until all files were loaded and processed: https://github.com/potree/PotreeServer/blob/redo/src/Regions...

Wait until the output was written to disk: https://github.com/potree/PotreeServer/blob/redo/src/Regions...

What happens is that ~1000 files will be loaded in the background, points are filtered in the main thread and even while some files are still being loaded, we already start writing the results to the output file.

> I tried to process simple CSV files in a very straight forward (but async) way and got reading 200mb CSV and just splitting it to columns (with simple split by comma) takes ~10 seconds.

CSV may be much bigger challenge since it's ASCII data. That always tends to take multiple times longer.

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

#168

Post by staticassertion »

dnomad wrote: post #157
minitech wrote: post #149

Earlier quoted context omitted.

> Very simple mistakes like immutable, never changing build releases Can you expand a bit more? Not sure what this means.

[1] https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakag... , [2] https://www.csoonline.com/article/3214624/security/malicious... , [3] https://news.ycombinator.com/item?id=16087024 And the list goes on and on IMO. What's disappointing is that these were lessons learned a long time ago and now they're being re-learned.

This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc.

But anyways, [2] is at least a problem in many other package repositories. [1] would probably be a problem for many - given legal pressure (vendor your shit, that's the solution). [3] was a bug, not a design issue - no package management system is immune to bugs.

The one thing Java has is that it uses namespaces, which may help with [2] (but barely). [2] certainly has been a problem in PyPI.

Certainly all of this could happen to PyPI. We see it happen with js more, I think, because js happens to be extremely popular so there's a ton of packages for it and it's also much younger (especially node) than others.

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

#169

Post by bartread »

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…

I think the problem with "bloat-free" is it's a fine ideal until you try to solve any kind of reasonably complex problem, and honestly it starts to creep in even when you're solving something that isn't particularly complex.

Here's a concrete example. Your classic node.js or express.js sample app is something fairly simple like a hello world, or an IM server. A more complex sample probably looks something like that venerable nodecellar app from a few years back. In all cases the spiel is, "Hey, look how easy it is to create a web server with node."

Except that I'm looking at my node server source right now - for an honestly fairly simple app containing a handful of pages and a blog - and here's what I have:

- Routing (obviously)

- Cookie and body parsing

- Session management

- MongoDB integration

- Passport.js for authentication with a couple of providers (FB and Twitter)

- File system access

- HTTPS and SPDY/HTTP2 support

- Compression support

- Logging with winston and morgan, including loggly integration

- Referer spam filtering

- Pug templates

- Hexo blog integration

- Path resolution support

- Request validation and redirects

- Static content support

- Stripping headers such as X-Powered-By, and adding other headers such as the all-important X-Clacks-Overhead

- Error handling

There's probably a couple of other items I missed, but you get the idea. It seems like a lot but, as far as I'm concerned, this is express.js app MVP for anything you might want to put into production.

I haven't even mentioned the gulpfile I use to build all this, which targets desktop, mobile, along with embedded versions for a particular mobile app due to launch in the near future, and has become something of a behemoth[1]. Nor have I mentioned that I have Cloudflare to sit in front of this, primarily to deal with the heavy lifting of some of the media files I serve up.

On the face of it, this might feel like "bloat" but it's all necessary to run the application and, like I say, a lot of it is the bare minimum for an MVP web app in node.

[1] Yes, I know I could/should switch to webpack, but gulp works, and switching to webpack "just because" doesn't justify itself with the value it might add.

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

#170

Post by royjacobs »

cpeterso wrote: post #133
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…

That's a good example of the Innovator's Dilemma: the enterprise incumbent is unseated by some "crappy" lightweight solution that is easier to get up to speed and solves enough of the problem. The complexity, accidental and essential, comes later.

Yes, this is exactly what's happening. Existing tools are seen as too complex because people don't seem to be realizing that the complexity is not accidental, but necessary.

I'm not trying to say that Java has no accidental complexity of course, I don't want to open that can of worms :)

Post reply on HN