|
| brundolf wrote:
| I'm really strongly rooting for Deno. I'm even implementing my
| current passion-project on it
| (https://github.com/brundonsmith/bagel). But I have a couple of
| significant (but solvable!) criticisms, if anybody on the team is
| here.
|
| 1) The documentation for the standard APIs is extremely wanting.
| The main, and weirdest, problem is that it seems almost
| impossible for search engines to index (or at least DDG). I can
| search for very very specific things, and still get kicked to the
| home page and have to manually navigate to the part I'm looking
| for (and the navigation is also pretty difficult; I often can't
| find the thing at all and have to rely completely on editor
| hover-overs for documentation). It can also be confusing- some
| things like certain standard APIs appear to have multiple
| conflicting reference-manuals? And it can be hard to know which
| one is current or correct. Even getting past all the obfuscation,
| the docs are just ok. They often leave out deeper details (this
| last part is less of a problem and more understandable, this
| being a young project).
|
| 2) The VSCode extension still needs work. It's usable, and better
| than nothing, and it's better than it used to be, but (ordered
| from most to least significant):
|
| - When I open certain files - usually bundles or something; maybe
| files outside of the project directory? - the language server
| crashes over and over and over, each time popping the terminal
| back up to show the output and distracting from what I'm trying
| to look at. This doesn't happen with my normal, in-project Deno
| files at least.
|
| - It doesn't have auto-import as you're typing like normal
| TypeScript does; you can auto-import by clicking the lightbulb,
| so I assume it's a relatively short hop to plug that in. Makes a
| significant difference in flow.
|
| - It chokes on absolute import-paths in Windows. Thinks they're
| malformed remote URLs.
|
| - It has caching issues sometimes. I'll change some type in one
| file and other files won't get the updated type until I close and
| re-open them, or sometimes the whole editor. This is uncommon so
| it's not a huge deal.
|
| I list these criticisms because I want to see Deno succeed.
| Switching from using TypeScript on Node (with the build
| steps/configuration, ad-hoc testing and linting, and Node's
| pathological legacy APIs) to Deno was a huge quality of life
| improvement, even with all these problems. Brought to its full
| potential, I think Deno could be a revolution.
| ravenstine wrote:
| Yeah, I've seen worst API documentation, but their docs site is
| needlessly weird. Documentation is something that should be
| solved by now. No project needs whatever custom thing Deno
| uses. I don't get it.
|
| Leaving out details, for the most part, is the right approach
| for now, I think. Only Node/JavaScript veterans should probably
| be using Deno for the time being. But I definitely hope Deno
| can eventually take over and make Node obsolete.
|
| > 2) The VSCode extension still needs work. It's usable, and
| better than nothing, and it's better than it used to be, but
| (ordered from most to least significant)
|
| At this point, I've kind of given up on VS Code
| language/runtime extensions in general. Virtually none of them
| work with the slightest variation in toolchain configuration,
| whether it's C++ or Typescript or even ESLint. You're lucky if
| they don't slow the heck down over time. Import paths are the
| worst! Somehow that's something I inevitably run into, again,
| no matter the language.
|
| I kinda want to blow all this stuff up and start over. Maybe
| Deno is a part of that equation. haha
| jay_kyburz wrote:
| The API doc page crashes my iPad. I can't even open it.
| postalrat wrote:
| It would be really cool to see the service worker api supported
| in deno.
| Miaourt wrote:
| Why would you need that in a runtime context ?
| dgb23 wrote:
| Maybe to build custom proxies with the same API.
| postalrat wrote:
| Proxy or server
| 91edec wrote:
| I started a project with a Deno backend and Svelte front end last
| week and it was painful trying to share types between the
| projects. Deno not allowing imports without file extensions '.ts'
| and the Typescript tsserver not allowing imports with a '.ts'
| extension is really annoying, and neither group seems to want to
| budge. I ended up having to create a shared types folder and a
| script that copies the files to each project stripping out file
| extensions for non-Deno projects.
|
| Does anyone else have a better solution shared Typescript code?
| wwwigham wrote:
| Deno has _very_ custom module resolution rules. The first thing
| you notice is the required `.ts` extensions and browser-esque
| URLs. Oh, and also the import maps proposal (which is its own
| can of worms). Then you dig a little deeper and learn that deno
| also supposedly supports all `node` resolution rules sometimes
| via compat flags. Then you learn that it pulls types from magic
| `/// Deno has no "magical" module resolution.
|
| Which, as an implementor of module system rules, seems
| incredibly far from the truth of the matter (where deno has the
| most complex resolution rules of any runtime currently in use).
| I think maybe there were simple goals at the start, but that
| came crashing against reality and xkcd 927 executed in full
| force.
| AbuAssar wrote:
| Related:
|
| https://github.com/microsoft/TypeScript/issues/42813
| deckard1 wrote:
| This sounds just like the headaches I had about a year ago
| using ESM for isomorphic code, with node. The only thing that
| ever worked was, of course, Babel.
| candiddevmike wrote:
| Another question, how are people actually using Typescript with
| Svelte? It seems like you can't use $some.prop = avalue, it
| can't be type checked, so wtf is the point of using Typescript
| with Svelte?
| ravenstine wrote:
| Having used Typescript with Svelte, I think that Typescript
| is still potentially useful, just not directly in `.svelte`
| files. There's nothing wrong with keeping all your business
| logic in separate `.ts` files and then importing them into
| your Svelte components, because those components can and
| often are primarily view logic, and the utility of having
| everything type-checked down to the template level is... not
| particularly significant IMO. If your Typescript modules are
| still type-checked and pass tests, then I find trying to make
| a Svelte project Typescript all the way down to be kind of
| paranoid.
|
| To each their own, but I think life's too short to be adding
| types to your view logic and your templates. It adds so much
| complexity for so little gain. Maybe it'll get better at some
| point where it will change my mind, in particular when using
| something like Deno.
| IshKebab wrote:
| Damn I was hoping Svelte had proper Typescript support given
| that they claim that Svelte officially supports TypeScript.
| Is it just like Vue - it "supports" it, but there's still
| important stuff that's not type checked at compile time?
| The_rationalist wrote:
| marcus_cemes wrote:
| Well, good news for you, it does! Very well, in fact.
| Svelte itself is written in TypeScript.
| marcus_cemes wrote:
| I'm not sure about "$some.prop = avalue", but props are
| declared as exports of your component [1], and they can be
| given types. Perhaps you're refering to "$$props"? The only
| time I've hacked into the component variables is to check
| whether slot is set.
|
| [1]: https://svelte.dev/tutorial/declaring-props
| makapuf wrote:
| Yes had the same issue. Had to make deno run js files and
| import js produced by ts.
| danielvaughn wrote:
| I get the appeal of TS, but why the fuck would any project tie
| themselves to the language in this way? Angular 2+ did it, I
| didn't realize Deno did as well. Very bizarre decision unless
| I'm missing something.
| Bilal_io wrote:
| Just like the sibling comment stated. Angular does not force
| you to use Typescript, you can use JavaScript. Angular 2+
| even used to work with Dart but they dropped it.
| ignoramous wrote:
| > _Angular 2+ even used to work with Dart but they dropped
| it._
|
| "They" dropped Angular altogether:
| https://blog.angular.io/finding-a-path-forward-with-
| angularj...
| Bilal_io wrote:
| I was not referring to Angularjs. I specifically
| mentioned Angular 2+.
| xkapastel wrote:
| What do you mean? You can use TypeScript or JavaScript, so
| .ts or .js extensions.
|
| I think what you are missing is that, if you use TypeScript
| in Deno, the extension is .ts. What's confusing is the way
| Node.js+TypeScript does it, which means using TypeScript with
| .js extensions.
| danielvaughn wrote:
| Ohh I see. I should probably delete my comment then. I
| thought the OP meant that Deno enforces the use of
| Typescript like Angular does. That makes a lot more sense,
| thanks for the explanation.
| spankalee wrote:
| The way TypeScript/Node does it is correct. The thing
| you're importing is JS with a .js extension. If you publish
| to npm you're publishing the JS files, not TS files. If you
| write .d.ts/.js pairs instead of .ts - which should be
| identical to importers, there's no .ts file to import.
| nllsh wrote:
| Considering that Ryan Dahl started both Node.js (where
| imports do not include file extensions) and Deno (where
| he added them back after deciding it was a bad decision
| to leave them off) I'm not sure how you've come to the
| conclusion that TypeScript/Node does importing correctly.
| Additionally, the ecmascript import syntax
| https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe... specifically mentions that
| your tooling may or may not need file extensions but the
| examples in the spec (and indeed in browsers at large)
| require a full or relative path including the extension.
| If anything, I'd bet that file extensions make it into
| Node and tsc in the next few years.
| spankalee wrote:
| Node requires the extension for imports already, unless
| the package you're importing from has defined
| extensionless entries in an export map.
| schemescape wrote:
| This also makes using TypeScript libraries that weren't
| authored specifically for Deno nontrivial.
|
| One solution is to use an import map on the Deno side to map
| your extensionless imports to the corresponding files, but this
| only works when you control the Deno command line arguments (so
| not for libraries you plan to publish for others to use).
|
| It's unfortunate because, other than this huge problem, Deno is
| the best TypeScript runtime I've found.
| brundolf wrote:
| Another good workaround is to use something like JSPM, which
| bundles up the NPM library with all its dependencies into an
| ES module, ready to be consumed (and even loaded remotely!)
| by Deno
| ignoramous wrote:
| > _Deno is the best TypeScript runtime I've found._
|
| I may be nitpicking here, but Deno isn't a typescript
| runtime, is it? In the usual case, does it not transpile
| typescript to JavaScript and run the code from there?
| pseudosavant wrote:
| Yes, but I'd argue that is an implementation detail. You
| can directly run a TypeScript file like this `deno run
| helloWorld.ts`.
|
| Is Node really a JavaScript runtime? V8 converts the JS to
| an AST. Would that make Node an `AST runtime`?
| fivea wrote:
| > Yes, but I'd argue that is an implementation detail.
| You can directly run a TypeScript file like this `deno
| run helloWorld.ts`.
|
| Why yes, you can run directly Typescript code in Node
| (well, at least just as direct as Deno, as it transpiles
| TS to JS) with the likes of ts-node.
|
| https://www.npmjs.com/package/ts-node
| nitsky wrote:
| Then it would be fair to say ts-node is a typescript
| runtime, while node is a javascript runtime.
| piaste wrote:
| > I ended up having to create a shared types folder and a
| script that copies the files to each project stripping out file
| extensions for non-Deno projects.
|
| Still a hack, but perhaps symlinks could be a little simpler?
| stickyricky wrote:
| Whats the purpose of sharing types? Define entities on each and
| leave behavior as a domain consideration. Clients should be
| disposable and decoupled. If you want to render html on the
| server that's fine but svelte isn't the best choice for that.
| fivea wrote:
| > Clients should be disposable and decoupled.
|
| No, not really. Clients are loosely coupled, but they must
| comply with a contract.
|
| And guess what: contracts define types, and REST focuses
| almost exclusively on types.
| stickyricky wrote:
| > Clients are loosely coupled
|
| Under the architecture I describe, no, clients and servers
| do not couple to one another. The client and server couple
| to a data interchange format.
|
| > contracts define types
|
| Yes, the interchange format defines the types _for the
| interchange_. But a string can be represented as an
| enumeration on the server and as a checkbox on the client.
| The _type_ of the data is dependent on context.
| afavour wrote:
| > Whats the purpose of sharing types?
|
| Server sends data as JSON to the client. Client parses JSON.
| Both now have the exact same data shape. Shared TS types let
| you use the same representation for the same data no matter
| where.
| stickyricky wrote:
| At the expense of coupling which is not a trivial concern.
| Regardless, the browser is the only platform capable of
| using those types (even so the types aren't shared but
| generated). You don't use those types in Swift or Java or
| Kotlin. You don't use those types in a python client
| library.
| The_rationalist wrote:
| throw10920 wrote:
| Why does adding types result in any more coupling than
| what exists already?
|
| If your client and server both treat field "temperature"
| as a string for protocol version 1, and then the client
| upgrades to protocol version 2 and temperature is now a
| float, the server has to be modified _anyway_ , type
| system or no type system, because otherwise it'll break.
|
| If anything, the type system helps to expose the fact
| that the client and server now disagree about the type of
| a field, which is helpful.
| danielvaughn wrote:
| In my experience this coupling cannot be avoided. At a
| bare minimum the client has to know the communication
| protocol of the server. This means you typically need to
| define this protocol in both the server and client. If
| you could define it once and have both the client and
| server pull from the single source, it's a win.
| wruza wrote:
| What expense?
| afavour wrote:
| > Regardless, the browser is the only platform capable of
| using those types
|
| That and a Node/Deno backend. Which is what the OP is
| talking about.
| zkldi wrote:
| Sharing the types of API returns is very useful.
| jbirer wrote:
| Deno came too late, there is Go and Rust now
| esjeon wrote:
| Yeah, that's kinda sorry state of Deno right now. We have more
| than pure JS/TS ecosystem that NPM used to thrive on.
|
| The backend market is already leaned toward Go. It's the best
| language for microservices. We also have WASM entering the
| scene on the frontend side, which allows mixing other
| languages, especially Rust. Hell, I heard some people ported a
| whole C++-based UI engine to make it cross-platform. We're
| already entering the next generation.
| DrFell wrote:
| If you like Deno because of TypeScript, you're gunna love this:
| Imagine the jump from JavaScript to TypeScript, only taken to a
| whole new level! It's free, open source, cross-platform, really
| fast, has an enormous ecosystem, and is great for games and
| native apps! It's called C#.NET.
| nozzlegear wrote:
| I had attempted to use Deno not long ago, but I learned that
| (apparently, I might be wrong) you can only get proper
| intellisense/error checking support if you're using a VS Code
| extension. I write my code in Vim/Neovim almost exclusively, and
| the import declarations really screwed up my TypeScript plugin;
| it didn't know how to handle the URLs and so I had no
| intellisense/error checking.
|
| I gave up after searching around for a few minutes and learning
| that for now I'd need to use VS Code to write Deno code, if I
| want those features.
| 91edec wrote:
| If you're using coc you can add the coc-deno extension and
| initialize the project with `CocCommand
| deno.initializeWorkspace`.
| nozzlegear wrote:
| Thanks! I didn't know about the coc extension, I'll give that
| a try.
| choward wrote:
| I have to believe that you leaving the "-deno" off of "coc-
| deno extension" was intentional which I find to be pretty
| funny.
| phil294 wrote:
| Neovim apparently supports the LSP protocol natively, so
| could you please explain why CoC is necessary?
| chana_masala wrote:
| From the last I saw, coc is still more feature rich than
| native LSP in Neovim.
| brundolf wrote:
| It does suck that it can't use standard typescript tooling
| because of a couple of small, key, breaking-differences (mainly
| the import path style, to my understanding). I don't think they
| could have done it any differently, and with enough traction
| the ecosystem support is a solvable problem, but it's still a
| shame.
| ravenstine wrote:
| I agree, though I do think that Deno's import paths are _more
| correct_ than Node.js or tsc. I 'm not exactly sure sure why
| official Typescript can't support both by now.
| simonw wrote:
| The FFI interface looks very neatly designed. Here's how the
| SQLite module is implemented using it:
| https://deno.land/x/sqlite3@0.3.0/src/ffi.ts
| edgyquant wrote:
| I've recently started a new personal project and I'm using Deno.
| I'm really happy with it as my main complaint about typescript
| currently is the transpile process slows down development when
| you're used to all the bells and whistles of modern JavaScript.
| Things like hot reloading take 3x as long.
| lucacasonato wrote:
| Try `--no-check` when using `--watch` and you already get type
| errors from your IDE. Should speed up hot reload and hot
| restarts significantly :-)
| Escapado wrote:
| About 3 months ago I got my feet wet and fiddled around with it
| for a bit. Eventually I used it to deploy(using deno deploy) a
| small script which would forward calls to an unofficial API of
| some App. It turned out chrome would not let me set a Cookie
| header (which the API required) due to some security policy in my
| axios calls so my script would proxy the request and inject it
| when calling the API. I was pretty amazed by how easy the whole
| process was. I can see myself using it more often for side
| projects and even recommending it at work (If I get the
| enterprise java crowd to try something new).
| egeozcan wrote:
| In my experience, enterprise Java crowd never spills its
| managed beans. In my whole career, I couldn't even get any of
| them admit that JSF may not be the best front end technology in
| the world. It's a lost cause.
| rukshn wrote:
| I have to second this. I worked on a java app which was
| painful to scale, due to JSF and JPA. I have distanced myself
| from the project as much as I can.
|
| Now, I see another new app for a different purpose being
| started and I hoped to push for a modern way of building it,
| but no they just won't give-up using java and JSF.
|
| Nothing wrong with java, it's just java and jsf crowd is hard
| to be converted to something else.
| u-rate wrote:
| I love the current version of Deno for smaller hobby projects.
| But using it in a full blown production env with actual paying
| customers depending on it is a whole different story. Deno is a
| lot simpler and more cohesive than node. But the simplicity is
| what currently stops me from attempting any big projects with it.
| Yes, having no package.json files is great - but on the other
| hand it hinders me from configuring my project in one file.
| Epskampie wrote:
| I don't really get the point of Deno anymore. First they were all
| about their sandbox/security system, but since you couldn't
| specify that per module it turned out basically useless.
|
| Then they had "url" imports, but now they're adding npm
| compatibility. At that point people will just keep publishing on
| npm, so I don't see why I should go to the trouble of switching
| to Deno.
| n0w wrote:
| For me, one of the largest benefits is the Web API
| compatibility.
|
| As a frontend dev by day, trying to write services/scripts in
| Node is constantly frustrating. Simple things like base64
| encoding or making http requests have me heading off to the
| documentation and trying to remember "the Node way".
|
| The other large part for me is the lack of npm. The npm
| ecosystem is one of my largest sources of daily frustration. I
| look forward to ESM everywhere.
| brundolf wrote:
| Running TypeScript directly is a great part, but there's a
| bigger, little-discussed aspect: Deno has a built-in,
| prescribed, standardized,
|
| - Testing framework
|
| - Linter
|
| - Bundler
|
| - Formatter
|
| It's like having Cargo or Go's CLI for JavaScript/TypeScript.
| It eliminates so much fiddling and breakage, gets everyone in
| the ecosystem on the same page, etc. Even for a solo project
| it's been a dream to use, compared with the hodgepodge of a
| Node project.
| sondr3 wrote:
| At least for me one of my favorite things is how integrated it
| is, after having used Rust for a while, having the compiler,
| linter, lightweight testing and formatting all in one bundle is
| an amazing time saver and a major boon for me. No more fiddling
| with ever growing configurations for ESLint, or having to
| install Jest/Ava/uvu/tap for testing and their ESLint rules and
| then Prettier which may also require ESLint... I realize not
| everyone cares enough to configure it, but the approach of Deno
| (and Rust, and Go, and so on) is such a weight of my shoulders
| when starting a project. Just open Neovim, create a TypeScript
| file, write some tests, all without having to do any kind of
| configuration or installation of packages.
| nllsh wrote:
| If you are concerned about security in one of your imported
| dependencies (or in user code) you can run that code in a
| sandboxed worker (See: https://deno.land/manual@v1.18.0/runtime
| /workers#specifying-...). Beyond this it is still very useful
| to limit your runtime for software to only access specific
| directories, network addresses, etc. So the sandbox/security is
| definitely not useless.
| [deleted]
| andrewstuart wrote:
| If you'd like the Amazon JavaScript SDK to support Deno then make
| your support known on this thread:
|
| https://github.com/aws/aws-sdk-js-v3/issues/1289
| userSumo wrote:
| I also dont get the point of Deno. when i was looking into it
| seemed to me that was presented as a modern NPM alternative. Yet,
| it is completely unusable for any kind of frontend work. Which is
| wierd, since javascript is a frontend language. You cannot use it
| to write anything that uses DOM API. Not sure if that is supposed
| to change. Would be nice if it was clearer that it is a solution
| for back-end only.
| kentor wrote:
| I've recently used Deno to implement a couple of bots for a small
| discord channel, namely webhook handlers for Discord Slash
| Commands and Twitch's EventSub. It's honestly been amazing. Next
| to no configuration and deployments are dead simple. Just set up
| some env vars and push to github to deploy.
| ipnon wrote:
| Deno seems ideal for the now common use case of serverless
| JavaScript, erm, servers. It's hard to imagine the project
| superseding the prior art in other domains, however. Deno is a
| little too weird.
| tfsh wrote:
| It's interesting to see the intersection between Deno TypeScript
| code and native Rust libraries, e.g the native HTTP library [1],
| however it would be interesting to see a performance evaluation
| between this and a regular express app.
| tills13 wrote:
| I am very interesting in the performance implications here as
| their _has_ to be some performance tradeoffs given you have to
| serialize / deserialize across the bindings. I get that Rust is
| fast, but at what point does the trade-off no longer make
| sense?
| searchableguy wrote:
| https://deno.land/benchmarks is what you are looking for.
| AaronO wrote:
| On many of our internal benchmarks, Deno's std/http server
| outperforms Node's http (so express/koa too). There's still
| some room for improvement on our end and we would like to put
| together rigorous benchmarks before sharing that broadly.
| chana_masala wrote:
| I had a weird experience on Libera.chat #node - I asked if anyone
| knew of an official #deno channel and ljharb's [1] reply was
| (something like) "deno is repeating all of the mistakes that JS
| has made in the browser" and the sentiment was that "deno sucks."
| I found it to be a strange comment.
|
| [1] https://github.com/ljharb
___________________________________________________________________
(page generated 2022-01-25 23:01 UTC) |