I finally escaped Node • Hacker News Board

Re: I finally escaped Node

#61

Post by vagrantJin » Wed, Mar 24, 2021, 1:28 PM UTC

int_19h wrote: post #47

tekknik wrote: post #38

Earlier quoted context omitted.

Most people have moved on from ORMs and the like, since most DBs are not SQL anymore and supporting all of the different DB types is just too hard.

"Most DBs" by what metric? If you count them as products, you're probably correct. But I seriously doubt that is true when adjusted for usage - say, number of requests per second, globally, across all deployed databases worldwide. (in fact, I suspect that SQLite would win that contest handily.)

Sqlite is really good, though often overlooked as a serious data persistence option. Especially in web developmemt.

Re: I finally escaped Node

#62

Post by estsauver » Wed, Mar 24, 2021, 1:31 PM UTC

tekknik wrote: post #38

phpnode wrote: post #33

Earlier quoted context omitted.

Because otherwise you end up with thousands of incomplete and incompatible implementations all fighting to be the best or running out of steam after a month or two. Node is a hellscape from a db perspective

Most people have moved on from ORMs and the like, since most DBs are not SQL anymore and supporting all of the different DB types is just too hard.

I think that statement should be strongly disputed. Most businesses still have a SQL database at the core of their stack. NoSQL is still definitely the exception rather than the rule.

Re: I finally escaped Node

#63

Post by brainwipe » Wed, Mar 24, 2021, 1:31 PM UTC

rockyj wrote: post #20

From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…

.NET Core can certainly run in well under 100MB, handle requests under 50ms and get running quickly under load. You also have async/await and type safety, scales horizontally. It's not JS/TS, so the skills are different and that's not idea but if you're in TS and squint, you're looking at C#.

Also far from perfect but I do think it's now a viable option as a replacement for node.

Re: I finally escaped Node

#64

Post by sradman » Wed, Mar 24, 2021, 1:32 PM UTC

tannhaeuser wrote: post #34

sradman wrote: post #9

The article focuses on server-side Node, rather than its role as a CLI tool. Compared to V8, Ruby, Python, and PHP are not performant. Node’s libuv network library was highly concurrent and Node built single-core concurrency into the runtime and libraries; multi-core concurrency, however, is not best-of-class. IMO, Ryan Dahl made two fundamental mistakes in both Node and Deno that make them uncompetitive for simple s…

> No web Gateway Interface like WSGI and Rack Node.js wasn't created in a vacuum. Its http lib, and express.js which extends it (and Sencha connect before that) implements part of the CommonJs API created by earlier SSJS frameworks such as Narwhal, Helma, etc. and was inspired by Ruby's Sinatra. In fact, a common portable API and standardized language that isn't going away anytime soon (JavaScript) is what draw me to…

It was my understanding that Node never implemented JGSI [1]. I've never compared the two APIs so you may be correct. Regardless of the path taken, the middleware should apply to a separate web server module that is functional by default. The tight coupling that emerged was too hard to master and the defaults are too attack prone to inspire quick public deploys. It resulted in copy-and-paste server-code between projects rather than reusable server modules.

This may be a property of all embedded network libraries but I think my observation still holds; server-side Node did not outpace the alternatives despite its superior performance/concurrency relative to the dominant GIL platforms.

EDIT: AWS Lambda (i.e. Function-as-a-Service) can be considered an extremely simplified service gateway interface though it is rarely thought of in those terms.

[1] https://en.wikipedia.org/wiki/JSGI

Re: I finally escaped Node

#65

Post by FlyingSnake » Wed, Mar 24, 2021, 1:32 PM UTC

haolez wrote: post #43

cygned wrote: post #19

We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's econo…

How do you feel about the impact on developer productivity after migrating to Java + Spring Boot? I haven't used Java in a long while and every time that I try to come back to it, I get driven away by the difficulty and complexity to do simple things (thinking of annotations, dependency injection, complicated design patterns). It feels like an effort of one hour of Node or Python programming (or even Go) would take 1…

> How do you feel about the impact on developer productivity after migrating to Java + Spring Boot.

I can answer that as we just strangler-pattern'd a legacy nodeJS app to Golang. Abstracting away from Node and JS paradigm is bit harder, but the blame totally lies on the callback ridden code we end up with Node. It also forced us to think about our DataStructures, abstractions and module structure. The efforts took comparatively the same time as it took the original team to write the Node app. Also I wouldn't put Golang and Python in the same league as Node.

> effort of one hour of Node or Python programming (or even Go) would take 10x more in Java

Modern Java (and Kotlin) is surprisingly powerful and the days of AbstractFactoryBeanFacadeInterface are behind it.

Re: I finally escaped Node

#66

Post by hnedeotes » Wed, Mar 24, 2021, 1:33 PM UTC

int_19h wrote: post #52

hnedeotes wrote: post #5

Earlier quoted context omitted.

> You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. I see this mentioned many times, but when I do my impression (which might be wrong) is that you haven't written Elixir or Erlang for any thing more serious than tutorials or docs examples. Besides, elixir is technically (?) strongly typed - but not statically typed. Regarding async/await, compared to the things you get i…

Green threads are great, right up until the moment you have to interoperate with something written in another language / using another VM. Then it's a mess (see also: Go). The nice thing about async/await is that, because it's all just a bunch of syntactic sugar over callbacks, any language that supports some kind of callbacks with state, can be mapped to async/await - even C! On WinRT, for example, such interop work…

I think I might be missing what you mean? You can write an async/await implementation from scratch in a few dozen lines of elixir if wanted, but you also have Tasks that provide that already written for you (with support for being included into supervision trees, etc)?

How does JS interoperate with something outside V8?

Re: I finally escaped Node

#67

Post by jkhdigital » Wed, Mar 24, 2021, 1:33 PM UTC

ducharmdev wrote: post #45

argvargc wrote: post #25

Earlier quoted context omitted.

I'm only just starting with Elixir, but my impression so far is that I will be refactoring a lot less, due to the way Elixir encourages simple and elegant approaches to many of the common problems a programmer faces. In node for example, I'm refactoring constantly (or, at least, should be...) because I keep backing myself into cognitive and developmental corners by using a kind of brick-by-brick approach that is perh…

Do you have any concrete examples you can link to show these differences? I'm unsure what you mean by architectural decisions made at the language level.

I am porting a cryptocurrency arbitrage trading platform from Node to Elixir and the difference is extremely refreshing. The actor model lends itself naturally to abstractions like producer, consumer, batcher, dispatcher, etc. which are like stations on an assembly line. “Pulling the chain” when problems occur at any point along the line is simple and clean since the actors are not tightly coupled in the first place.

I think the key “architectural decision” here is that code and execution (i.e. the process) are bundled together by design.

Re: I finally escaped Node

#68

Post by bstar77 » Wed, Mar 24, 2021, 1:36 PM UTC

cygned wrote: post #19

We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's econo…

- Lack of a good standard api: I don't understand this one. I've never had a problem with its documentation and the API always seemed fine to me, but I don't use C# or Go so maybe I'm missing out?

- There's a tendency in the ecosystem to abandon projects rather soon: This can certainly happen, but it's important to choose libraries and frameworks carefully. My node servers (Express.js) are extremely light weight, so I rarely have this problem.

- Lack of multi threading: I think you are wrong on this point but I don't know your expectations since I'm not a Java developer. I have written some multi threaded code and saw massive perf improvements. You can't expect a scripted language to perform like Java, but quality of code is also very important. I wrote a generator that replaced a Java utility that was 10x faster. I rarely have to worry about this because it's easier to write async code that's extremely fast.

- Lack of typing: this seems more like a criticism of javascript.

I get that this isn't the platformm for you, but I think you might be wanting it to be too much like what you are familiar with.

Re: I finally escaped Node

#69

Post by holografix » Wed, Mar 24, 2021, 1:36 PM UTC

Right now I’m trying to unit test an API on node that does a database query.

I’m using express, mocha, supertest and typeorm.

Mocking the database is fucking black magic. So I gave up and simply use an in memory SQLite db and add some records in the test body for my API to fetch and return so I can test.

I’d like the db to basically get nuked and recreated after every test.

So I use “afterEach” to close the connection and create a new one.

No matter what I do, when I call the api endpoint using supertest it tells me my DB connection is closed.

You’re thinking maybe the previous test didn’t reopen it or something. But there only one test.

It’s like it’s closing it _before_ the test runs. As if afterEach is not waiting on the result from supertest (yes I awaited).

I spent a _whole day_ today trying to understand just what the fuck is going on.

Gimme goroutines _any day_.

Re: I finally escaped Node

#70

Post by christiansakai » Wed, Mar 24, 2021, 1:36 PM UTC

The issues described here is so overblown and mostly non issue/nitpicking. But I'm not gonna write counter-points here, plenty of those already online. Some of the commenters here will also write it.