Hacker News Reader

> No web Gateway Interface like WSGI and Rack

It uses http, which is much more standardized, used and accepted than Rack or WSGI. I can chain together http servers, use graphql http redirectors, etc. With WSGI and Rack you’d need a fronting web server to terminate and translate.

> No DBMS API/SPI like JDBC.

Covered this in another comment.

> Express was supposed to be a Microframework like Sinatra and Flask but developers have to spend most of their time defining a robust web server.

Doesn’t this mean it is a microframework? As opposed to something like Django that has everything included?

> Since the http server and app code are tightly integrated, 12-Factor Apps or JSON API Microservices are more complicated than they need to be in Node.

If you are serving up an express app directly with no fronting load balancer then perhaps they are tightly integrated. Otherwise they are not. Express does not and should not handle load balancing.

> 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 Node.js, and I still find it's an excellent framework for lightweight web servers and b4f approaches. TypeScript and Deno, not so much.

Edit: also, while Node.js had its share of quirks in early versions (especially around the Streams 1/2/3 API), its core API is super-stable (and it better be with some 100s of thousands of packages making use of it out there).

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

> 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. ... did not outpace ... GIL ...

I honestly have no idea what you're talking about. The beauty in Node.js' http lib is that you can write middlewares against the core API and run the same code under express.js with additional middlewares for sessions, routing, etc. Python, whatever its strengths, certainly isn't used for web apps more than Node.js, let alone is dominant. Re modules and reuse, I guess if one side is complaining about too much modularity (leftpad) while the other doesn't see enough of it, Node.js got it just right ;)

Edit: CommonJs directly references JSGI [1], and if you compare it to Node.js' http core or express.js' API, you can see the correspondence quite obviously, can't you?

[1]: http://wiki.commonjs.org/wiki/JSGI

For clarification: PHP never had GIL. And it's a magnitude faster than Ruby or Python.

It's a common misconception to group PHP with Ruby and Python in terms of performance.

Even more now that PHP8 is JIT'ed. Plus async/await is coming with Fibers RFC and already present as modules.

People have been using async PHP in production for years. See Swoole.

Modern PHP frameworks (Workerman, Swoole, Comet) rank as top performers of Techempower Benchmarks. Much higher than Python / Ruby / Node.js and head-to-head with the Golang based project performance.

Disclaimer: I'm the author of the Comet:

https://github.com/gotzmann/comet

> The lack of a JDBC-like API/SPI hurts many languages included Node and Rust.

I always wondered what is a use case for Rust service that talks to a (non-local)database. First people pay borrow checker tax, get a chance to have an amazingly responsive system in return and then blow it on the round trips to a database. What am I missing?

Users who use Rust in this way report that these services tend to be extremely robust and have orders of magnitude less resource usage, which in a world of cloud computing translates directly into an improvement on the bottom line.

Why would a DBMS API need to be built into the runtime?

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.

"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 in every android phone, it wins by a mile. I'd even go as far to wager that MSSQL instances alone outnumber Mongodb or Dynamo by a good margin.

SQLite is also in every Win10 install. And in every Firefox install, IIRC?

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

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.

I'm not sure I could disagree more.

I'd phrase it more like "ORMs are as popular as they always were, most DBs today are SQL DBs, same as always, and the only recent change in the last 10 years is people have stopped speculating that NoSQL is going to replace SQL DBs, and accepted they will be, at most, specialised tools for niche uses.".

Obviously that's just my subjective opinion, but the Stack Overflow 2020 dev survey (https://insights.stackoverflow.com/survey/2020#technology-da...) has it MySQL, Postgres, MS SQL Server, SQLite, MongoDB. DB Engines (https://db-engines.com/en/ranking) has it as Oracle, MySQL, MS SQL Server, Postgres, MongoDB, and in both cases there's a STEEP falloff after the top couple entries.

I'm not sure either of those is a super reliable source, but I don't know of any better ones.