71–80 of 101 posts
Earlier quoted context omitted.
[dead]
I’m working on a moderately large-scale Nest.js project and deeply dig it, but I don't really see a lot of people talking about it, which gives me concern. Glad to hear you say that, though, maybe I’m just out of the loop.
What is the standard web application backend framework for Node.js these days, is it Koa? As I understand it express is quite dated because of the callback structure. I have been confused recently with the moving best practices. What is the server architecture Next.js is most often plugged into?
[dead]
Earlier quoted context omitted.
[dead]
I can't tell how this has actually improved upon existing options like Koa. This reeks of object oriented programming just for the sake of object oriented programming.
It's nice to have consistency between backend and frontend, but it is indeed a bit heavy and really not necessary most of the time.
Earlier quoted context omitted.
I sure hope not. NodeJS is a FOSS project under the Linux foundation (via OpenJS) and is not driven by profit, while Deno is developed by a for-profit company (Deno Land Inc) which has bunch of closed sourced projects to fund the company. Hopefully, NodeJS learned from the whole Npm Inc history and tries to remain more independent from for-profit companies. The whole io.js thing was a very different thing than Deno.…
While I wasn't aware that Deno was owned by a for-profit company, Deno itself is MIT licenced. Is there any particular reason why everything you just said cannot also be true for Deno?
> NodeJS is a FOSS project under the Linux foundation
Deno is not maintained by a non-profit organization, and Deno Land Inc are unlikely to want to let someone else control their project, that'd be kind of suicidal.
> is not driven by profit
The organization who maintain Deno is explicitly for-profit, meaning it has to be driven by profit. If they give the project to the Linux Foundation, I guess that could change, but again, unlikely they'd do something like that.
> NodeJS learned from the whole Npm Inc history and tries to remain more independent from for-profit companies
Deno arguably did learn from that story and did package management differently. They didn't avoid the whole for-profit angle, as again, the maintainers are working for a incorporation.
> Contributors tired of slow pace of NodeJS
As far as I can tell as an outsider, Deno seems to be moving forward at a decent speed and I haven't seen any noise in their community about a possible fork because of slow development pace.
Earlier quoted context omitted.
Who cares how old something is, if it works well, why not use it? You can easily avoid callback-hell by making the callback you pass in to expressjs async and use await inside of it, without much drawbacks. Just because the first closure into express is a callback doesn't mean you need to use callbacks everywhere, just use await/generators/whatever you want in your application code. expressjs at this point is battle-…
> It's very mature and does what it does well. Is it? It performs slower than e.g. Fastify. Don't see how that's doing well. > Who cares how old something is, if it works well, why not use it? It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard?
It's such a marginal difference when you consider real-life applications built with either express or Fastify though. Seldom is the actual bottleneck which HTTP library you use (unless you're at a really, really, really big scale), and more about how you structure your code, database and general architecture. I can count on one hand the number of times I've had to care deeply about the HTTP stack in order to optimize something, while I've probably had to optimize 100s of web products over the years, all done without touching the HTTP parts at all.
> It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard?
How to handle HTTP requests kind of doesn't. HTTP 1.1 continues to work, and will continue to be sufficient for at least 90% of all the use cases on the web for a long time.
I know that the JS community generally suffers from "If it hasn't been updated in the last year, it's probably broken and not modern enough" syndrome, but some software actually end up being "finished" and good enough for the task at hand. What improvements could you actually add to express without breaking the API interface that millions of applications depend on? Sometimes stability is wanted and needed, and that's how you get mature software. Who wants to rewrite their application and architecture every time some library you happen to use decides to "improve" it?
Earlier quoted context omitted.
> It's very mature and does what it does well. Is it? It performs slower than e.g. Fastify. Don't see how that's doing well. > Who cares how old something is, if it works well, why not use it? It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard?
> Is it? It performs slower than e.g. Fastify. Don't see how that's doing well. It's such a marginal difference when you consider real-life applications built with either express or Fastify though. Seldom is the actual bottleneck which HTTP library you use (unless you're at a really, really, really big scale), and more about how you structure your code, database and general architecture. I can count on one hand the n…
If you take out your 386 and boot up Dos 3.1 it'll; continue to work too. Let's just not improve, right?
> but some software actually end up being "finished" and good enough for the task at hand
Like dead? Do you ever stop learning and growing? Are you "finished" too? There are new vulnerabilities, new compatibilities, existing bugs, different use cases, etc - you think it's finished = turning a blind eye.
> It's such a marginal difference when you consider real-life applications built with either express or Fastify though.
That's how we get Electron and everything become a resource hog. Oh it doesn't matter. Oh marginal difference. No don't recycle, don't do good for the environment and anything in life because it's all marginal. Why even reply? It's a marginal difference.
No, we can do better and will.
What is the standard web application backend framework for Node.js these days, is it Koa? As I understand it express is quite dated because of the callback structure. I have been confused recently with the moving best practices. What is the server architecture Next.js is most often plugged into?
Earlier quoted context omitted.
The big new feature is a sandboxing with explicit CLI flag opt in to permissions, exactly like deno pioneered. Except there's zero mention of deno as a clear inspiration of the feature.
I don't understand that description, but I'll take your word for it.
Earlier quoted context omitted.
[dead]
I can't tell how this has actually improved upon existing options like Koa. This reeks of object oriented programming just for the sake of object oriented programming.
What is the standard web application backend framework for Node.js these days, is it Koa? As I understand it express is quite dated because of the callback structure. I have been confused recently with the moving best practices. What is the server architecture Next.js is most often plugged into?
Koa is relatively outdated at this point. Fastify is generally what I and most people I know look towards when starting something "new". Express is still in a lot of things, though.
Architect serverless (https://arc.codes) is pretty good for serverless.