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

71–80 of 245 posts

Re: Deno 1.9

#71

Post by coolreader18 »

tkzed49 wrote: post #58
maga wrote: 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?

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.

Re: Deno 1.9

#72

Post by aikah »

Tarucho wrote: post #50

What kind of improvement will this bring to the seasoned nodejs dev, that it will leverage the learning effort?

> What kind of improvement will this bring to the seasoned nodejs dev, that it will leverage the learning effort?

Not much right now, aside from 'native' Typescript support and not relying on NPM hell for everything. But as the project matures, it might be useful to take a look at it.

I personally hate having to rely on third party libraries for basic web-server functionalities, so a strong "official ecosystem" with batteries included is an interesting proposition.

Re: Deno 1.9

#73

Post by hayd »

paxys wrote: post #55
maga wrote: 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…

There's the web APIs which are tested against https://github.com/web-platform-tests/wpt (albeit without full coverage), and there is ffi/plugins - for deno specific things like readFile.

I don't know the history of Node... but why would there need to be a diversion?

Re: Deno 1.9

#74

Post by ROARosen »

sadturnip wrote: post #21

Have they resolved issues where many third party packages are not available for Deno? Like i don't see things such as MikroORM/Pino/Firebase-Admin on deno.land, and even things like AWS-SDK are out of date.

With deno you can import scripts from anywhere on the web you want, my personal favorite is jspm.dev which basically has all npm packages

Re: Deno 1.9

#75

Post by aikah »

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.

Re: Deno 1.9

#76

Post by andrewmcwatters »

I'm not looking forward to when I lose all my productivity with Node.js because the industry collectively agrees to move on to Deno and rebuild or port things that have been working just fine for the past decade, but OK, here we go.

Maybe I should just hedge my bets and get on the train now even though I don't want to.

Re: Deno 1.9

#77

Post by the_duke »

paxys wrote: post #55
maga wrote: 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…

The selling point was being able to write server code in Javascript and potentially share code between UI and server.

Node never implemented any of the essential browser APIs like XMLHttpRequest or later fetch, localStorage, etc.

Re: Deno 1.9

#78

Post by jorisd »

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…

The third slide of Ryan Dahl's 2009 JSConf.eu presentation (https://www.youtube.com/watch?v=ztspvPYybIY) covers most of the reasons for why it was made: "I/O needs to be done differently". Evented I/O via event loops wasn't really that much of a thing back then, and many server-side web frameworks were simply sitting idle whilst waiting on I/O. Node changed this, and thereby enabled a kind of concurrency that was easy to achieve and there by default, often without the programmer really realizing it, because they didn't have to do anything too special to get it done other than write JavaScript with callbacks.

I don't think JavaScript was really the point of it.

(EDIT: but JavaScript having functions as a first-class citizen, and closures, makes it a very good candidate for something that leverages event loops for this kind of thing)

Re: Deno 1.9

#79

Post by Soremwar »

andrewmcwatters wrote: post #76

I'm not looking forward to when I lose all my productivity with Node.js because the industry collectively agrees to move on to Deno and rebuild or port things that have been working just fine for the past decade, but OK, here we go. Maybe I should just hedge my bets and get on the train now even though I don't want to.

You don't ever lose productivity or knowledge on a tool when a new one comes out though. A new thing that people like becomes popular and people start using it, old one becomes less used but it doesn't dissapear.

You only really "switch" to a new tool if that's what you like the most, not because that's what people like now.

Re: Deno 1.9

#80

Post by steve_adams_86 »

andrewmcwatters wrote: post #76

I'm not looking forward to when I lose all my productivity with Node.js because the industry collectively agrees to move on to Deno and rebuild or port things that have been working just fine for the past decade, but OK, here we go. Maybe I should just hedge my bets and get on the train now even though I don't want to.

Having come from the node ecosystem, I find deno pretty welcoming and familiar overall. I'm glad to see a design I think is better, over all - so long as development continues, it seems like it'll be worth the shift.
Post reply on HN