Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Web: Deno

byteofdev.com

Post reply on HN
Print view View original

81–90 of 116 posts

Re: State of the Web: Deno

#81

Post by synergy20 »

_jplc wrote: post #55

Think of it as Node.js + Typescript, but you don't have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary. Don't think about syncing that formatting/linting/import aliases configuration with VSCode, all you need is the Deno plugin and you'll get all the benefits of working with TS on VSCode. Packages are obtained (and heavily cached) from any URL in…

nice to have ts+linter+formatter together, it took me one or two hours to set up with my own vim(using vite/volar), so it saves me some time.

what I really like a new Node.js(e.g. deno) is actually its module system, I don't like the `npm i` in node.js pulls hundreds of modules, a standard library that contains most commonly needed modules is the key. If deno does not do that, I probably will never try that(as I can have the bundle of tooling done myself in one-or-two hours, vite/volar now makes this even simpler).

In short, I will prefer gold-quality set of modules or APIs(e.g. glibc) to the 100% flexibility "you pull whatever you want freely now even over http URL", for security and stability reasons.

Re: State of the Web: Deno

#82

Post by pjmlp »

tomxor wrote: post #79
pjmlp wrote: post #9

Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.

NodeJS's ecosystem looks like more of a liability and less of an asset to me each passing day. This perspective is making Deno feel easy for me to jump to for my next backend project, now that I'm actively fighting against dependencies.

On my own private projects, I just do classical SSR inclusion of JavaScript libraries in Java and .NET frameworks and SCRIPT tags.

I don't even care nodejs exists.

Re: State of the Web: Deno

#83

Post by evv555 »

redisman wrote: post #31
forty wrote: post #24

Earlier quoted context omitted.

My understanding is that one of the goal of deno is to be more compatible with the Web. As a backend only dev I don't find that great, I rather have clearer separation between quality backend modules and shitty 100-dependencies web modules ;) Also I don't want smaller modules. I want bigger and better maintained modules with few dependencies. Small modules is what makes npm ecosystem not that great.

Thing is - unless you really love JS for some weird reason, then deno is competing with established languages like “go” that have a great web server in the standard library. In addition to competing with node which is fine! Apart from it’s insane package management situation. Which most people just kind of shrug at

JS is already a popular language for "DevOps" cloud scripting. Deno would be a better fit for these kinds of use cases for the same reason Go is a good fit and there's already market share.

Re: State of the Web: Deno

#84

Post by pier25 »

jcelerier wrote: post #40
wruza wrote: post #38

I'd like to use some modern common ground for js/ts development, but the entire toolchain is not ready for this, somehow turning it into chicken/egg problem. Typescript, webpack, babel contribute to that. For last 10 days I tried to pull my generic project as much to the top as I could^, but modules are still commonjs, because to use imports I have to "type":"module" in package.json, which makes webpack.server.config…

Reading that makes me so happy to just have to open QtCreator, hit "new project" and get rolling

I still miss being able to do that with Flash.

Re: State of the Web: Deno

#85

Post by _jplc »

andrew_ wrote: post #75
_jplc wrote: post #55

Think of it as Node.js + Typescript, but you don't have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary. Don't think about syncing that formatting/linting/import aliases configuration with VSCode, all you need is the Deno plugin and you'll get all the benefits of working with TS on VSCode. Packages are obtained (and heavily cached) from any URL in…

That built in linter leaves a lot to be desired. If you're a big big fan of being told how your code should be formatted, then it's a good fit. however, if you're the slightest bit opinionated, you still have to implement ESLint and jump through those hoops.

Right. Personally, I don't think any opinion is more correct than any other in regards to code formatting, so, consistently and collectively choosing one and going forward with it is the way.

Re: State of the Web: Deno

#86

Post by _jplc »

synergy20 wrote: post #81
_jplc wrote: post #55

Think of it as Node.js + Typescript, but you don't have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary. Don't think about syncing that formatting/linting/import aliases configuration with VSCode, all you need is the Deno plugin and you'll get all the benefits of working with TS on VSCode. Packages are obtained (and heavily cached) from any URL in…

nice to have ts+linter+formatter together, it took me one or two hours to set up with my own vim(using vite/volar), so it saves me some time. what I really like a new Node.js(e.g. deno) is actually its module system, I don't like the `npm i` in node.js pulls hundreds of modules, a standard library that contains most commonly needed modules is the key. If deno does not do that, I probably will never try that(as I can…

In Deno's case, there are two things:

Deno API, which comes bundled with Deno and is present globally, always, without importing: https://doc.deno.land/deno/stable. Includes basic stuff like stdin, stdout, stderr, file management... etc and standard Web APIs like Fetch API, web assembly interoperability, localStorage, FormData, TextEncoder/TextDecoder, etc.

Deno std lib, an official library that presents what you could expect from a standard library, based on Deno API: https://deno.land/std@0.120.0, but you need to import it, because it's no different than any other module in the wild. Mime types, more encoding options, extended file system management, etc.

Re: State of the Web: Deno

#87

Post by andrewmcwatters »

Now instead of npm packages abusing SemVer unless you use non-default --save-exact behavior as an attack vector, we can import modules from URLs without subresource integrity unless you use non-default lock file behavior! Great! We learned nothing!

Re: State of the Web: Deno

#88

Post by tmikaeld »

Griffinsauce wrote: post #17
tmikaeld wrote: post #10

Earlier quoted context omitted.

I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.

> smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. This isn't necessarily enforced by Deno itself right? That seems like more of a side-effect from the self-selection of its users. Once the ecosystem grows and the all the "normies" come in, this doesn't seem guaranteed at all.

Right, like I wrote, it's up to each developer, but i really do hope the trend continues.

Re: State of the Web: Deno

#89

Post by ihnorton »

_jplc wrote: post #86
synergy20 wrote: post #81

Earlier quoted context omitted.

nice to have ts+linter+formatter together, it took me one or two hours to set up with my own vim(using vite/volar), so it saves me some time. what I really like a new Node.js(e.g. deno) is actually its module system, I don't like the `npm i` in node.js pulls hundreds of modules, a standard library that contains most commonly needed modules is the key. If deno does not do that, I probably will never try that(as I can…

In Deno's case, there are two things: Deno API, which comes bundled with Deno and is present globally, always, without importing: https://doc.deno.land/deno/stable . Includes basic stuff like stdin, stdout, stderr, file management... etc and standard Web APIs like Fetch API, web assembly interoperability, localStorage, FormData, TextEncoder/TextDecoder, etc. Deno std lib, an official library that presents what you co…

I just noticed that Deno merged their native FFI support: https://deno.land/manual@main/runtime/ffi_api

I had been watching some issues around this, but lost track, so I'm very excited to see it is available now! This makes Deno _very appealing_ for a wide range of tasks where FFI is a small but non-negotiable necessity (places where I would use Python's ctypes, for example tooling around C libraries; such tooling becomes much more complicated if another toolchain and compilation step is required before lib can be called from a script).

Re: State of the Web: Deno

#90

Post by Soremwar »

andrewmcwatters wrote: post #87

Now instead of npm packages abusing SemVer unless you use non-default --save-exact behavior as an attack vector, we can import modules from URLs without subresource integrity unless you use non-default lock file behavior! Great! We learned nothing!

Hence why developers always recommend to use immutable sources when importing modules
Post reply on HN