Live data from Hacker News

Deno 1.9

deno.com

61–70 of 245 posts

Re: Deno 1.9

#61
post #55
post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

When Node first released its biggest selling point was being able to reuse web APIs. It also filled in gaps for APIs that weren't standard in browsers. Then browsers started to add these APIs, and some of Node's implementations naturally diverged (aka the idiosyncrasies that you mention). Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold fo…

You could argue that the apis in question are more mature now than when Node was first released.

Either way, if Deno is one day replaced by something else, say 'Done' to keep the naming convention, that won't refute the use everyone will have gotten out of Deno in the mean time, in the same way that Deno doesn't refute the use everyone has already gotten out of Node.

Re: Deno 1.9

#62

Earlier quoted context omitted.

That's a rather ignorant thing to say. You are basically saying "I feel like I have hit a point in my life where I don't want to learn." It doesn't matter if it's a framework, language, protocol, specification, book, way of coding, or anything else. Learning is how you gain knowledge and stopping ones desire to gain knowledge is never a "point in ones life". It's just being lazy.

Then why are you on here blathering about someone being ignorant when you are being "just as lazy" and not spending this time learning new$x.js instead of arguing on the internet? Have some compassion/empathy for those of us that don't have the luxury to be able to constantly keep up with what gets churned out every day.

Who said anything about compassion/empathy?

There is a difference between saying I won't try and convivence me otherwise. Versus saying I can't I don't have the time.

OP is very clearly saying I won't, they have given no indication as to the fact they don't have time to learn.

Re: Deno 1.9

#63
post #58
post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

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?

Deno uses ES6 modules, which are supported by modern browsers. There’s no node_modules. https://deno.land/manual/examples/import_export

Re: Deno 1.9

#64
post #55
post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

When Node first released its biggest selling point was being able to reuse web APIs. It also filled in gaps for APIs that weren't standard in browsers. Then browsers started to add these APIs, and some of Node's implementations naturally diverged (aka the idiosyncrasies that you mention). Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold fo…

JavaScript itself has gone through about a 10-year transition period from a toy language for writing quick scripts to a full-on general-purpose programming language. It didn't even have a module system when Node launched.

So I strongly doubt the next 10 years will be anywhere near as tumultuous as the past 10. It's very possible that right now is just a much better time to be establishing a JS runtime.

Re: Deno 1.9

#65
post #55
post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

When Node first released its biggest selling point was being able to reuse web APIs. It also filled in gaps for APIs that weren't standard in browsers. Then browsers started to add these APIs, and some of Node's implementations naturally diverged (aka the idiosyncrasies that you mention). Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold fo…

Indeed. I remember that, I have been using node since the very early days, and switched to it for precisely that reason--that I could use the same language through my web application. Nevertheless, when we did get those modern web API, Node was slow to change or adapt them, although, it's doing its best now.

In case of Deno, I hope they just stick to following the standards and changing with them. They might not, I cannot vouch for them. On the other hand, I was also skeptical about TypeScript following ECMAScript. I though at some point they'll get too much into conflict and MS will refuse to follow, but so far I've been proven wrong. And from the looks of it, TS even deprecates stuff that is likely to conflict with upcoming ES versions.

Re: Deno 1.9

#66
post #58
post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

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?

Snowpack might be an option

Re: Deno 1.9

#67
post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

What do you mean by reuse of web apis? I’m curious to read up on this feature.

[deleted]

Re: Deno 1.9

#68

Earlier quoted context omitted.

What do you mean by reuse of web apis? I’m curious to read up on this feature.

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...

Re: Deno 1.9

#69
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…

Do you have an actual experience with nodejs/deno?

There are many (server-side) things where javascript is not a good choice but "smart-proxies" or micro-service-orchestration kinds of things are definitely super-easy to do in nodejs.

I've also done many languages, like really, and I don't know any better for this task.

What's your choice BTW?

Re: Deno 1.9

#70
post #53
post #39

I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.

Deno has a couple of very good selling points, the main one is that it allows to use JS web browser API's in the CLI, this includes things that range from the Fetch API[1], up to WebGPU even! all in the command line interface. Besides this, it uses the same module system as the browsers do. The JS module system is in my opinion very well designed and intuitive. No need for AMD or CommonJS or Node require's. Other goo…

I personally really like the `Deno compile` feature which outputs your code into a self-contained .exe which executes your script no need for separate tools.
Post reply on HN