[HN Gopher] Deno 1.9
___________________________________________________________________
Deno 1.9
Author : searchableguy
Score : 645 points
Date : 2021-04-13 19:14 UTC (1 days 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.
| brunoluiz wrote:
| With HTTP 2 implemented in this version, gRPC might be possible
| in a near future.
| pietroppeter wrote:
| Just realized that de-no is reverse of no-de
| rvieira wrote:
| Actually, it's not :)
|
| According to the official Deno releases it's:
|
| "node".split("").sort().join("")
|
| Which makes the pun even wittier.
| raulytpro wrote:
| I just created this account because I made the exact same
| comment 54 minutes ago to my co-worker and he was seeing this
| post. Mate, maybe we're linked souls or smth like that, what do
| you think? Could it be possible?
| HatchedLake721 wrote:
| No
| 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.
| smt1 wrote:
| s/Node.js/perl
|
| Don't worry, we've all been there.
| 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.
| de6u99er wrote:
| Having read multiple comments Deno looks to me like somethung I
| want to get into.
|
| Is there somewhere a getting started with Deno guide, tackling
| setup of a d velopment environment and some typical use cases as
| examples?
|
| How would e.g. a company like CloudFlare run Deno instead of v8
| for it's serverless infrastructure?
| searchableguy wrote:
| > How would e.g. a company like CloudFlare run Deno instead of
| v8 for it's serverless infrastructure?
|
| Raptor is an example project which does that:
| https://github.com/littledivy/raptor
|
| deno_runtime crate provides high level abstractions which you
| can use to execute code for deno. It is used in the cli. You
| would still need to bring in your own transpiling layer for
| typescript support.
|
| As for getting started, you can go through the manual:
| https://deno.land/manual
| da39a3ee wrote:
| Are you a computer program? Your third sentence is much more
| sophisticated than your first two; they don't seem to have been
| written by the same human. And the two typos look somewhat
| inauthentic.
| eloff wrote:
| > How would e.g. a company like CloudFlare run Deno instead of
| v8 for it's serverless infrastructure?
|
| They're both built on v8.
| [deleted]
| mekster wrote:
| What are the conditions for people feel the urge to migrate over
| to deno?
|
| Currently, I don't see enough reasons to switch to deno for
| primary projects.
| fctorial wrote:
| Does the single executable distribution change anything?
| node/python/google-chrome are all single executable programs as
| far as the users are concerned.
| phplovesong wrote:
| Deno is a single executable as in you only download one file.
| Compared to a new python install, it needs all kinds of
| additional stuff to get up and running.
| herodoturtle wrote:
| On the deno.com homepage, if you click on CLI it takes you to
| https://deno.land/
|
| If you then scroll to the bottom, the deno tag say "failing".
|
| Just thought I'd share (in case the right people happen to read
| this).
| 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.
| beaker52 wrote:
| If you want to do this with node, pkg exists.
|
| https://github.com/vercel/pkg
| tarruda wrote:
| > So how does Deno fit in and what is the added value?
|
| I also had that question in my mind until I tried deno a couple
| of weeks ago. There are a few great things I've discovered that
| IMO makes it a great alternative to node.js:
|
| - Deno + std library has a lot of batteries included. Have you
| tried creating a web browser project with node.js recently?
| Just adding a few basic dependecies to compile and bundle your
| code will leave you with node_modules having hundreds of other
| dependencies. With recent cases of malware slipping into npm
| dependencies tree, I'm a bit fearful of starting a new project
| and infecting my computer (not too crazy imagining that one of
| the developers of those hundreds of deps will be careless with
| their SSH keys). "deno bundle" basically solves that for me.
|
| - I can't think of a reason why I would not use typescript
| these days. Not having to install tsc or create a tsconfig.json
| is a killer feature for me. Not to mention compiling ts with
| Deno feels really fast (maybe because they don't have to load
| the whole typescript compiler into the JS VM on every run?).
|
| - As a consequence of Deno's fast startup + tsc support + great
| standard library + automatic dependency download, I've found a
| vastly superior alternative to python for writing quick and
| dirty scripts for automating various tasks. So for me Deno is
| not just for writing servers, it is also for using typescript
| as a script language for automating my desktop and server
| workflows.
|
| These are just a few things that stand out for me, there's
| certainty more to Deno than it may initially appear.
| kaba0 wrote:
| Similarly, how does both Node.js and Deno compare to GraalJS?
| I've been reading about it and find the idea absolutely genius,
| but I'm sure it doesn't have nearly as much of a userbase as
| these.
| 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.
| croes wrote:
| It's main selling point is security. With Deno you can provide
| permission to scripts using flags. Deno offers a sandbox
| security layer through permissions. List of the flags:
|
| --allow-env allow environment access.
|
| --allow-hrtime allow high resolution time measurement.
|
| --allow-net=<allow-net> allow network access.
|
| --allow-plugin allow loading plugins.
|
| --allow-read=<allow-read> allow file system read access.
|
| --allow-run allow running subprocesses.
|
| --allow-write=<allow-write> allow file system write access.
|
| --allow-all allow all permissions (same as -A)
| kybernetikos wrote:
| What I dislike is that you provide these permissions for the
| whole process. I'd like it to be more that you can constrain
| and pass the permissions down to libraries like capabilities.
| beaker52 wrote:
| I agree. I hear a lot made of Deno's "security" but process
| flags don't really make me feel much more secure when I've
| had to enable most of them anyway. At that point they just
| start getting in the way and giving me a false sense of
| security.
| 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.
| anthonygore wrote:
| I made a video on Deno which gives a quick summary of its key
| features:
|
| https://devtrends.io/videos/deno
| 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.
| oscargrouch wrote:
| > Deno glue code around V8 is written in Rust.
|
| The C++ V8 api is very reasonable to be used in a safe way.
| So i dont see this as a good point unless of course for
| people that wan to write some parts that need to be optimized
| in Rust.
|
| Don't deal with NodeJs that much, but is a lot of node
| functionality in C++ modules? and if so they are presenting a
| lot of security bugs in a way that Rust might see appealing?
|
| Because by not having direct access to the V8 api in its
| native language might limit you, the "glue coder", in the
| things you really can do.
| tym0 wrote:
| > Deno glue code around V8 is written in Rust.
|
| Maybe this is not the best way of putting it. They use Rust
| for all the system bits including networking, so it's not
| like they just wrote some JS to V8/C++ glue code in Rust.
| oscargrouch wrote:
| Ok, but even if there's more Rust code in it, i think the
| expectations of the parent poster are unreal, as for
| safety, only if V8 VM were rewritten in Rust, and giving
| its a JIT VM sensitive portions of code would need to be
| in 'unsafe{}' anyway, so how much safer would it turn out
| to be even than?
|
| Anyway in security terms it will probably turn out
| negligible as the percentage of code in safe Rust are
| probably low compared to the whole thing.
|
| Than in memory usage, if it replicates Eletron,it would
| turned out almost the same, giving is not the C++ core
| the one that is most memory hungry.. is mostly the
| renderer process with WebKit and V8 executing big
| portions of javascript code in memory.
|
| Giving if such a branch existed, it would use typescript
| which in turn is the same V8/javascript pipeline that is
| memory hungry.
|
| So, addressing to the parent poster, i don't think it
| would change much in terms of security or memory pressure
| if compared to Electron.
|
| Sometimes i think Rust give some people high
| expectations, that it would be very hard to actually
| replicate in real life experiences, giving software is
| much more complex and as in Deno, requires other core
| parts that cannot be realistically rewritten in Rust, and
| even if they could, while we can see how software written
| in Rust can be safer, it still needs to prove the claim
| for bigger, sensitive pieces of software that requires a
| lot of "unsafe" techniques to work like JIT's and OS's
| and therefore might not feel that much of a difference
| giving the size and complexity of the project.
| 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?
| EugeneOZ wrote:
| > Therefore we have employed Hyper to build a new native HTTP/2
| server API in Deno.
|
| > The binding improves hello-world throughput by 48% when
| compared to the std/http pure TypeScript HTTP server.
|
| Nice to read it about Hyper - one of my favorite Rust tools!
| devgoldm wrote:
| As a primarily C++ dev who's been using nodejs on the side for
| about a couple years now - so forgive me if this is naive - but
| am I wrong in seeing Deno as a potential Electron replacement
| with standalone binary builds + webview?
|
| If so, the introduction of interactive permission prompts is
| pretty cool.
|
| I see a few comments from more experienced web developers that
| are quite negative about Deno that seem to generally be centred
| around the fact it offers very little compared to nodejs, and
| isn't worth the effort to learn.
|
| Does it have potential as a safer, lightweight Electron
| alternative? Or are there better options than Deno in that
| regard?
| oscargrouch wrote:
| > Does it have potential as a safer, lightweight Electron
| alternative? Or are there better options than Deno in that
| regard?
|
| If they target this, the big chunk of code will still be the
| same ones on Electron, so i don't think it would get to be
| safer or lightweight as compared to Electron.
| tambourine_man wrote:
| I think it's not its main goal right now, but it could be and
| would be really interesting if it happened.
| rektide wrote:
| there's webgl, webgpu, and dom, but it's a headless dom (jsdom)
| not a webview.
|
| I wouldn't be surprised to see packages developed for a webview
| but atm demo seems to target server side web platform
| compatibility... except rendering html!
|
| I wouldn't be surprised to see some packages try to fill the
| gap, & deno has a much stronger basis for implementation than
| node (a rpc layer between rust & v8 defines the core character
| of the project, and an native addon that adds webview methods
| to the rpc would be natural in Deno, vs a hack in electron).
| searchableguy wrote:
| The most updated webview bindings I know of for deno:
| https://github.com/webview/webview_deno
|
| It's likely you will find some hiccups in latest deno release
| because it uses rust plug-ins and they are getting overhauled
| at the moment. Maybe a few more months before getting
| stabilized.
| jshawl wrote:
| I wish deno files had a different file extension. Editor gets
| confused often switching between front end typescript and deno
| typescript.
| Soremwar wrote:
| For frontend TypeScript I assume you mean TypeScript that
| doesn't use JS modules but extensionless modules, the
| TypeScript folks sadly have decided to not bring compatibility
| here ATM.
| 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?
| mark_and_sweep wrote:
| I believe so. Recently Deno started running a subset of
| the Web Platform Tests to test compatibility.
|
| See:
| https://deno.land/manual/contributing/web_platform_tests
| 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.
| jonny_eh wrote:
| Node introduced the "global" object instead of using the
| existing "window" object the pre-existed in all browsers.
| sdfin wrote:
| At least whe have "globalThis" now.
| IggleSniggle wrote:
| I think that depends on how much deno commits to
| following the web APIs with each release.
|
| Actually, nodejs has really done a lot of catching up
| with deno in this regard. It just has to support both the
| "legacy" way and the "forward looking" way where deno
| does not.
| rektide wrote:
| node actually invented a lot of wheels. node was first
| with promises (a couple major iterations!), streams, uhh
| I dunno what else. file access (we're just getting that
| now in the browser after some old ill supported early
| attempts). modules.
|
| the web reinvented many of these wheels.
| eyelidlessness wrote:
| Node didn't introduce the Promise API. Although it
| definitely instigated it. Node, with its async IO model,
| was just littered with callbacks. There were a zillion
| different approaches to async APIs that could ease that.
| Promises were, well, the most promising. But years of
| iteration and competing standards came and went before
| Node adopted them as the preferred API. And they did so
| right along with browser vendors and web standardization
| bodies.
| rektide wrote:
| I was referring to node <0.1.30[1] which did have
| promises for a while. largely from jQuery deferred, which
| were ungood in a couple ways I don't remember. but also
| remarkably similar.
|
| I still largely think kris kowal building the "Q" promise
| library is what made promises interesting, what surfaced
| the idea that we might want to first-class our
| completeablea/futures. I know kris had some specific
| inspirations but I forget what.
|
| pains me somewhat to this day that promises ultimately
| became somewhat un-value like, that handlers don't get to
| see what it was resolving. all the chain/spawn
| discussion, the functional promise folk: they got rolled
| by those insisting we had to target only the lowest rings
| of the developership, and that allowing more potent
| systems was unacceptable. wish I could find those es-
| discusa threads, for the powerful sorrow of the afteath,
| what we are stuck with, in it's so lites form, haunts me.
| especially as we double back a decade latter & invent
| controllers & signals toanage our promises. which we
| would have had for free.
|
| way off topic now. forgive me my late night ramblings.
|
| [1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1
| .30/Cha...
| 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...
| bavell wrote:
| Not originally though: https://nodejs.org/dist/latest-v10
| .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.
| girvo wrote:
| Part of me almost misses `browserify` -- the heady days of
| "Node modules are the One True Way", with all the
| constraints that implied. Got a lot done with it and
| related tooling back then!
| brundolf wrote:
| CommonJS worked well enough for lots of things, and it
| was neat that it was so simple (no new syntax!)
|
| But it had limitations, chiefly that imports/exports were
| not static. Things got imported at runtime when they got
| reached, etc. This meant that things like browserify were
| fudging the semantics in some ways, and it also made it
| impossible to properly do tree-shaking. The stricter
| semantics of ES modules are better IMO, despite the pain
| of transitioning.
| 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.
| eyelidlessness wrote:
| Overall this is true. And beyond that the TypeScript team
| is heavily involved in TC39, and quite a lot of TC39
| proposals are specifically designed to be enhanced by TS.
| That said...
|
| There are a few longstanding incompatibilities/footguns.
| And they're likely to remain due to widespread use, even
| though most are controversial. Off the top of my head:
|
| - access control annotations (`private` which is compile
| time only vs `#`). I'm on the fence on this one. I prefer
| the TS syntax, but obviously not the behavior.
|
| - Enums. Everyone but me hates them. I use them extensively
| for personal/internal use but try not to force them on
| others.
|
| - Decorators. This is the big bad ticking time bomb. Last I
| checked the TC39 proposal has diverged significantly from
| the TS implementation. And sure it's marked "experimental"
| but it's used _a lot_ and almost guaranteed to be a future
| conflict. Putting that toothpaste back in the tube is gonna
| make a lot of people feel a lot of pain.
| barry27 wrote:
| Enums are cool. Mixins, though, are rubbish. Everyone but
| me loves them, though. They should have done traits, like
| Scala. Scala is awesome.
| folkrav wrote:
| > enums [...] everybody but me hates them
|
| Hmm, what did I miss, why do people hate them exactly?
|
| > And sure it's marked "experimental" but it's used a lot
| and almost guaranteed to be a future conflict. Putting
| that toothpaste back in the tube is gonna make a lot of
| people feel a lot of pain.
|
| Maybe I'm a bit masochist, but I can't say I feel a lot
| of compassion for people using experimental features in
| missing-critical production code.
| tengbretson wrote:
| > Hmm, what did I miss, why do people hate them exactly?
|
| They operate in a weird gray-zone between being just
| compile-time types vs. an actual readonly object in the
| runtime. I don't think I've seen a use case for them yet
| that wouldn't have been better accomplished with a union
| type of string literals and using const string literals
| in the code.
| pierreyoda wrote:
| > Hmm, what did I miss, why do people hate them exactly?
|
| In my experience, enums are far less type safe and
| convenient (usage in switch for instance, combined with a
| linter) than union types.
| flyingchipmann wrote:
| The thing is enum and union type have different use
| cases. Union type cannot be used to check against
| incoming data. It's a lightweight type level feature.
| There is no way for compiler to identify the unknown data
| object from the network. Enum is essentially an object in
| memory which can be used in this case.
| lobstrosity420 wrote:
| >Maybe I'm a bit masochist, but I can't say I feel a lot
| of compassion for people using experimental features in
| missing-critical production code.
|
| To be fair, decorators are an experimental feature in
| name only at this point. A lot of libraries force you to
| use it, including Microsoft's own tsyringe and the beyond
| popular TypeORM. NestJS is a reasonably popular framework
| that will codegen services with decorators in them. As
| the OP of this thread said, the toothpaste is out of the
| tube now.
| lygaret wrote:
| the entire angular2+ ecosystem as well
| folkrav wrote:
| Fair point.
| 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
| dwaite wrote:
| There is a tremendous amount of overlap between the Web and
| Node API creators, but there has been push-back and slowness
| to adapt many of the Web APIs in Node by the same group. For
| example, the delays in adopting ECMAScript modules in node,
| or the lack of first-party API for fetch.
| 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
| eyelidlessness wrote:
| Their companion CDN (and namesake umbrella parent company)
| is also a first class part of Snowpack.
|
| _However_ using CDNs in the browser has some big trade
| offs. Besides obvious concerns sending any data to
| consolidated third parties, it's actually a performance
| detriment now that browsers are caching per origin.
|
| Used to be, using a CDN got you more likely cache hits and
| better perf on N+1 requests. Now you definitely don't get
| that plus you get the extra DNS lookup and whatever
| performance characteristics of that CDN.
| chris_engel wrote:
| There has always been an extra DNS lookup wirh a CDN.
| Thats even the point of the CDN since based on where you
| are, you will be served from a location as physically
| close to you as possible.
|
| Where did you get the information from that CDNs arent as
| good as they used to be?
| richeyryan wrote:
| Safari and Chrome now use a combined cache strategy using
| the URL of the resource and the top level domain of the
| site loading that resource as the cache key.
|
| For scenarios that were previously popular like using the
| jQuery CDN, you won't get the benefit of the user having
| jQuery in their cache from another website. You will
| however still get the proximity benefit you describe.
| CDNs are obviously still quite useful, just not for
| getting cache hits on popular libraries.
|
| https://www.stefanjudis.com/notes/say-goodbye-to-
| resource-ca...
| chris_engel wrote:
| Yeah thats true - so you explicitly mean CDNs that serve
| a single thing only.
|
| Using a CDN for your static files is just as fine as it
| always has been.
| [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.
| IggleSniggle wrote:
| Deno's import system is just the ecmascript import system.
| So, it works exactly the same way it does in the browser.
| Or with curl. Or whatever. You just supply a uri and get
| the resource at that location. Things like import maps are
| just a way to make that more convenient during development,
| but there's no secret system for pulling these pieces
| together; it's just the ecmascript module standard (that
| didn't exist until more recently).
| eyelidlessness wrote:
| Yes there are plugins for this in pretty much every build
| tool and for Node. But they all have a bunch of caveats and
| mutual discrepancies.
| 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.
| greenshackle2 wrote:
| Kind of a leap to go from not wanting to learn the JavaScript
| techology du jour to not wanting to learn anything.
| 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_.
| int_19h wrote:
| It's the most popular PL because it ships in every browser
| out there, and so you have to use it to do any front-end
| work. It doesn't really say anything about the quality of the
| language or its ecosystem.
| neximo64 wrote:
| I agree with you its quality but what i'm saying is that
| didn't matter.
|
| And to counter on the browser bit, Rust/Go/C/etc can be
| compiled into Webassembly and yet its not thriving.
| Similarly on the backends Javascript is thriving too.
| int_19h wrote:
| wasm is still a very niche thing in terms of scenarios
| that it can cover. Things will be very different once
| there's a full-fledged native wasm browser API that is at
| least equivalent in power to what JS gets today.
|
| On the backends, it seems that the only reason why JS
| even made a foothold there is because it was on the
| front-end first, and because it had its performance
| optimized there (V8 etc) first. Node specifically pitched
| "same language for both front-end and back-end" back in
| the day.
|
| JS is kind of like C - it just has an immense first mover
| advantage by now, to the point where it's very hard to
| move forward from it. I hope wasm will be the holy grail
| in that regard... eventually.
| 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.
| int_19h wrote:
| I would argue that much of the Node ecosystem suffers from
| the same flaw as "millions of apps" advertised by Apple and
| Google on their mobile platform: most of it is useless one-
| liners, or abandonware.
|
| Now, when you filter it all out, it's still not any worse
| than Python etc - but it's not any better, either.
| sintaxi wrote:
| Node wasn't about bringing JS to the server. The purpose of
| Node was to bring asynchronous I/O to the web - and it
| absolutely crushed it.
| 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)
| smt1 wrote:
| I'd say v8 being nicely engineered and happening to be a JS
| engine made it natural as well
| 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.
| jadbox wrote:
| I wonder what the general performance difference difference there
| is between the new Rust-based server and Express?
| 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
| Osiris wrote:
| If dependencies are imports from URLs, how does one audit their
| dependencies?
|
| If a server gets hacked those TS can be replaced with malicious
| versions.
|
| In npm we at least know that a package is immutable once
| published, someone could publish a malicious version as a newer
| release but a current release.
|
| Does demo generate some type of file that keeps a hash of all
| downloaded imports to verify against the next time those
| imports are downloaded?
| dkdbejwi383 wrote:
| > In npm we at least know that a package is immutable once
| published, someone could publish a malicious version as a
| newer release but a current release.
|
| This is only true as long as you trust NPM. If they were
| hacked or taken over by a malicious actor, packages could be
| modified unbeknownst to you.
| felixfbecker wrote:
| No they could not. Because your package-lock.json contains
| integrity hashes that are verified during installation.
| Soremwar wrote:
| Only if you update dependencies, a fresh install would
| not have such integrity checks, so it's just as
| vulnerable as Deno hosts to such attacks
| tlrobinson wrote:
| Integrity checking & lock files https://deno.land/manual@v1.9
| .0/linking_to_external_code/int...
|
| The same problem (and solution: package-lock.json or
| yarn.lock) exists in npm if you use semver version
| specifiers, or npm itself could be hacked, it's just a bit
| more acute in Deno since it's easy and common to load files
| from arbitrary hosts that don't enforce immutable versions.
| eevilspock wrote:
| You realize Deno is founded by Ryan Dahl, who founded Node 12
| years ago, don't you?
|
| Perhaps you should be less quick to label anything about it
| "asinine" or even "awful hack".
| zkldi wrote:
| I do! And I think node has a lot of flaws (Ryan seems to
| agree).
|
| I do not _understand_ why deno has gone for this route. It
| seems primed to produce a package manager eventually, and it
| seems like a bad idea to leave package manager creation down
| to whoever makes the first decent tool (which is mostly why
| npm is the standard for node.)
| Twixes wrote:
| With all respect to Ryan Dahl, I'm sure he'd disagree with
| the "asinine" characterization but would also disagree he's
| infallible - as evidenced by the creation of Deno after Node
| eevilspock wrote:
| I'm just saying _Don 't be so quick to judge. Be humble!_
|
| No one is infallible. That said, creating Deno after Node
| doesn't imply that Node was a fail or that Deno will be
| perfect. Obviously not.
|
| Consider that someone really smart _has reasons_ for doing
| (or trying to do) things a certain way. Be humble!
| goldenkey wrote:
| Node is a failure. It's standard library is written ad
| hoc. Riddled with catch 22s and monkey patches. The
| development style is just to bolt on more and more
| variables and branches, endlessly, without any cohesive
| style.
|
| Example of the "common caterpillar" genus of node quirks
| and the awful antagonistic responses by the dev team:
| https://github.com/nodejs/node/issues/25857
|
| Just take a look at a random stdlib source file: https://
| github.com/nodejs/node/blob/master/lib/readline.js
|
| ``` if (input && input.input) { // An options object was
| given output = input.output; completer = input.completer;
| terminal = input.terminal; history = input.history;
| historySize = input.historySize; signal = input.signal;
| ```
|
| It's junior-level code writing all over the project. That
| is a failure in my mind, especially when I know the
| library backing my project has to import all that junk
| hidden from view.
|
| See (wontfix) fs.promises.readFile is 40% slower than
| fs.readFile:
| https://news.ycombinator.com/item?id=26332774
|
| Not to mention the awkward political nature. There is a
| BLM banner on their front page: https://nodejs.org .The
| founder of BLM, Patrisse Cullors, just bought 4 mansions,
| the last for $1.4 Million USD:
| https://news.yahoo.com/blm-official-calls-investigation-
| foun...
|
| Node's dev team is not interesting in supporting the
| community. They are amateurs who are trying to be woke
| and add "top Node contributor" to their toolbelt of
| proverbial ego items. Prove me wrong.
| pests wrote:
| Most support BLM the concept, few know anything of BLM
| the organization.
| goldenkey wrote:
| The movement has been co-opted by opportunists just like
| Al Sharpton did 10 years ago.
|
| Police reform is an issue that everyone can get behind.
| But it's not as catchy and divisive.
| 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.
| anderskaseorg wrote:
| The problem the deps.ts pattern solves is that your project
| has several dozen modules that all import a particular
| version of a dependency, and now you need to update them all
| to a new version of that dependency.
|
| (If your project only has one module, then you don't have
| this problem and don't need this solution.)
| smallnamespace wrote:
| Why not just use sed?
| systemvoltage wrote:
| Why bother with DRY at all? Just sed all day to replace
| 24 instances of function foo().
| smallnamespace wrote:
| Indeed, DRY is overrated, especially for trivial things
| like string constants.
| goldenkey wrote:
| How is DRY overrated? Making edits to a codebase
| shouldn't require any more tools than a text editor. I
| wouldn't want to live in a house that required powertools
| for every minor repair, it would be burdensome and
| indicate poor development practices.
| smallnamespace wrote:
| Are you using a text editor that can't index your repo
| and do search-replace within? Vim and emacs both do this
| easily.
|
| If you're not using an IDE, have you considered that by
| DRY-ing up constants, you're adding about 2-3 steps to
| even see what the value of a constant is?
|
| Jump to the top of your file, figure out where the import
| is from, open the other file, then find constant name.
|
| You also force your code reviewers to do this in e.g.
| GitHub, where there's no convenient 'jump to definition'.
|
| IMHO, if your starting point is that you won't use sed,
| can't use a good IDE, and won't configure your editor
| nicely, then you're just creating a lot of unnecessary
| work for yourself, regardless of whether you're doing
| DRY.
|
| Power tools are appropriate if you're building a house.
| uli31 wrote:
| You're just going to wind up making changes where you
| don't need them that way. There's no guarantee that
| because the code looks the same it does the same. An IDE
| can't figure out what side-effects will happen.
|
| By just letting your IDE make changes globally, you're
| running the risk of introducing bugs. By DRYng up your
| code, you know that the change you make will have the
| same result everywhere.
| apatheticonion wrote:
| The issue is that JavaScript (by extension TypeScript) doesn't
| have the concept of folders.
|
| You can only import a single file per import statement.
|
| Developers create "barrel" files that allow them to re-export
| all of the important stuff in a folder externally. This allows
| for namespacing // foo/index.ts export *
| from './foobar' // main.ts import * as
| foo from './foo/index' new foo.Foobar()
|
| Or use destructured imports to help with static analysis tool
| that trace imports removing unused references from the final
| build // main.ts import { Foobar } from
| './foo/index'
|
| Node has non standard behaviour where it appends `/index` to
| the import path if it's a folder allowing you to shorten
| imports to import {} from './foo'
| z3t4 wrote:
| Gotcha in ES6 import is that you need to import the default
| export specifically eg. import default as Foo, * as Bar
|
| It would be much easier if it was one namespace like in
| Node.js require. eg. var Foo = await requires("foo", {fs:
| "/home/user"})
|
| Node.js modules are pretty much perfect besides the security
| flaws.
| jFriedensreich wrote:
| i like to have multiple deps files roughly grouped. this
| reduces not only the likelihood of name clashes but also gives
| a bit more structure and in addition when running in the
| browser its possible to handle bundling the dependencies
| separately by that grouping.
| riho wrote:
| This is probably one of the bigger issues holding me back from
| adopting Deno (at least for personal projects anyway). I'm
| sorry, I don't want to go back to early 2000s where we're copy
| pasting random links to script tags. Those days are over and
| for the better. NPM has proved pretty much undeniably that
| people prefer the simplicity of just typing in the name of
| something to install it, and import it. Does it have issues?
| Absolutely. I'd rather those issues be resolved than completely
| throwing away the concept though.
|
| This feels to me a bit like if a new browser came around and
| said "DNS is the root of all evil" and only allowed you to
| directly type in the IP address of websites.
|
| You can make all kinds of excuses, like "oh, but you can keep a
| list of your own!" or "hey, you can install this plugin that
| gives you DNS lookups back", but ultimately as a user I'm gonna
| say "No thanks, I'll keep using a browser that doesn't
| needlessly complicate my day."
|
| I'm usually an early adopter for this kind of stuff, and I
| really like a lot about Deno, which is why this situation just
| makes me very sad.
| ARussell wrote:
| You could opt to improve upon the standard practice, right? I
| have only played with Demo a little, but the deps file seems
| only like a convention rather than a strict rule.
|
| Why not instead create a deps directory, and keep in it one
| file per dependency? Inside each file, you re-export the
| library from URL.
|
| This way you can import from files rather than URLs elsewhere
| in your code, and it should be clear which dependency is being
| imported from the file name itself.
| zkldi wrote:
| That solution is great! But it sounds like something that
| could be automated or managed for me.
| 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
| arcatek wrote:
| It's almost like you need something to manage your
| packages to generate them.
| 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";
| zkldi wrote:
| > Do you namespace them yourself, or export an object under
| the name of the library (and therefore give up
| destructuring?)
|
| I know you can do this, but then you can't do
| import { Function1, Function2 } from "oak";
|
| You could do import { Oak } from
| "./deps.ts"; const { Function1, Function2 } = Oak;
|
| But that is still an awful workaround.
| antihero wrote:
| Perhaps you could do: import {
| Function1, Function2} from
| "https://deno.land/x/oak/mod.ts";
|
| In the file that needs them? Though then you have a lot of
| redundant URLs everywhere and god knows how auto-imports
| could work.
|
| Or perhaps you could do // deps/oak.ts
| export * from "https://deno.land/x/oak/mod.ts";
|
| and then you'd do import { Function1,
| Function2 } from './deps/oak';
|
| I am not a fan of any of these.
| searchableguy wrote:
| There are user land tools to manage dependencies for you. I
| cannot comment on the specifics because I haven't used them
| extensively but one example is deno-udd.
|
| It updates your dependencies. https://github.com/hayd/deno-
| udd
|
| There are one or two more feature rich ones. The need for
| deps.ts can be eliminated with management tools which work
| with your imports directly.
| zkldi wrote:
| That's just a package manager!
|
| If something like that is needed, then I think deno
| should attempt to come with something for managing
| dependencies.
|
| Eventually, developer convinience will win, and everyone
| will settle on some sort of package manager for deno.
| It'd probably be for the best if deno made it official
| as, personally, I think this is heading towards a second
| NPM.
| searchableguy wrote:
| Not quite the same. It's a simple management tool which
| rewrites your imports to use the latest version from
| supported registries. Deno binary still handles all the
| resolution, fetching, caching and loading.
|
| There are no plans to add such convenience in the binary
| because it would mean limiting places you can import from
| (cannot upgrade deps for unsupported registries). Deno
| binary will remain agnostic to where you import from.
|
| Community will come up with something if it's a huge
| problem and settle eventually.
| sroussey wrote:
| Wouldn't this work?
|
| import { Oak: {Function1, Function2} } from "./deps.ts";
| joelg236 wrote:
| This isn't valid syntax, no
| jessaustin wrote:
| This is a regression. This was possible with "require"
| and destructuring assignment.
| goldenkey wrote:
| I don't know why you are getting downvoted. I agree. The
| difference is that ES6 imports are meant to be more
| optimized and also can allow for async/top-level async
| modules. I believe part of the additions of ES6 modules
| made it harder to treat the right hand side like a
| complete object that can be destructured. In summary,
| it's not the syntax, it's the difference in feature
| richness between ES6 and CommonJS importing.
| jessaustin wrote:
| Yeah, I'm not saying that _import_ was a mistake or even
| a good idea done in the wrong way. I use "import"
| whenever I can in my own code. It could be impossible to
| import only the particular things one needs, and that
| trusting tree-shaking is the best we can do. However, it
| very much _seems_ like a first version to me, and that
| import statements could be made smart enough to
| destructure.
| sroussey wrote:
| Yeah, was afraid it might be bad ES6. But this is Delo,
| so they can do whatever they want.
| Soremwar wrote:
| No they can't, Deno is JavaScript compliant
| zomglings wrote:
| I'm curious, if anyone has lived through the experience: What is
| the migration story like to port an existing codebase from
| node.js to Deno?
| TranquilMarmot wrote:
| Even trying this with some toy projects I have it is NOT easy
| or straightforward. The dependency management alone is
| different enough to make this almost impossible.
|
| I think if you want to use Deno, it would have to be from the
| ground up or a complete rewrite.
| fatiherikli wrote:
| So probably Deno is something like that: console.log('Deno')
| fatiherikli wrote:
| Or (node = 'Node', 'Node'.substr(2, 4) + 'Node'.substr(0, 2))
|
| Can we stop implementing JS engines instead of resetting the
| router?
| syspec wrote:
| I have a question, how come people do not use Dart in place of
| this?
|
| It runs on the server, it is a typed language, it's faster than
| v8 javascript (since that is part of the reason for it's
| existence to eek out more performance)
|
| From what I've seen it can be distributed very as well, and your
| app is self contained ala Go.
|
| ---
|
| So my question is, why don't more people use Dart where they
| would use a "Node + 'Typescript compiled to JS'" combination,
| which seems like it has a lot of headaches once your project
| grows in size
| mixedCase wrote:
| Dart is an extremely limited language compared to TypeScript
| (it doesn't even have sum types), and has access to a much
| smaller ecosystem. Its runtime isn't much better either, like
| for example Go's or Haskell's is.
|
| Deno has a partial implementation of Node's API, and even
| without it it's still the same underlying runtime concepts, so
| porting is easier than porting to another language like Dart.
| s_tec wrote:
| If your team has invested a lot of time & energy into mastering
| the Javascript ecosystem (including things like Typescript), it
| makes sense to use the same language on the server side as
| well. Server machines are cheaper than good developers,
| especially if you can share resources between the backend &
| frontend.
|
| As for Deno specifically, it's definitely closer to the
| "browser" way of doing things than Node is, which is super
| attractive. The main reason to stick with Node is the huge
| library ecosystem, but Node itself feels kinda weird & old,
| since the language has moved in a different direction while
| Node has remained stagnant (poor support for promises & ES
| modules, for instance).
| inbx0 wrote:
| How come more people don't use ReasonML in place of this? It
| runs as OCaml on the server, it is a typed language, it's
| faster than v8 JavaScript. Or F#? Not a fan of the functional?
| Then maybe Kotlin? Nim? No?
|
| There are a ton of great languages out there, many arguably
| better than TS in many ways. But for a language to be popular,
| being great is not enough.
|
| I'm not sure what it is that makes TS so popular, but I am
| pretty sure that you have to look past mere language qualities
| for it.
| syspec wrote:
| Well in this case, the Dart VM and V8 are a made by the same
| people. That's why I asked.
| spartanatreyu wrote:
| One major thing to consider when thinking about replacing JS
| with another language:
|
| All JS already works inside TS so it's really easy to slowly
| transition your project over time between the two languages
| without losing any functionality or needing to take time off to
| make the transition.
|
| In practice this means, new code can just be written with TS
| and any existing code updates can be made in TS. After that you
| can decide whether to even touch the remaining JS which still
| works.
| jitl wrote:
| Dart has nothing to offer over other languages, and a lot of
| deficiencies. Why not use Kotlin? It's like Dart, but has a
| much bigger ecosystem.
| hannofcart wrote:
| I have only seen Dart code in Flutter code bases, and my
| comment here might be the result of incomplete knowledge.
| However, from what I can see, Dart seems to resemble the Java
| way of doing things a lot. Specifically, the over-use of is-a
| inheritance.
|
| Just scrolling through the list of examples in the Flutter
| samples directory illustrates this point.
|
| https://github.com/flutter/samples
|
| Use of inheritance seems to be the canonical way of doing
| things in Flutter and it seems to permeate the code base, both
| in the use of core Flutter APIs as well as associated library
| ecosystem. I find them rather hard to read and reason about.
| It's easy to be a bit confused on encountering a function in an
| object that inherited the function from a superclass 3 levels
| up in the hierarchy.
|
| To be clear, I completely recognize that it's unfair of me to
| attribute to Dart (the language) issues/patterns I see with a
| library/framework ecosystem (Flutter). But this is mitigated by
| the fact that Flutter is by far what the lion's share of Dart
| code is written for today. Please correct me if I'm wrong.
| jonathanaird wrote:
| The canonical way of doing things in Flutter is composition
| NOT inheritance. This is the whole point of Widgets.
| Inheritance is used in ways that generally make sense and
| don't result in huge complex inheritance trees.
| hajile wrote:
| Dart has top-level, first-class functions that don't
| require wrapping everything in a class. It then proceeds to
| waste this by wrapping everything up into classes and
| hoping nobody will use inheritance.
| oscargrouch wrote:
| Because Typescript eventually won that race? (The race to be a
| fine, typed and sane counterpart to Javascript).
|
| Somehow Typescript convinced people from the Javascript side of
| the fence that they could mix both and eventually upgrade from
| it. While Dart also tried the same feat, it failed doing so.
|
| Nowadays Dart is only being considered to anything because the
| team behind it are top-notch and implemented themselves a
| platform where Dart could be the king.
|
| Giving their talent they were able to create a great platform,
| where they would made even more success if they used Javascript
| or Typescript as a development language. But giving they wanted
| to save all their years of work on Dart, and giving its not a
| bad technology per-se, it just had a adoption problem, Dart
| lives on Flutter.
|
| If you want to use Flutter go for Dart, but picking Dart to
| anything outside Flutter will just alienate the developer crowd
| as giving even Typescript is some sort of a niche language in
| terms of adoption, nevermind forcing people to learn Dart.
| m00x wrote:
| > Because Typescript eventually won that race? (The race to
| be a fine, typed and sane counterpart to Javascript).
|
| Dart is doing fine, I'm not sure what race you're talking
| about?
|
| > If you want to use Flutter go for Dart, but picking Dart to
| anything outside Flutter will just alienate the developer
| crowd as giving even Typescript is some sort of a niche
| language in terms of adoption, nevermind forcing people to
| learn Dart
|
| Dart is incredibly similar to Javascript/Typescript. You can
| learn it over a weekend + lookups in Google whenever you see
| a difference.
|
| Your points are extremely weak.
| oscargrouch wrote:
| Where you were in 2012?
|
| Dart was heavily marketed as a Javascript successor by
| Google, this was even before ES5 changes, so Javascript was
| a even weaker language in terms of design, giving people
| were doing more and more full applications in the language.
|
| The problem is, Javascript did a catch-up, and the
| Typescript technique of compiling to Javascript made it
| more appealing as a successor, not mentioning the design of
| the language (I know that Dart had this too, but having its
| own JIT it were more appealing in terms of speed back
| then).
|
| Meanwhile Google abandoned the project that would allow the
| Dart VM and bindings to WebKit to coexist with V8. And now
| that only the Dart-to-JS path could be followed to develop
| for the Web, Typescript championed this path as it was the
| only way for them from the beggining.
|
| So if you were following those events, you would know what
| sort of race i was talking about.
|
| I agree with you that "Dart is doing fine", but is only
| doing so because of Flutter. As in, people learn Dart to
| target Flutter, not the other way around.
|
| Im not implying that Dart is a bad language, or technology,
| because thats not true. Its only a problem of adoption, and
| it will have a hard time outside of the Flutter bubble.
|
| If it were not for Flutter, Dart would continue is path to
| a slow death, not because its a bad language or technology,
| but because of how the events turned out to be, and a
| little bad luck.
| graftak wrote:
| As is the dart type system compared to that of typescript.
| goldsteinq wrote:
| Deno's interactive permission prompt is still easily bypassed by
| nicely asking terminal to confirm it:
|
| https://github.com/denoland/deno/issues/9750#issuecomment-79...
|
| Direct link to asciinema:
| https://asciinema.org/a/9rvK8ANJK0WnQc9nsrFKdC7ir
| ncmncm wrote:
| I can't see what Deno even is.
|
| Clicking the "deno" name at the top of the linked page takes me
| to another page that says just "cli" and "deploy". Great!
|
| Clicking CLI (why?) reveals it is a Javascript runtime in Rust.
| OK, what does one do with that? We know Javascript runtimes come
| built into browsers. What would I do with one on its own?
| Anywhere I could run it, I could run code that actually does
| something, instead.
|
| So I ... run it and use it to run somebody else's JS code? Whose?
| Or link it into something (what?) that I distribute, that runs
| somebody else's JS code? Whose? Is this a thing to bolt into an
| alternative browser, next to a CSS renderer, to compete with
| Chrome? Or into Chromium, in place of Google's JS engine?
|
| I can guess at answers to these questions, but why make me guess?
| lucacasonato wrote:
| Deno is a secure server side runtime for JavaScript and
| TypeScript. It is an alternative to Node.
| EMM_386 wrote:
| > I can't see what Deno even is.
|
| These are just release notes, for developers who already know
| what it is and want to see what's new.
|
| Literally the top result on Google for "Deno":
|
| https://deno.land/
| pictur wrote:
| What exactly does deno promise when it comes to package
| management?
| woutr_be wrote:
| Not sure why this got downvoted, but I have the same question.
| Most of my projects run behind a corporate firewall, where our
| NPM repository is proxied. Will Deno eventually offer
| something?
|
| As far as I understand, you can import packages from anywhere,
| which is obviously a major concern for anyone behind a
| corporate firewall
___________________________________________________________________
(page generated 2021-04-14 23:02 UTC)