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

Deno 1.9

deno.com

Post reply on HN
Print view View original

121–130 of 245 posts

Re: Deno 1.9

#121

Post by inbx0 »

syspec wrote: post #107

I have a question, how come people do not use Dart in place of this? It runs on the server, it is a typed language, it's faster than v8 javascript (since that is part of the reason for it's existence to eek out more performance) From what I've seen it can be distributed very as well, and your app is self contained ala Go. --- So my question is, why don't more people use Dart where they would use a "Node + 'Typescript…

How come more people don't use ReasonML in place of this? It runs as OCaml on the server, it is a typed language, it's faster than v8 JavaScript. Or F#? Not a fan of the functional? Then maybe Kotlin? Nim? No?

There are a ton of great languages out there, many arguably better than TS in many ways. But for a language to be popular, being great is not enough.

I'm not sure what it is that makes TS so popular, but I am pretty sure that you have to look past mere language qualities for it.

Re: Deno 1.9

#122

Post by spartanatreyu »

syspec wrote: post #107

I have a question, how come people do not use Dart in place of this? It runs on the server, it is a typed language, it's faster than v8 javascript (since that is part of the reason for it's existence to eek out more performance) From what I've seen it can be distributed very as well, and your app is self contained ala Go. --- So my question is, why don't more people use Dart where they would use a "Node + 'Typescript…

One major thing to consider when thinking about replacing JS with another language:

All JS already works inside TS so it's really easy to slowly transition your project over time between the two languages without losing any functionality or needing to take time off to make the transition.

In practice this means, new code can just be written with TS and any existing code updates can be made in TS. After that you can decide whether to even touch the remaining JS which still works.

Re: Deno 1.9

#123

Post by searchableguy »

zkldi wrote: post #120
Soremwar wrote: post #96

Earlier quoted context omitted.

You do something like this export * as Oak from "https://deno.land/x/oak/mod.ts"; export * as Postgres from "https://deno.land/x/postgres/mod.ts"; Then you do this: import { Oak, Postgres } from "./deps.ts";

> Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?) I know you can do this, but then you can't do import { Function1, Function2 } from "oak"; You could do import { Oak } from "./deps.ts"; const { Function1, Function2 } = Oak; But that is still an awful workaround.

There are user land tools to manage dependencies for you. I cannot comment on the specifics because I haven't used them extensively but one example is deno-udd.

It updates your dependencies. https://github.com/hayd/deno-udd

There are one or two more feature rich ones. The need for deps.ts can be eliminated with management tools which work with your imports directly.

Re: Deno 1.9

#124

Post by zkldi »

searchableguy wrote: post #123
zkldi wrote: post #120

Earlier quoted context omitted.

> Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?) I know you can do this, but then you can't do import { Function1, Function2 } from "oak"; You could do import { Oak } from "./deps.ts"; const { Function1, Function2 } = Oak; But that is still an awful workaround.

There are user land tools to manage dependencies for you. I cannot comment on the specifics because I haven't used them extensively but one example is deno-udd. It updates your dependencies. https://github.com/hayd/deno-udd There are one or two more feature rich ones. The need for deps.ts can be eliminated with management tools which work with your imports directly.

That's just a package manager!

If something like that is needed, then I think deno should attempt to come with something for managing dependencies.

Eventually, developer convinience will win, and everyone will settle on some sort of package manager for deno. It'd probably be for the best if deno made it official as, personally, I think this is heading towards a second NPM.

Re: Deno 1.9

#125

Post by searchableguy »

zkldi wrote: post #124
searchableguy wrote: post #123

Earlier quoted context omitted.

There are user land tools to manage dependencies for you. I cannot comment on the specifics because I haven't used them extensively but one example is deno-udd. It updates your dependencies. https://github.com/hayd/deno-udd There are one or two more feature rich ones. The need for deps.ts can be eliminated with management tools which work with your imports directly.

That's just a package manager! If something like that is needed, then I think deno should attempt to come with something for managing dependencies. Eventually, developer convinience will win, and everyone will settle on some sort of package manager for deno. It'd probably be for the best if deno made it official as, personally, I think this is heading towards a second NPM.

Not quite the same. It's a simple management tool which rewrites your imports to use the latest version from supported registries. Deno binary still handles all the resolution, fetching, caching and loading.

There are no plans to add such convenience in the binary because it would mean limiting places you can import from (cannot upgrade deps for unsupported registries). Deno binary will remain agnostic to where you import from.

Community will come up with something if it's a huge problem and settle eventually.

Re: Deno 1.9

#126

Post by jFriedensreich »

zkldi wrote: post #88

I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack. What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an obj…

i like to have multiple deps files roughly grouped. this reduces not only the likelihood of name clashes but also gives a bit more structure and in addition when running in the browser its possible to handle bundling the dependencies separately by that grouping.

Re: Deno 1.9

#127

Post by bavell »

austincheney wrote: post #68
tengbretson wrote: post #38

Earlier quoted context omitted.

Things like using UInt8Arrays instead of Node's homemade Buffer class, fetch, using WHATWG's implementation of Streams, Blob, WebWorker, etc.

Node's homemade Buffer class uses UInt8Arrays. https://nodejs.org/dist/latest-v15.x/docs/api/buffer.html#bu...

Not originally though: https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html#bu...

Re: Deno 1.9

#128

Post by sroussey »

zkldi wrote: post #120
Soremwar wrote: post #96

Earlier quoted context omitted.

You do something like this export * as Oak from "https://deno.land/x/oak/mod.ts"; export * as Postgres from "https://deno.land/x/postgres/mod.ts"; Then you do this: import { Oak, Postgres } from "./deps.ts";

> Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?) I know you can do this, but then you can't do import { Function1, Function2 } from "oak"; You could do import { Oak } from "./deps.ts"; const { Function1, Function2 } = Oak; But that is still an awful workaround.

Wouldn’t this work?

import { Oak: {Function1, Function2} } from "./deps.ts";

Re: Deno 1.9

#129

Post by joelg236 »

sroussey wrote: post #128
zkldi wrote: post #120

Earlier quoted context omitted.

> Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?) I know you can do this, but then you can't do import { Function1, Function2 } from "oak"; You could do import { Oak } from "./deps.ts"; const { Function1, Function2 } = Oak; But that is still an awful workaround.

Wouldn’t this work? import { Oak: {Function1, Function2} } from "./deps.ts";

This isn't valid syntax, no

Re: Deno 1.9

#130

Post by searchableguy »

rektide wrote: post #118
devgoldm wrote: post #114

As a primarily C++ dev who's been using nodejs on the side for about a couple years now - so forgive me if this is naive - but am I wrong in seeing Deno as a potential Electron replacement with standalone binary builds + webview? If so, the introduction of interactive permission prompts is pretty cool. I see a few comments from more experienced web developers that are quite negative about Deno that seem to generally…

there's webgl, webgpu, and dom, but it's a headless dom (jsdom) not a webview. I wouldn't be surprised to see packages developed for a webview but atm demo seems to target server side web platform compatibility... except rendering html! I wouldn't be surprised to see some packages try to fill the gap, & deno has a much stronger basis for implementation than node (a rpc layer between rust & v8 defines the core charact…

The most updated webview bindings I know of for deno: https://github.com/webview/webview_deno

It's likely you will find some hiccups in latest deno release because it uses rust plug-ins and they are getting overhauled at the moment. Maybe a few more months before getting stabilized.

Post reply on HN