[HN Gopher] Deno 1.9
___________________________________________________________________
Deno 1.9
Author : searchableguy
Score : 291 points
Date : 2021-04-13 19:14 UTC (3 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| Tarucho wrote:
| What kind of improvement will this bring to the seasoned nodejs
| dev, that it will leverage the learning effort?
| aikah wrote:
| > 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.
| andrewmcwatters wrote:
| 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.
| indymike wrote:
| Deno's not too far off the mark if you know Node.
| coldpie wrote:
| Welcome to software development, friend. The secret is it's all
| one big treadmill. You don't get paid for standing still.
| Soremwar wrote:
| 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.
| steve_adams_86 wrote:
| 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.
| rsp1984 wrote:
| 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.
| paxys wrote:
| In the simplest terms, it is meant to be a replacement for
| Node.js.
| HugoDaniel wrote:
| 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 good things about Deno is that it includes a lot of
| goodies by default. In that single binary you get in your
| command line interface:
|
| - A very very decent and fast bundler (bundling in JS is a
| mess, the Deno is straightforward and needs no config and no
| hacks, which, surprisingly is unique in the JS bundling scene)
|
| - Testing library
|
| - TypeScript support (for those that like it)
|
| - Documentation generator
|
| - Linter
|
| - Syntax modifier (like prettier)
|
| - Official VS Code plugin
|
| Unlike Node, it uses Rust to bridge the gap between the JS
| engine and the OS, and leverages on a lot of very cool Rust
| libraries.
| ROARosen wrote:
| 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.
| ketzo wrote:
| Woah, is that a thing? Very cool.
| divbzero wrote:
| Deno is designed to be a replacement for Node.js on the server.
| The introduction to the Deno Manual [1] provides a comparison.
|
| [1]: https://deno.land/manual@v1.9.0/introduction
| stevieoop wrote:
| deno supports typescript out of the box whereas to run
| typescript in nodejs you need to transpile down to javscript
| first. deno also has some security features enabled by default
| like not allowing network communication unless you explicitly
| enable it. so that prevents malicious packages from making
| network requests that you might not have noticed. thats a great
| feature because tons of javascript projects/tools dont need to
| send http requests so if your tool doednt require that then you
| can be confident that any dependency you use is not secretly
| spying on you.
| sod wrote:
| * Running a linter without granting it write or net access
|
| * Running a build tool with only file access to the source
| files
|
| * Trying a cli script without granting it access to everything
| by just showing the help
|
| In times where a linter has 10000 dependencies, I'm in
| desperate need of sandboxing.
|
| People on hackernews are easy to judge companies when they leak
| customer data. But what if we the developers are actually the
| problem by executing megabytes of foreign code just with faith.
| zamadatix wrote:
| Deno is by the original creator of Node.js and seeks to
| fix/change a few things about Node he regretted while adding
| first class support for a few things that were new since then
| like TS. It's also more security minded from the get-go. Not
| just in a "written in a memory safe language" way but it has a
| permissions system and strong built in ways to inspect/audit
| dependencies.
|
| So it's not aiming to be revolutionarily different from Node,
| rather a second shot at Node.
| jppope wrote:
| Deno is meant to be an improvement on the nodejs ecosystem.
| Ryan Dahl took everything that he learned from node and
| improved upon it with Deno. There are a series of features like
| native typescript support, having single executable, url
| imports, etc that are all very pleasant improvements. The idea
| is that it will make for a better developer experience.
| k__ wrote:
| It's a Node.js alternative.
|
| Deno glue code around V8 is written in Rust.
|
| It tries to be as close to the browser API as possible, using
| ES-Modules instead of CommonJS and doesn't require a package
| manager.
|
| Also, it compiles TypeScript automatically.
| topicseed wrote:
| Regularly 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?
| maga wrote:
| 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.
| FractalHQ wrote:
| What do you mean by reuse of web apis? I'm curious to read up
| on this feature.
| tehbeard wrote:
| Things like ArrayBuffer/view, fetch(...) and worker threads
| being the same spec/interfaces as the browser implementations
| rather than homegrown stuff like Buffer, child_process and
| any number of npm wrappers around the http module in node.
| TechBro8615 wrote:
| Hopefully the story is the same in five years after Deno
| and browsers have both had time to evolve. Are there plans
| in place for tracking future updates to Web APIs in Deno?
| monocasa wrote:
| 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.
| maga wrote:
| This. I started tinkering with node shortly after I heard
| Ryan introduce it at JSConf EU, and it was a very different
| world, not much for Node to draw from on the browser side,
| no modules, no promises, not even TypedArrays IIRC.
| paxys wrote:
| 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.
| tengbretson wrote:
| Things like using UInt8Arrays instead of Node's homemade
| Buffer class, fetch, using WHATWG's implementation of
| Streams, Blob, WebWorker, etc.
| austincheney wrote:
| Node's homemade Buffer class uses UInt8Arrays. https://node
| js.org/dist/latest-v15.x/docs/api/buffer.html#bu...
| [deleted]
| paxys wrote:
| 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 for?
| hayd wrote:
| 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?
| brundolf wrote:
| 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.
| maga wrote:
| 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.
| the_duke wrote:
| 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.
| halfmatthalfcat wrote:
| Nope, that's why there's a million node-fetch, isomorphic-
| fetch, etc variants
| bijection wrote:
| 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.
| tkzed49 wrote:
| 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?
| sjy wrote:
| Deno uses ES6 modules, which are supported by modern
| browsers. There's no node_modules.
| https://deno.land/manual/examples/import_export
| sdfhbdf wrote:
| Just like you did in the browsers back in the day when you
| imported code from URLs with <script src="">, 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...
| zdragnar wrote:
| Snowpack might be an option
| [deleted]
| coolreader18 wrote:
| 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.
| GenerocUsername wrote:
| I 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?
| oehpr wrote:
| 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.
| k__ wrote:
| Good news.
|
| Deno tries to be as close to the browser API as possible. So
| it's easier to learn than Node.js if you come from frontend
| development.
| brundolf wrote:
| It isn't a framework, it's a runtime. You use it instead of
| Node, and the headlining feature is you can run TypeScript
| without a separate build step. The system APIs are different
| than Node's but those are analogous/easy to learn, and the
| language itself is still just JavaScript/TypeScript, so there
| isn't really much to learn.
|
| With that said: I've used it for a couple projects because I'm
| really interested in its value-proposition, but so far I'm not
| impressed with the dev experience when it comes to editor
| integration. It brings its own language server because it has a
| few tiny caveats, and the language server doesn't work nearly
| as well as the official TypeScript one. Type changes sometimes
| don't propagate across files, auto-imports are lacking the file
| extension (which Deno requires, so you have to go and manually
| edit them all), etc. Given that frictionless TypeScript support
| is the major draw, this is a pretty serious issue for me.
|
| I hope it gets there some day, but for me it isn't there yet.
| wperron wrote:
| Sorry you've had this experience -- the LSP is improving a
| lot with every release, this one included, try it out and let
| us know what you think. We really appreciate issues for the
| LSP on GH
| brundolf wrote:
| Thanks- I should probably actually file bug reports :)
|
| I am curious though: why roll your own? It seems like the
| only real differences are a) URLs/file extensions in the
| module names, and b) some type declarations for the system
| APIs (which I'd think just come down to some .d.ts files,
| not custom LSP logic). Microsoft's TypeScript language
| server is a wonder of engineering, and I doubt any small
| independent team would ever be able to go toe-to-toe with
| it. Seems like a waste to forego that if there's any
| possibility of utilizing it. A minimal fork maybe, if
| nothing else?
| wperron wrote:
| There's a couple of reasons. Internally, there's quite a
| few things that we do in Rust that aren't actually taken
| care of by TypeScript -- Having our own LSP allows us to
| connect those bits (like the module graph resolver for
| example) directly to the internals of Deno, in-sync with
| the Deno version you have installed.
|
| Deno also does more stuff than just providing Type
| definitions, embedding TypeScript and doing module
| resolution; it's a complete toolset -- there's things
| that we can cover having our own LSP that the TypeScript
| LSP can't. Linting, formatting, testing etc.
| lucacasonato wrote:
| TypeScript does not actually have a native language
| server. TSC is just directly shoehorned into VS Code. It
| is very difficult to extend (we tried with the 1.x and
| 2.x branch of our extension). We needed to do a lot of
| trickery to get TSC to do what we want, and even then it
| would not always work. That solution also only worked on
| VS Code. Our new LSP works on all editors with LSP
| support. We are hoping that in the coming few weeks /
| months the Deno LSP will be just as featureful as TSC +
| Node in VS Code, and way more performant. We still have
| some ways to go, but we are slowly getting there.
| brundolf wrote:
| Ah gotcha, that's unfortunate that they integrated it
| directly, though it explains a lot.
|
| Well I'm glad to hear it's a priority. Best of luck, and
| I'll try to check in periodically and see how things are
| coming along! I would very much like to see this project
| succeed :)
| paxys wrote:
| This is only partially true. TypeScript does have
| tsserver built in, which is where the language server
| design originated from (just with a slightly different
| API). The VS Code TypeScript integration is a layer
| around that, not a custom implementation. There are also
| a couple other TypeScript language servers out there
| (which again simply wrap tsserver and translate the APIs)
| which work great.
| konart wrote:
| Should we tell him that this is not a framework? Anyone?
| croes wrote:
| No.
| asidiali wrote:
| ...de alternative!
| dubcanada wrote:
| 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.
| tehbeard wrote:
| 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.
| dubcanada wrote:
| 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.
| pupdogg wrote:
| short_anecdote: don't switch, it's not for you!
| hayd wrote:
| It's not a framework, it's a JS runtime on top of v8 (like
| node).
| programmarchy wrote:
| Deno has first-class support for TypeScript. Refactoring code
| without types is not a pleasant experience.
| johnfn wrote:
| Deno isn't a framework, it's a node.js alternative. The best
| pitch I've heard is that it's written by the same guy who did
| node.js, with the intent to fix everything he thought he got
| wrong with node.js.
| FractalHQ wrote:
| Is it technically a framework? I thought it was an entire
| alternative runtime to NodeJS.
| remexre wrote:
| Well, Deno's not really a framework, it's a runtime (like
| node.js). If you're writing Typescript, it makes that way
| easier. If you're doing lots of IO, it makes that easier
| (promises). If you want sandboxing, it has that (though if it's
| for server software, you should use firejail or Docker or
| something around it anyway).
| devmunchies wrote:
| does it interop with libs made for node.js and are on npm?
| e.g. using the official the AWS node.js library
| brundolf wrote:
| It doesn't load libs from NPM directly, it has its own
| package management system based around URLs. _Most_
| JavaScript /TypeScript logic should port to it trivially,
| unless they use system APIs, in which case those will have
| to be converted to Deno's system APIs. But mostly that just
| comes down to "swap out function X for Y and rearrange the
| parameters a bit".
|
| So in practice: it's super easy to port something, but most
| of the time you do actually have to port it, unfortunately.
| remexre wrote:
| Can't comment on sibling, but https://www.skypack.dev/ lets
| you import many npm packages; I haven't tried the AWS
| library, though.
| brundolf wrote:
| 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
| remexre wrote:
| Yes, it's automated.
| wperron wrote:
| The canonical answer is _maybe_. If your Node lib relies on
| Node built-ins, you won't be able to import it directly
| from GitHub for example. However, CDNs like Skypack and
| esm.sh do polyfill some of those to Deno. Your mileage may
| vary depending on the lib you're trying to import. Some
| will work better on one CDN, some on another -- you really
| just have to try it for yourself. A surprising amount of
| libs work without issues.
|
| The AWS sdk v3 works really well from Skypack, check out
| our docs for our Deploy platform, it has an example with
| DynamoDB https://deno.com/deploy/docs/tutorial-
| dynamodb#write-the-app...
| turbinerneiter wrote:
| Deno isn't a JS framework?
| tannhaeuser wrote:
| You mean it's a runtime, like Node.js? /s
| turbinerneiter wrote:
| I guess roughly a billion people were just as triggered as
| I was and now there are all these redundant "actshually"
| comments :D
| [deleted]
| tolmasky wrote:
| It's really weird that most responses to you are that Deno
| isn't a framework, as if changing the category the thing is in
| would somehow magically remove your choice fatigue, especially
| considering that the most likely interpretation of your fatigue
| would make the distinction between runtime and framework fairly
| meaningless in this case: they are both for practical purposes
| a set of APIs you must learn on top of an existing language you
| probably already know. Whether under the hood they are
| implemented as Rust bindings that require you to run your app
| in a specific binary, vs. being written in JS, probably doesn't
| matter, and if anything would make the endeavor _more
| complicated_ and raise the bar necessary to convince you to
| learn it _even more_.
|
| Either way, barring your work forcing you to learn something,
| or you running into a specific problem that requires you to
| learn something new, you should really treat
| frameworks/runtimes/languages/etc. the same as TV shows or
| comics, and I mean this in a very positive way. If you enjoy it
| and have the bandwidth for it, then of course pick up a new
| show or comic and invest some time into it! Especially if a
| trusted friend recommends it to you. It might introduce you to
| new ideas or give you a different perspective. And most
| importantly, you probably won't get as much as you would out of
| it if it doesn't seem exciting. You won't _miss out_ on it if
| you decide to punt it until later, I promise you. This isn 't
| some Thanksgiving Day sale, if in a year it's more popular than
| it is today, there'll only be better articles and tutorials
| that have been written, more bugs having been fixed, and more
| libraries already existing for it than today. And if it ended
| up not being that great, you probably won't hear about it in a
| year anymore, and you will have spent your time on a thing you
| do enjoy. So don't force it, if it seems cool to you or
| resonates with you for any reason, try it, otherwise, no big
| deal!
| croes wrote:
| Maybe because there are way more JS frameworks than runtimes.
| It feels like dozens of frameworks pop up every day.
| tolmasky wrote:
| Yes but my point is that this doesn't address the OP's
| frustration: learning new APIs without a clear sense of
| what one is getting out of it. Many of Deno's fundamental
| features _are basically framework features_. Learning the
| Deno for-await API for answering HTTP requests is an
| identical experience to learning a framework that offers
| that API. "But Deno has fundamental performance
| improvements" -- Frameworks can also offer fundamental
| performance improvements. In fact, I can write a Rust-
| backed binary package for node.js and now we're really in a
| grey area.
|
| The point is that "its a runtime not a framework" is not an
| answer as to why he should learn it or not. At least, not
| without attaching to it a meaningful explanation as to the
| benefits he'll get from it because its a runtime, but at
| that point, we're back where we started: just pitch him on
| what he'll get out of it, don't correct him on technical
| terminology.
| brundolf wrote:
| Frameworks tend to dictate a certain way of doing things and
| introduce a pile of their own concepts and abstractions.
| Runtimes tend to be unopinionated. There's very little
| learning-fatigue around Deno, and there's almost no choice-
| fatigue since it's only the second mainstream (non-browser)
| JS runtime.
| tolmasky wrote:
| Perhaps in the general case, but Deno is probably as
| opinionated or more so than your average JS framework
| choice on node.js. And certainly more opinionated than a
| more "neutral" runtime change like when Microsoft made the
| Chakra-backed node.js. For example, choosing to go with
| Deno cuts you out of much of the npm ecosystem (either due
| to the specific module model, or simply because the
| fundamental APIs are different, which is why express won't
| run "out of the box" on Deno -- there had to be ports of
| express and koa, etc.), which certainly is a bigger side-
| effect than switching from React to Vue. It also, to its
| credit, bets big on Typescript, a very opinionated decision
| (and I'd argue a good one too!). It bets big on async/await
| (which is still somewhat contentious in the node.js
| community, but luckily fading). In other words, there's not
| a lot of information conveyed from "it's a runtime not a
| framework," at least not in this case, aside from technical
| aspects. And again, I think it is precisely worth pitching
| it _on its opinions_ , like the browser-compatible APIs,
| etc.
| [deleted]
| worik wrote:
| 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 client,
| server, on any _& &^^*!! thing!
|
| I still do not see the need for Javascript anywhere but in a
| browser, and with Webassembly, most of the impressive things done
| in the browser do not need Javascript any more.
|
| So my preference is for Javascript to quietly die out in a
| dignified exit stage left. But I am not always completely
| correct. So if you must, then use Deno. Node.js is simply awful.
| Deno is only useless. A vast improvement._
| neximo64 wrote:
| 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_.
| aikah wrote:
| 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.
| jorisd wrote:
| 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)
| cztomsik wrote:
| 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?
| sadturnip wrote:
| 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.
| ROARosen wrote:
| 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
| wperron wrote:
| Pro tip: don't import those libs from deno.land/x. The runtime
| is agnostic to where you're pulling libs from, and that's by
| design. The AWS SDK v3 for example works great through the
| Skypack CDN, and you're pulling the canonical one, not simply a
| port maintained by a third party.
| zkldi wrote:
| 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 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
| dpweb wrote:
| 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.
| vexna wrote:
| 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...
| zkldi wrote:
| oh damn, that's _exactly_ what i 've wanted.
| sujayakar wrote:
| it seems like libraries can't use import maps though, right?
| the final binary can provide that flag, but is there a way
| for library dependencies to specify their own import maps?
| the spec [1] has support for scoping, but I didn't see a way
| to integrate that with the Deno loader.
|
| [1] https://github.com/WICG/import-maps#scoping-examples
| Soremwar wrote:
| Yeah, libraries can't use import maps because import maps
| are not extensible
| Soremwar wrote:
| 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";
| pictur wrote:
| What exactly does deno promise when it comes to package
| management?
___________________________________________________________________
(page generated 2021-04-13 23:00 UTC)