deno VS ASP.NET Core

Here is the relevant Github issue with a better explanation:

https://github.com/denoland/deno/issues/16105

Deno, version 1.28 or later.

import { serve } from "https://deno.land/[email protected]/http/server.ts"; const handler = async (_request: Request): Promise => { const resp = await fetch("https://api.github.com/users/denoland", { // The init object here has an headers object containing a // header that indicates what type of response we accept. // We're not specifying the method field since by default // fetch makes a GET request. headers: { accept: "application/json", }, }); return new Response(resp.body, { status: resp.status, headers: { "content-type": "application/json", }, }); }; serve(handler);

Does this change your mind at all? https://github.com/denoland/deno/blob/be1fc754a14683bf640b7b...

It looks to me like they've documented the KV Connect protocol they invented to support this feature, in enough detail that anyone else could build an alternative backend for it.

This has helped me feel completely OK with how they're handling this. They get an advantage in that they've already built an extremely robust proprietary backend, but I find that acceptable given the documented protocol.

Yes, sort of - on Deno Deploy the authentication doesn't come from a token in env vars, but from intrinsic security tickets baked into the Deno Deploy system. Also, it's a bit faster on first connect, because compared to KV connect we can skip the metadata exchange[1] because the information it provides is already present in Deno Deploy through other means. Both the backend service and frontend API (JS->KV) is the same though :)

[1]: https://github.com/denoland/deno/blob/be1fc754a14683bf640b7b...

import { serve } from "https://deno.land/[email protected]/http/server.ts";

Deno is an alternative JavaScript runtime that was released back in 2020. I’ve been seeing more interest in it recently, and it has some compelling features:

Most platform connectors are written on Deno, that allows you to host them serverless for free!

First is the size. Writing a server-side and client-side program is possible with Rust, and the resulting WASM package will be small enough. At the same time, Microsoft Blazor converts C# code to WASM, but the client delivery has to include the reduced .NET runtime, taking several megabytes for a script. The same is true for GoLang, even with an attempt to reduce the runtime delivery in TinyGo WASM. Developers want to work with their favorite languages, whether it is Java, Kotlin, Dart, C#, F#, Swift, Ruby, Python, C, C++, GoLang, or Rust. These languages produce groups of runtimes. For example, JVM and .NET have many common parts, Ruby and Python are dynamically interpreted at runtime, and all mentioned depend on automatic garbage collection. For smaller WASM packages, browser vendors can include extended runtime implementations, for example, by delivering a general garbage collector as part of WASM. Garbage collection support by WASM is currently in progress: WASM GC, .NET WASM Notes.

hey, I am a beginner and am learning c# and asp.net MVC from Kudvenkat so any issues mean Kudvenkat`s videos are 10 years old so any problem? and if there are jobs on .NET and they want skills like c#,asp.net MVC then If I learn c# and asp.net MVC from kudvenkat then any issues?

I know that but any issues there? if jobs are available on dot net then any issues learning c# and asp.net MVC from Kudvenkat?

asp.net is a framework like a laravel for php, django for python, spring for java

.net is an old version asp.net core is new you should learn that:-in asp.net core there are MVC structures that will help you to make full-fledged web applications

You can build an app without asp.net, but you cannot build app without .net p.s. actually you can, since C# has more then one runtime - Mono, but that is old things

In javascript front end world maybe use local storage , local session,jwt token but for me , i not advise as it more secure to rely on asp.net internal session or authentication.