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

101–110 of 245 posts

Re: Deno 1.9

#101

Post by IggleSniggle »

coolreader18 wrote: post #71
tkzed49 wrote: post #58

Earlier quoted context omitted.

How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?

Maybe there's a bundler/webpack plugin that supports deno's import system, so it just fetches whatever http urls/analyzes the import maps and turns it into a normal web bundle.

Deno’s import system is just the ecmascript import system. So, it works exactly the same way it does in the browser. Or with curl. Or whatever. You just supply a uri and get the resource at that location. Things like import maps are just a way to make that more convenient during development, but there’s no secret system for pulling these pieces together; it’s just the ecmascript module standard (that didn’t exist until more recently).

Re: Deno 1.9

#102

Post by anderskaseorg »

dpweb wrote: post #92
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…

Not sure I’d use the local deps file. I really like just the import {..} from “ https://xn--ivg . The version, everything, is up front and explicit.

The problem the deps.ts pattern solves is that your project has several dozen modules that all import a particular version of a dependency, and now you need to update them all to a new version of that dependency.

(If your project only has one module, then you don’t have this problem and don’t need this solution.)

Re: Deno 1.9

#103

Post by int_19h »

neximo64 wrote: post #97
worik wrote: post #56

I have been programming computers since 1988, so I have seen a lot of things come and go. Not often has there been a just relationship between quality and popularity. Never has that been so stark as with Node.js. So many mistakes, mistakes that have been made before. Such a mind boggling lack of purpose. There has never been a need for Node.js - except to play with the cool kids that programme Javascript on the clien…

And yet it is the most popular programming language in the world.. So maybe you're not exactly right. In the end it's not about what coders need it's what they want .

It's the most popular PL because it ships in every browser out there, and so you have to use it to do any front-end work. It doesn't really say anything about the quality of the language or its ecosystem.

Re: Deno 1.9

#104

Post by IggleSniggle »

paxys wrote: post #49
monocasa wrote: post #37

Earlier quoted context omitted.

Defaulting to browser based APIs when they exist (like a global 'window' element to access the DOM), rather than reinventing the wheel the way Node did. Although to be fair a lot of Node APIs predate their browser equivalents, and in a lot of ways the browser contains a 2.0 version of a lot of Node APIs.

I can't think of a single case of Node reinventing the wheel with their APIs. Like you said, they were all created to fill gaps in browser JS implementations. It's obviously going to be hard to reconcile the two as browsers themselves increase their API surface, but then Deno is going to run into the same problem eventually.

I think that depends on how much deno commits to following the web APIs with each release.

Actually, nodejs has really done a lot of catching up with deno in this regard. It just has to support both the “legacy” way and the “forward looking” way where deno does not.

Re: Deno 1.9

#105

Post by int_19h »

aikah wrote: post #75
worik wrote: post #56

I have been programming computers since 1988, so I have seen a lot of things come and go. Not often has there been a just relationship between quality and popularity. Never has that been so stark as with Node.js. So many mistakes, mistakes that have been made before. Such a mind boggling lack of purpose. There has never been a need for Node.js - except to play with the cool kids that programme Javascript on the clien…

Often the worth of a language comes from its ecosystem. Node.js for now has perhaps the biggest ecosystem in history of computer languages and since Javascript is supported natively by browsers, well it makes the number of developers knowing Javascript quite substantial. It's no worse than Python, Perl or others.

I would argue that much of the Node ecosystem suffers from the same flaw as "millions of apps" advertised by Apple and Google on their mobile platform: most of it is useless one-liners, or abandonware.

Now, when you filter it all out, it's still not any worse than Python etc - but it's not any better, either.

Re: Deno 1.9

#106

Post by zomglings »

I'm curious, if anyone has lived through the experience: What is the migration story like to port an existing codebase from node.js to Deno?

Re: Deno 1.9

#107

Post by syspec »

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 compiled to JS'" combination, which seems like it has a lot of headaches once your project grows in size

Re: Deno 1.9

#108

Post by mixedCase »

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…

Dart is an extremely limited language compared to TypeScript (it doesn't even have sum types), and has access to a much smaller ecosystem. Its runtime isn't much better either, like for example Go's or Haskell's is.

Deno has a partial implementation of Node's API, and even without it it's still the same underlying runtime concepts, so porting is easier than porting to another language like Dart.

Re: Deno 1.9

#109

Post by s_tec »

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…

If your team has invested a lot of time & energy into mastering the Javascript ecosystem (including things like Typescript), it makes sense to use the same language on the server side as well. Server machines are cheaper than good developers, especially if you can share resources between the backend & frontend.

As for Deno specifically, it's definitely closer to the "browser" way of doing things than Node is, which is super attractive. The main reason to stick with Node is the huge library ecosystem, but Node itself feels kinda weird & old, since the language has moved in a different direction while Node has remained stagnant (poor support for promises & ES modules, for instance).

Re: Deno 1.9

#110

Post by jonny_eh »

paxys wrote: post #49
monocasa wrote: post #37

Earlier quoted context omitted.

Defaulting to browser based APIs when they exist (like a global 'window' element to access the DOM), rather than reinventing the wheel the way Node did. Although to be fair a lot of Node APIs predate their browser equivalents, and in a lot of ways the browser contains a 2.0 version of a lot of Node APIs.

I can't think of a single case of Node reinventing the wheel with their APIs. Like you said, they were all created to fill gaps in browser JS implementations. It's obviously going to be hard to reconcile the two as browsers themselves increase their API surface, but then Deno is going to run into the same problem eventually.

Node introduced the "global" object instead of using the existing "window" object the pre-existed in all browsers.
Post reply on HN