What exactly does deno promise when it comes to package management?
Deno 1.9
81–90 of 245 posts
Re: Deno 1.9
#82Earlier quoted context omitted.
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.
Nope, that’s why there’s a million node-fetch, isomorphic-fetch, etc variants
Re: Deno 1.9
#83I feel like I have hit a point in my life where I don't want another framework to learn, and due to this I am not giving Deno a fair shake... Does anyone have a short anecdote why I might bother to invest in yet another JS framework?
You're getting a lot of responses. I just want to say that I empathize with you.
I'm not at that point in my life where new technologies don't excite me. I'm still happy to learn new things. But I fully expect I'm going to get tired of the next wiz bang language, the next gee wow framework, the next hot stuff server. I get it.
There's still value in knowing what you know. I wish people didn't think so much otherwise.
Re: Deno 1.9
#84The 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?
Just like you did in the browsers back in the day when you imported code from URLs with , the "deno way" is supposed to follow browsers in these regards as well.
And you can always use `npm`, `node_modules` and `import maps`[0][1][2] to kind of mimic "nodejs way".
[0]: https://wicg.github.io/import-maps/
[1]: https://blog.logrocket.com/es-modules-in-browsers-with-impor...
[2]: https://deno.land/manual/linking_to_external_code/import_map...
Re: Deno 1.9
#85Earlier quoted context omitted.
Can't comment on sibling, but https://www.skypack.dev/ lets you import many npm packages; I haven't tried the AWS library, though.
That looks pretty cool; it's unsurprising that there's an automated solution since the differences are so small and predictable Edit: Does this do automated conversion? I can't actually tell
Yes, it's automated.
Re: Deno 1.9
#86I'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.
Welcome to software development, friend. The secret is it's all one big treadmill. You don't get paid for standing still.
Re: Deno 1.9
#87Regularly writing Typescript code both for frontend (React) and backend. Most is hosted on GCP.
What's the best path to hosting an API (Fastify-based) on GCP with Deno today?
Re: Deno 1.9
#88I'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 object under the name of the library (and therefore give up destructuring?)
The URL thing seems similarly cumbersome and unecessary. Is there something wrong with a configuration file that would map 'package names' to the urls to get them from?, and then import { foo } from "packagename"?
[1]https://deno.land/manual@v1.9.0/examples/manage_dependencies
Re: Deno 1.9
#89I'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 found most of the dependency woes to go away with import maps: https://deno.land/manual@v1.9.0/linking_to_external_code/imp...
Re: Deno 1.9
#90Earlier quoted context omitted.
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.
Woah, is that a thing? Very cool.