3 ms·

> 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

> 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).

sradman 6y ago
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 https://en.wikipedia.org/wiki/JSGI
- tannhaeuser 6y ago
  > 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 http://wiki.commonjs.org/wiki/JSGI

sradman 6y ago

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 https://en.wikipedia.org/wiki/JSGI

tannhaeuser 6y ago
> 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 http://wiki.commonjs.org/wiki/JSGI