Using Deno in Production

[CordialGit]

I just want to ask a few questions:

1.) Deno was released in Year 2020, while Node.JS is 2009.

This is a difference of 11 Years.

So I assumed that Deno should have had 11 Years of experience from Node.JS in its release, and should have grown wiser.

My Question is this:

To enhance Node.JS HTTP functionality and Server power, We install and "require" Express to add the full fledged Server functionality.

Deno already knows this.

1.) Why didn't Deno make this Full fledged Server functionality a default in the Core HTTP Standard Library of Deno, so that we will not need Oak Server Middleware as Express is needed by Node.JS?

2.) I want to build a full Stack Social Media Application on JavaScript alone.

Is Deno fully ready for Production?

2b.) Deno Deploy is not ready for Business.

They don't have Customer Support Ticket system, and it's hard to reach them.

I'm I wrong? -- or is there a better way to reach the Deno Deploy Team?

3.) Is there a way that we can host a Deno Application on any Web host, in the same way that we can host WordPress Websites on any Shared Hosting Package of any Web Host?

[markthree]

@CordialGit Hello, you can join the Discord discussion group。Most of the time, Deno's team is involved in discussions 👉 discord.com/invite/deno

[markthree]

@CordialGit
To answer your questions

1. I think it's not necessary to add express to the standard library, because deno is increasing its support for npm, and later on, deno depoly should support npm as well, so you can easily use express in the future.

   For now, we can only use it like this 👇

   import express from "https://esm.sh/express?target=denonext";
   
   const app = express();
   
   app.get("/", (req, res) => {
     res.send("Hello from Deno Deploy!");
   });
   
   app.listen(8080);

   Of course you can also discuss it at deno_std

2. The vast majority of my compute services and static resource provisioning services in my production environment now come from deno deploy, which are super fast to cold start and then you can access it from almost anywhere in the world, and for me, sort of available in production environments. I think you can use a part-by-part constant migration over when you first use it.

3. About Service

   • Just package your deno program as a platform-specific binary and place it on a web server to run it, or install the deno runtime on your server to run it as well.
   • If you're looking for out-of-the-box use, not only deno deploy, but you can also use deno in supabase and netfiy.
   • You can even host your own deno service 👉 supabase.com/blog/edge-runtime-self-hosted-deno- functions

[CordialGit]

@markthree

I want to Thank You very much for your reply.

However, your reply confused me in some parts. So I will ask my questions in another way.

1.) I think you misunderstood me here. What I was saying is that, If I want to use Node as a Server, I need to install Express.

Consequently, if I want to use Deno as a Server, I need to install Oak Server ( https://github.com/oakserver/oak)

What I am asking is that-- why can't Deno be built in a way that it will have in-built, whatever Oak Server was bringing--- in such a way that we shouldn't need Oak at all?

2a.) I am asking if I can build a Deno Application right now, and launch it straight into production without having problems soon?

2b.) I am asking that--- Why isn't there a better Customer Service Channel, like WhatsApp, Chat or Email through which we can reach Deno Deploy?

3.) We have hosting Companies like Bluehost, SiteGround, InMotion Hosting, Scala Hosting, DomainKing, and many other hosting Companies.

Can I just host a Deno Application on any one of them, without needing specialized Set Ups?

Regards.

[markthree]

@CordialGit I'm sorry I don't know much about your response and questions, looking forward to other people's views on this issue 👀，I have nothing else to add。

[kwhinnery]

@CordialGit hey there - thanks for the questions!

1.) Why Deno doesn't provide a framework like Oak directly in the runtime: I think this is a fair question, and worth keeping in mind as the runtime evolves over time. One advantage of maintaining a lower-level HTTP server API is enabling innovation and experimentation in userland. If Deno were to provide an oak-like library for middleware, it would probably be in addition to the lower level API (increasing the API surface area), and probably have a chilling effect on any other third-party attempts to create a higher-level abstraction on top of HTTP requests. That being said, an API to create a middleware stack is a pretty fundamental component of backend servers, so maybe there's an argument to be made to add something like it to the standard library. We'll keep listening to the community for preferences here.

2a.) Can I run Deno in production? Short answer is yes. We have a number of customers (like Netlify, Supabase, and others) that are running large production workloads on Deno and Deno Deploy. Of course it's hard to give a blanket answer to whether or not Deno is appropriate for any particular use case, but you can draw some confidence from the fact that the runtime is being used in a non-trivial way by others.

2b.) Support: You are able to reach out to [email protected] with critical or private issues, but given our relatively small team size, we do need to make difficult prioritization decisions with requests that come through this channel. If at all possible, I'd encourage you to use the #help channel in our Discord community, where you can receive help from both Deno team members and our user community. In the coming weeks, we will also restart Deno community office hours in Discord, where you can come to ask questions of Deno team members in real time.

3.) Other hosts: You can definitely use other hosts to run Deno applications! In these use cases, I would do as @markthree suggested, and package your Deno server as a single executable. If you generate an executable this way for your target platform (Linux, e.g.) you should be able to run it just about anywhere, maybe using another server as a proxy.

[lino-levan]

Just wanted to note in this issue that denoland/std#1295 exists, and it's about adding middleware to std. I'm not a huge fan of attempting to standardize something that already has so much community divergence though.

Also, I feel like this would be better as a discussion than an issue.

[CordialGit]

@lino-levan
You see, JavaScript is powerful. It can do so much on the frontend. And it is a sufficient tool when now paired with Deno.

Now, I'm offended that creators of JavaScript frameworks are making JavaScript Frontend Development too difficult.

On the Frontend, I will take the pain to learn HTML, CSS and JavaScript. Then move forward to learn React and Next.JS.

If I choose the Vue route, I need to learn Vue, and Nuxt for Server Side Rendering, Pinia for Storage, Vuetify for Components, and Vitest for testing.

With so much frontend power in JavaScript already, we still learn more and more tools, in the name of wanting to simplify JavaScript on the Frontend.

THE MATTER WITH DENO
Considering the headache with Frontend, I am of the opinion that Backend should also not kill us.

All of these over-learning is making JavaScript Web Development too difficult.

And I'm hoping that Deno could just be the only thing we need to learn for Backend-- without the need for anything extra.

Yet all the full features that MiddleWare adds to the mix, will be self contained in Deno, out-of-the-box. This is the future I expect with Deno.

For the future, I am also hoping that some sensible JavaScript Developers would also come up with a Single Complete Full Featured Frontend JavaScript Framework-- which you can transition into, directly after learning Vanilla JavaScript, and it will have the capacity to handle State Management, Component creation, Testing, Styling, Server Side Rendering, Authentication, API, Validation, Deployment---and anything else that we need React and Next, or Vue, Nuxt and Pinia for.

I guess by now, you can see why my mind favours the one tool model?

[davidthor]

Just want to take a moment to say that I don't want that to be the future for Deno. I'm using Deno to build a CLI which does NOT need an http server and values keeping the compiled binary extremely small. Usage for CLI development has been the primary thing that attracted me to Deno, and I would hate to see its std library bloated when use cases like HTTP servers are easily accomplished with external libraries.

Also, coupling too much into the std library would make it harder for the Deno ecosystem to evolve when improvements happen across the landscape for things like http servers. Forcing it into the std library ALSO forces Deno to become the maintainers of an http server and increases our dependence on them while increasing their burden. I'd rather they focus on making integration of modules/packages easier than have them "own" everything we all depend on.