[HN Gopher] Deno 1.14
___________________________________________________________________
Deno 1.14
Author : sondr3
Score : 233 points
Date : 2021-09-16 11:24 UTC (11 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| eins1234 wrote:
| One of the most exciting opportunities IMO that Deno opens up,
| compared to most traditional server-side frameworks, is the
| possibility for simple url-based live-reload workflows in
| production.
|
| I'd love to be able to develop backend services by pushing source
| code to some url as I develop, and then have the production
| instances of the service notified of the changes and reload
| themselves immediately for a super-tight feedback loop.
|
| In theory, building this kind of workflow in Deno should be very
| feasible, so I'm hoping to give it a shot in the not too distant
| future, but I'm wondering if anyone else has already tried it?
| tlarkworthy wrote:
| I built this https://webcode.run/
| tengbretson wrote:
| This is the biggest upside I see for Deno. I imagine a lot of
| fat could be trimmed in service orchestration with something
| that simply resembles a headless browser, and all it takes to
| deploy new code to your running service is giving it the
| equivalent of an `f5` and you're on your way.
|
| Heck lets get this headless browser running in Ring 0 and skip
| to the end of Gary Bernhardt's dream.
| gavinray wrote:
| This is a really old concept with interpreted languages,
| Capistrano in Ruby came out in 2006 for this sort of workflow:
| https://en.wikipedia.org/wiki/Capistrano_(software)
|
| 10 year old gist for this exact thing: https://
| gist.github.com/rchampourlier/1281506/a22148264c457ebb69259261f
| 117548569be6bef
|
| Same exists in Node, using PM2 process monitor via rsync/ssh:
| https://pm2.keymetrics.io/docs/usage/deployment/
|
| Run a command, new code is pushed to server files, you have a
| file-watcher daemon monitoring the directory and stopping +
| restarting the app, or you run stop/start as part of the deploy
| command.
| geofft wrote:
| Arguably, this is the model of CGI, which is about a decade
| older. Every time you hit a page on a CGI-powered service, it
| starts up a new process that runs your script. So you just
| edit a shell/Perl/PHP/Python/etc. file in place (or edit it
| locally, and FTP/SCP/etc. it to the remote host) and
| immediately on the next page load you see the impact of your
| change.
|
| It was kind of the original "serverless" - you'd often host
| it on a shared (multitenant) server with other users, with
| someone operating the web server for you and providing you
| with storage space. And it was a great development experience
| for small sites, especially for people new to web
| programming, and I miss it a lot.
|
| For performance reasons people built "FastCGI" where you have
| a long-running process that handles multiple requests, and
| for software engineering scaling reasons people moved away
| from the model of one file on disk per URL (and URLs mostly
| mapping to file paths on disk), and then eventually we got
| the setup we have now.
| [deleted]
| eins1234 wrote:
| Thanks for sharing! I have to admit that I am probably very
| ignorant of backend dev paradigms in general since I got my
| start in frontend dev. Definitely cool to see that I'm not
| anywhere close to the first one to find this kind of workflow
| compelling.
|
| IMO the possibility for an air-tight feedback loop is _the_
| killer feature for interpreted languages vs compiled ones. I
| can always feel my productivity plummet whenever I work in an
| environment that takes that away from me. I wish more people
| would try to take advantage of it.
| kbenson wrote:
| Some frameworks will offer this as part of the development
| process with a development server. Mojolicious (Perl) for
| example ships with Morbo as a development webserver, and
| Hypnotoad as a more enterprise ready one. One of the major
| differences is that morbo will take a path and auto-reload if
| any file in it updates, while hypnotoad offers zero downtime
| reloads, but you have to manually tell it to restart.
|
| Arguably a delineation like this is better, even if just a
| single flag separating the behavior in the server, since it
| allows production to not worry about some file copies/changes
| forcing lots of reloads that aren't needed, which isn't
| really a problem in most development environments.
| scns wrote:
| Does anyone know of providers for running deno FAAS style? Or is
| a VPS needed?
| siscia wrote:
| How it is the zero-copy ArrayBuffer transfer function
| implemented?
| lucacasonato wrote:
| ArrayBuffers are just views on underlying memory owned by the
| thread a V8 isolate is running on. (Each worker runs on a
| separate thread, each with its own V8 isolate). When we
| transfer an ArrayBuffer, we detach the underlying memory from
| the isolate in the sending thread, and move ownership of the
| memory area to the receiving thread, where a new JS ArrayBuffer
| object is created that points to that memory area.
|
| TLDR: The memory is never moved, the pointers to it are just
| detached from one isolate, and instead passed to another.
| csmpltn wrote:
| Hats off to you, helping Javascript programmers break out of
| the matrix ;)
| cylde_frog wrote:
| I'm convinced to try deno. I only use node for small testing
| scripts so it should be easy enough.
| IshKebab wrote:
| Deno is really awesome for shell scripts. Forget Bash. Forget
| Python. Deno is way better.
|
| You get a fairly sane type system, good performance, easy
| deployment (it doesn't count as easy if it's a pain on Windows),
| supports single file scripts _with third party dependencies_ ,
| and no compilation to deal with.
|
| There aren't really any alternatives that offer all that as far
| as I know.
| up6w6 wrote:
| https://github.com/denoland/deno/discussions/11771
|
| > NodeJS compatibility, what is our high-level strategy, goals,
| next steps?
|
| > Do we see Node and Deno co-existing, or do we want to think of
| Node as "legacy"? (Note, there was no clear decision on this
| question, it was just a conversation)
|
| > If we could say "you can run your Express server under Deno
| faster than Node" would that encourage adoption? No clear answer
|
| I really wish they go for a better compatibility with Node and
| sell themselves as a replacement that is strictly better.
| Mikeb85 wrote:
| Node is from the days before ES6 and uses a different API.
| Should just kill it and start fresh. Deno conforms to modern JS
| standards and is much more pleasant to use in pretty much every
| way.
| FinalBriefing wrote:
| I agree that that's the direction of the future. I wouldn't
| start a new, important project with Deno just yet. It's still
| the early days.
| mcguire wrote:
| Yeah, things like Oracle drivers might be nice.
| justshowpost wrote:
| Choose one:
|
| 1. Same. 2. Better.
|
| You can't have both. Since getting better involves change,
| which is the opposite of staying the same.
| sgtnasty wrote:
| How many runtimes are there for JS? They seem to pop up once a
| week...
| singularity2001 wrote:
| follow up question: how many different incompatible ways to
| require(), import ... are there?
| RobertKerans wrote:
| Two (import + require, which, as import didn't exist, was
| necessary). Most current tooling is built to handle both
| (Deno draws a line under it by disallowing the older one)
| RobertKerans wrote:
| Practically, number of browsers + 2 (Node and Deno, and Deno is
| stretching the definition of practical at this early stage).
|
| Edit: + Electron + the JS runtime used for Windows ecosystem
| based on Chakra (not sure if that's still alive though?) + a
| few other similar ones in that vein for desktop or mobile OS'.
|
| + whatever is available for embedded & similar devices, (I
| guess there will be a few but I know little about that area).
|
| + various [highly] specialised business/academic/hobby/PoC/etc
| runtimes, but they're not realistically things that many people
| care about.
| rubyist5eva wrote:
| Anyone using Deno in production? Would love to hear how it's
| going for your team.
| priansh wrote:
| We tried it for a couple months, it was basically a huge hassle
| getting our stuff to work especially anything that has bindings
| to CPP (any of the node gyp packages). Also felt like we were
| putting in a lot more effort to try to get packages with docs
| for node to work similarly in deno, and weren't really feeling
| any value from using deno over node.
|
| If you're a hobbyist or an academic or starting a totally new
| project that won't have dependencies/doesn't need a large
| community of modules, then I recommend deno. Otherwise I highly
| recommend sticking to node until deno comes out with something
| to make the switch more appealing.
| hardwaregeek wrote:
| Yeah I wonder how this will work long-term. I haven't heard
| of an ecosystem where they successfully avoided packages.
| Eventually you need some way of pulling in code that's
| versioned and has versioned dependencies of its own.
| Otherwise you end up with implicit versions or rolling your
| own everything, both of which are less than ideal and not
| necessarily better than packages. Deno could keep adding
| stuff to its standard library but I doubt even the largest
| stdlib could fit all users' needs.
| vorticalbox wrote:
| I honestly think the switch (being getting node libraries
| working in deno) won't happen.
|
| I believe it will be a much better if the community puts time
| into making a larger module pool that is upto the standard of
| node
| IggleSniggle wrote:
| I agree with this entirely. I would _absolutely_ use deno to
| teach js /ts. I would _absolutely_ use deno in a hobby
| project. I would _absolutely_ use deno if my requirements
| were such that I wanted to minimize js dependencies.
| nobleach wrote:
| I use when doing DSA/Algorithmic puzzle solving. I
| typically would use Java for such a thing. TS is pretty
| nice and when I don't need dependencies.... deno is a nice
| Typescript first language/runtime/env.
| simonw wrote:
| It's always worth reading the Deno release notes even if you're
| not using Deno because it's such a fascinating collection of
| interesting ideas.
|
| I always learn something new from them.
|
| In this case it was the existence of the URLPattern web API:
| https://pr8734.content.dev.mdn.mozit.cloud/en-US/docs/Web/AP...
|
| Also that Mutual TLS is an alternative term for client
| authentication.
| sqs wrote:
| I tried out Deno last weekend for a fun little hack project
| (syncing a local Markdown file to a formatted Google Doc), and it
| was awesome.
|
| Writing TypeScript code for Deno feels a lot like writing Go
| (which is a very good thing to me):
|
| - opinionated build/fmt/deps
|
| - well-designed stdlib
|
| - no need for scaffolding files (.eslintrc, babel.config.js,
| jest.config.js, mocha.opts, etc.)
|
| If that sounds good to you, try Deno!
| NotAnOtter wrote:
| Checking Deno out for my next project. I'm a recent typescript
| convert after working on a full JS team.
|
| The types feel soooooo good.
| geon wrote:
| Is it fast to start up? I have been using node with ts-node,
| and it takes a couple of seconds before it can start executing
| the actual code.
| chaosharmonic wrote:
| It's also _great_ for scaffolding CRUD sites. I used it a while
| ago on a MERN stack project in order to loop over a directory
| of game files -- Stepmania simfiles if anyone 's wondering --
| cleaning them up, parsing their metadata, and then POSTing it
| to my Express server. While I didn't avail myself of its
| CSV/YAML/etc parsing (JSON was a builtin and is now a third-
| party library), the stdlib's walk function made this generally
| painless.
|
| And to top it off there's yet another bonus to this approach:
| having Fetch included out of the box enabled me to mock out
| what eventually became my frontend requests, by running them
| headlessly and worrying about the form logic later.
|
| I haven't actually gotten to using TypeScript with it
| personally (it's among a _few_ things built into Deno that I
| 've been meaning to try now that I can run them with zero
| config), but when writing JS I've found myself reaching for it
| in some of the same scenarios I (anecdotally) see people point
| to for Python -- bulk file manipulation, scraping, programmatic
| requests, etc.
| mritchie712 wrote:
| mind sharing that project? I have a similar need.
| kbenson wrote:
| I also tried it out recently, because I wanted to make a small
| utility for myself and liked the idea of it providing a single
| executable (and bypassing the node/NPM ecosystem for learning a
| JS/TS based system appealed to me). It delivered on that
| beautifully, as all I did is switch from running "deno run" as
| I was for testing to "deno compile" and it delivered to me
| exactly what I was looking for. A bit large at 57 MB but that's
| not too bad for a fully bundled JS runtime and no library
| dependencies except glibc that I could see.
|
| As someone that's barely touched node for dev and always been
| put off by NPM and how that works (and the heavy build chain
| for some stuff), I find it much more palatable.
| Bilal_io wrote:
| That's interesting.
|
| 57mb is big, but not an issue when it's for personal use.
|
| Somewhat related, I haven't used rust, but I read that it can
| produce an executable including the run time for edge that is
| less than 1mb,. I couldn't find the source, but this article
| shares how an extension was reduced from 12mb to 4.5mb.
| kbenson wrote:
| > 57mb is big
|
| Honestly, I think most the time you're looking at 10MB+ for
| interpreted languages that are turned into executables
| (through a bundling of the runtime and scripts, that is,
| not through compiling to something else which is likely
| much smaller if offered).
|
| The complexity and size of the runtime is going to
| necessarily influence that size. V8 is fairly complex
| compared to most runtimes I think, with the JVM and maybe
| Mono being notable exceptions, and if you were to bundle
| the JVM with an app instead of just expecting them to have
| it installed, I imagine that would be quite large as well.
|
| > Somewhat related, I haven't used rust, but I read that it
| can produce an executable including
|
| That's actually the other thing I wanted to do with the
| project I built in Deno. Since it was _very_ simple, but
| actually useful for me, I was also going to implement it in
| Rust. I 've played with it a few times over the years, but
| never really had anything real that needed to be built in
| it, so this seemed like a good chance to build something
| real in it.
|
| In case anyone is wondering because I mentioned it twice,
| the project is just reading an ini file which defines
| browsers, pattern matches to apply to URLs to determine
| which browser to load based on the URL, and a default
| browser. The idea being that I can send work URLs to the
| browser I dedicate to work that's proxied through a SOCKS
| connection, and other URLs get handled automatically by the
| browser I use for personal stuff, and I can just make the
| application my default URL handler. Dead simple, but very
| useful for my current workflow.
| nicoburns wrote:
| If you happen to be on mac, there's an app called finicky
| that does this. It can also pattern match on source
| application which is pretty handy.
| kbenson wrote:
| I'm not, but that's nice. Pattern matching on the source
| application is actually what I would have preferred (and
| what I kept looking to see if anything on Windows could
| provide), but never found anything. Matching on the URL
| actually works well enough though, which I know because
| my _prior_ workflow was just a work container tab in
| Firefox with the Container Proxy extension to proxy only
| those tabs in that container, and work URLs were set to
| prefer that Firefox container.
|
| I was actually fairly happy with that, but it's nice to
| just be able to close the chrome instance with all the
| work tabs at the end of the day and have them all reopen
| when I start it up the next day, and all my work tabs are
| self contained and proxied through work. The only
| downside is I can't just click to open in Teams or
| Outlook, and need to copy the link and manually open it
| in Chrome, which is what I was aiming to fix.
| password4321 wrote:
| barely related:
|
| https://github.com/da2x/EdgeDeflector
|
| https://gist.github.com/GeeLaw/782d1ff3cf4f990c61ba1cc20d
| df4...
| kbenson wrote:
| Much appreciated! The first looks to be an example of how
| to register the handler through an installer, instead of
| the registry hack I'm doing (since MS only wants things
| actually installed and visible in Add/Remove programs to
| be protocol handlers, for obvious reasons, even if
| annoying), and the second isn't barely related, it's
| looks to be essentially the same thing but in C. Here's
| mine for comparison:
| https://github.com/kbenson/urlswitcher-deno
| Bilal_io wrote:
| Forgot the link
| https://arusahni.net/blog/2020/03/optimizing-rust-binary-
| siz...
| benatkin wrote:
| Deno is awesome, and it's great to see the WebCrypto additions!
|
| My current top feature request is that I wish Deno would have the
| same permission model for the repl.
|
| I highly recommend listening to this recent podcast with Ryan
| Dahl: https://changelog.com/podcast/443
| justshowpost wrote:
| That would make REPL difficult to use, since you would need to
| know in advance what you want to do to pass the right
| permission flags.
|
| REPL is particularly useful when trying out things "live" as
| they come into your mind.
| benatkin wrote:
| A common use case for a repl is to copy and paste code into
| it, or to give code to someone and have them run it. It's
| nice to not have to think about what the code could do to the
| system before running it.
| e12e wrote:
| Looks good. Interesting that they are "bringing back" mutual tls
| (after browsers pretty much axed it..).
|
| Is there support on the (deno http) server-side too? Eg: easy to
| set up mutually trusted, private-/non-ca tls between a deno
| client and deno server? Perhaps via a self-signed/private CA?
| lucacasonato wrote:
| The server does not support mutual TLS as of yet. Feel free to
| open an issue on denoland/deno though, so we can look into this
| :-)
| qsort wrote:
| Only tangentially related, but what's the point of a static class
| block? What problem does it solve that's not covered by either
| the class constructor or a static const? Doesn't it introduce a
| weird (stateful!) computation that's hard to reason about?
|
| There's probably a use-case I'm missing, because intuitively I'd
| automatically classify it as bad a practice.
| jarvuschris wrote:
| You can use it to load or compute derivatives of environmental
| configuration once
| WorldMaker wrote:
| Another perspective on static blocks is what they replace/help
| migrate away from. Static blocks are one of the last pieces of
| the puzzle holding some projects (or at least some particularly
| old legacy objects in those projects) from migrating to the new
| class syntax. For better or worse the classic Constructor
| Function pattern of building objects in JS was full of static
| initialization code (as it was an easy thing to do in that
| pattern). Static blocks bring back a way to do that in class
| syntax while adopting the better scoping rules of class syntax,
| helping more projects move away from Constructor Functions to
| class syntax.
| qsort wrote:
| Yeah, this makes a lot of sense. ES6 classes are restrictive
| if you look at them from a pre-ES6 perspective. Of course
| many of those restrictions are "right", but they are
| restrictions nonetheless.
|
| I guess it's a good way to bring back that behavior with the
| added bonus of being useful by itself in some limited but
| legitimate cases (sibiling comment mentioned cache
| initialization, also a good point).
| crabmusket wrote:
| It might be helpful if you have a "registry" of classes. The
| classes can self-register statically, rather than you having to
| add separate code which registers the just-declared class.
|
| It seems like a minor convenience, but it might play well with
| inheritance or mixin classes?
| iddan wrote:
| Modifying class static private properties
| officialchicken wrote:
| Off the top of my head it's probably useful for implementing
| The Singleton Pattern, which reduces to one single instance of
| a class: https://en.wikipedia.org/wiki/Singleton_pattern
| gavinray wrote:
| Singletons in JS/TS are done by creating and exporting an
| instance of a class: class MyClass {}
| export const myClassSingleton = new MyClass()
|
| Static initialization blocks = "Constructors, for static
| class members/values"
|
| Static blocks only run once, like the class declaration
| itself: class User {
| constructor(public name: string, public age: number) {}
| static { console.log("Hello from class User static
| block") } } const a = new User("a",
| 1) const b = new User("b", 2)
|
| Is transpiled to: class User {
| constructor(name, age) { this.name = name;
| this.age = age; } } (() => {
| console.log("Hello from class User static block");
| })(); const a = new User("a", 1); const b = new
| User("b", 2);
| officialchicken wrote:
| That's pretty close, but you need to add the protections
| around Object.keys(...) with guards in the getters and
| setters when using JS/TS. Sealing the entire class static
| should prevent the need and ability to edit that way.
| diatone wrote:
| > Doesn't it introduce a weird (stateful!) computation that's
| hard to reason about?
|
| Yes and no. For example, maybe you want to initialise a
| temporary directory on the filesystem for writing files to, for
| some caching mechanism. The pointer to the cache directory
| (maybe a const x = {}) can exist anywhere, but spinning up the
| directory itself in the static class block ensures that it's
| set up once and only once for all instances of the class. So,
| any instances get to reuse the directory without worrying about
| checking for initialisation first.
|
| Just another tool in the toolbox, best evaluated on a case-by-
| case basis
| IshKebab wrote:
| That's a pretty terrible example. No way do you want
| temporary directories to be created just by loading a class.
| That violates all sorts of best practices.
|
| There's a better example here: https://v8.dev/features/class-
| static-initializer-blocks
|
| You could also use it for initialising generated constants.
| ricardobeat wrote:
| What's the difference from declaring the entropy pool in
| the example outside the class, in the module scope? Still
| private, still a single shared value.
| ravenstine wrote:
| Funny, I was just looking into whether I could add a Deno config
| file to my project. Nice to know this was just made possible!
| maga wrote:
| Can you share a bit on the use case, i.e. what do you need
| configured?
|
| Personally, I find Deno's "zero config" approach appealing,
| although I do have to fight the linter's "ban-types" rule
| occasionally since suggested type replacements are not
| equivalent.
| lucacasonato wrote:
| Please open an issue on denoland/deno_lint with examples so
| we can make the diagnostic messages more useful.
| maga wrote:
| Thanks, I usually do, but in this case they are typescript
| issues and have tickets in the ts repo.
|
| For example, constructor signature for mixins requires
| `any` type that conflicts with `no-explicit-any` rule. In
| another case, `object` cannot be replaced with
| `Record<string, unknown>` when used with conditional types
| to mean "any non-primitive value".
| IggleSniggle wrote:
| This comment right here is enough for me to become
| suddenly much less keen on Deno.
|
| If you're somebody who wants to make their ts as close to
| provable as possible, but also be able to handle dynamic
| / generative content, then you run into issues of this
| nature all the time with (for example) linter settings
| that think they know typescript better than you do, but
| fail to recognize that there is literally no other way to
| express some type-concept in typescript without using a
| larger feature set.
| maga wrote:
| I agree wholeheartedly with the argument: tools getting
| in a way is the ultimate annoyance; in fact, struggling
| to force Jest to play nicely with ESM modules and
| TypeScript was the final straw that pushed me towards
| Deno for library development.
|
| However, the argument can be made against any tool, and
| I'd say Deno here is the least deserving: in most cases
| it has just adopted the "defaults" set by tsc, eslint, or
| prettier, and just like them it allows ignoring these
| rules where necessary.
|
| That said, I also think Deno made the right choice by
| enforcing these by default. Hopefully, it will fight the
| tide of low-quality code that plagues NPM. I do have to
| wrestle the linter, but it's mostly because I'm writing
| libraries that by themselves are pushing the limits of
| the TS type system, e.g. in structurae[1] I make an
| extensive use of mixins extending built-in objects, and
| mixin support is still nascent in TS. This is far less
| common in day-to-day production code, where, for example,
| using `any` or `object` is more often a sign of sloppy
| thinking rather than a necessity.
|
| [1] https://github.com/zandaqo/structurae
| lucacasonato wrote:
| // deno-lint-ignore no-explicit-any
| lenkite wrote:
| You can use Deno without TS. I use it with plain JS and
| the code/test cycle is much faster without typescript
| compilation. Basically prefer Deno for ES6 modules and
| the good standard library.
| ravenstine wrote:
| > Personally, I find Deno's "zero config" approach appealing,
| although I do have to fight the linter's "ban-types" rule
| occasionally since suggested type replacements are not
| equivalent.
|
| Precisely this. I'm compiling TS using `Deno.emit()`, which
| can be directly configured, but it would be nice to just
| configure Deno's linting/compiling behavior at the project
| level so that the same issues don't appear in VS Code with
| the Deno extension.
| nexuist wrote:
| Does anyone know if Deno has undergone a security audit yet? I'm
| interested in using it as a sandbox to run user-submitted JS, and
| I know its permission model is powerful, but I don't know if it
| is formally certified (if that's even a thing) and if you can
| prove that there can't be some exploit that can be used to break
| out of the sandbox.
| ricardobeat wrote:
| If you're thinking of V8 isolates, I believe Cloudflare was
| running their edge compute product using that.
| scns wrote:
| Has Node undergone such scrutiny? Honest question.
| mastrsushi wrote:
| Why'd they have to give a JS environment the name of a guido.
| aikah wrote:
| Love Deno and using it as a node replacement. Fantastic work. I
| encourage anybody who has npm packages to move everything to
| deno.
| yawaworht1978 wrote:
| I have 2 projects all in node, using express. Is there an easy
| way to migrate it? What happens to all the imported modules and
| dependencies? Can I still use express in Deno the same way?
| lytedev wrote:
| Probably not, but Deno has Oak, which is Express-like and the
| combination of those two will get you close. But most node
| libs are not compatible and similarly node projects.
| kreetx wrote:
| Isn't there a compatibility layer available, or are there
| reasons that in principle make this impossible?
| afiori wrote:
| There is a compatibility layer but it is not complete.
|
| One of Deno's objectives is not to expose V8 internals,
| so node packages relying on those will be harder to port
| oauea wrote:
| Who doesn't love being removed even further from the
| platform they're running on?
| WorldMaker wrote:
| Deno is striving for more unified APIs with browsers, so
| while they are moving away from the "platform" of
| internal use only V8 APIs, they are moving _toward_ the
| "web platform", which seems an admirable goal to me. One
| of my biggest complaints for a while has been how
| drastically different some Node APIs are from the way any
| actual "web platform" APIs work in 2021 (Promises for
| filesystem APIs in Node are still "experimental", and
| meanwhile there's an actual filesystem API standardized
| in the "web platform" that is entirely incompatible but
| Promise-based). You can polyfill some of the "web
| platform" libraries back on top of Node in many cases,
| but Deno seems sensible to me in trying to better unify
| such things from the start.
| dgb23 wrote:
| One of Deno's value props is to have a tighter and more
| explicit trust model.
|
| And this is not a obscure need. There are cloud providers
| who let you run JS on a specialized and restricted API.
|
| However, there is nothing stopping you from using Node or
| integrating V8 and go wild with it! (In fact I would
| argue that this is a solid strategy for some types of
| projects, where you can get the best of both
| (static/dynamic) worlds.
| oauea wrote:
| > And this is not a obscure need. There are cloud
| providers who let you run JS on a specialized and
| restricted API.
|
| Sounds rather obscure actually. Still somewhat confused
| why this would be useful in Deno. Looks like it's just a
| repeat of what happened with Java's SecurityManager,
| which is now being deprecated and removed.
| yawaworht1978 wrote:
| Thanks for that,Oh dear, I was secretly hoping for
| something as easy as a new package.json. A quick look
| around, I found this: Opine attempts to solve this by
| completely porting ExpressJS over to TypeScript in Deno,
| making changes only where the Deno APIs dramatically differ
| from Node.
|
| Will give it a try, really curious how importing works and
| all.
| kbenson wrote:
| > really curious how importing works and all.
|
| So was I, so this is what I determined, on top of the
| official docs.[1]
|
| On deno run of a script, it will download referenced
| imports and put them into a cache directory with a hash
| of the name. On a UNIX-like, this seems to be in
| ~/.cache/deno/deps (there's also a ~/.cache/deno/gen for
| the TS to JS stuff). Subsequent runs do not seem to
| download the scripts, but instead use the cached hashed
| versions. There's probably a way to blow out or overwrite
| the cache with newer download with a deno command, but
| I'm not sure what it is.
|
| Compiling bundled the cached dependencies, so they aren't
| downloaded on run. Importing from local files is also
| possible, as noted in the docs I linked.
|
| I'm happy to be corrected to supplemented on any of that
| info, I would rather know the actual way it works than
| persist in a slightly wrong assumption. :)
|
| 1:
| https://deno.land/manual@v1.11.5/examples/import_export
| andrew_ wrote:
| "Easy" is highly subjective. If you're proficient at picking
| up new architecture paradigms for familiar languages, you're
| adept with ESM syntax, and refactoring is a skill; then you
| might consider it easy.
|
| It's a paradigm shift, so there's always going to be some
| friction in migration. For your express needs, check out Oak
| https://deno.land/x/oak@v9.0.0
| kroltan wrote:
| Could you clarify what is the paradigm shift? Static types?
| (If so I agree, but using Node does not imply not using TS)
| yawaworht1978 wrote:
| This is my first day obviously, but what I can see are
| the following interesting syntax, bare server.
| const server = Deno.listen({ port: 8080 });
| console.log(`HTTP webserver running. Access it at:
| http://localhost:8080/`); // Connections to
| the server will be yielded up as an async iterable.
| for await (const conn of server) { // In order
| to not be blocking, we need to handle each connection
| individually // without awaiting the
| function serveHttp(conn);
|
| } async function serveHttp(conn:
| Deno.Conn) { // This "upgrades" a network
| connection into an HTTP connection. const
| httpConn = Deno.serveHttp(conn); // Each
| request sent over the HTTP connection will be yielded as
| an async // iterator from the HTTP connection.
| for await (const requestEvent of httpConn) {
| // The native HTTP server uses the web standard `Request`
| and `Response` // objects. const body
| = `Your user-agent
| is:\n\n${requestEvent.request.headers.get(
| "user-agent", ) ?? "Unknown"}`; // The
| requestEvent's `.respondWith()` method is how we send the
| response // back to the client.
| requestEvent.respondWith( new Response(body, {
| status: 200, }), ); }
|
| }
|
| Everything async await. There is an option to use a
| library, but it's to be deprecated,the native option is
| stable. Interesting import code: import
| { serve } from
| "https://deno.land/std@0.105.0/http/server.ts";
|
| So, Deno supports typescript out of the box or just plain
| JS. Deno doesn't support npm packages, imports are done
| via url. There is a window object, for whatever that's
| supposed to be used. Runs sandboxed, access to filesystem
| etc runs on permission basis. Access to the browser API
| without installing anything else. Packages are cached,
| this was very annoying in nodeJS.
|
| Sounds and looks pretty damn good.
| andrew_ wrote:
| package management, scripts are quite the shift in Deno.
| there are tools like velociraptor and trex which help
| bridge the gap, but there's still a lot to learn that's
| much different than node-world.
| e12e wrote:
| Probably more the removal of nodejs apis in favour of
| browser apis. For everything. (modules/imports included).
| brundolf wrote:
| I wouldn't call it a paradigm shift in terms of the code
| itself. The main thing is that it's a completely different
| set of system APIs that have to be targeted (by you or by
| the libraries you use). That means a lot of changes
| wherever those are involved, but they should mostly be
| straightforward changes (of course YMMV if you're having to
| use a new library/framework instead of just the new system
| APIs)
| Zababa wrote:
| I know it's a bit superficial, but I love Deno's branding. Their
| logo is cute and evokes a sense of calm, and the variations on
| the mascot are nice.
| a5aAqU wrote:
| > This release allows deno lint and deno fmt to be configured.
|
| That's good news. The main thing holding me back from seriously
| looking at Deno was the lack of config for the formatting. The
| default settings weren't right for me, and I tend to avoid
| projects where you have to fight the tools. I'm going to take
| another look now.
___________________________________________________________________
(page generated 2021-09-16 23:02 UTC)