4 ms·

I was really excited about deno and gave it a fair shake. I was certain I needed what it promised, and I was determined to make it work for me. Since trying an

I was really excited about deno and gave it a fair shake. I was certain I needed what it promised, and I was determined to make it work for me. Since trying and running up against the friction and barriers, I’ve realized I don’t care much anymore about sharing code from front to back. It feels weird to reflect on how badly I wanted it and how little I care about it now. I suppose I feel like it’s trying to optimize for the wrong thing. Part of my reluctance to share code from front to back is that I have Go for the backend now, and using Typescript on the backend feels like a serious disservice to my productivity and happiness. Rust is also compelling in some cases. It’s rare that I actually want to be writing Typescript on the server. On the frontend I find myself wanting the thinnest wrappers on my backends possible. Not like obtuse UIs that don’t hide anything for my unfortunate users, but I mean in the underlying logic, I have no desire to do anything clever or abstracted in the client. I have one side project I built with Deno and it’s the one I’m the most reluctant to return to. The only motivation I get to work on it, frankly, is to migrate it off to something else. I do wish it worked out. But that, and a lot of what this article mentions, has kind of ruined the whole idea for me. Maybe we will get there one day, but I think we’re much further than many would think. The current options seem like massive compromises only to gain code you can share easily. Which, as mentioned, is quite easy to do with WASM now too. If you don’t need rapid throughput, WASM is great. If you do, it’s often still acceptable. The interface isn’t ideal, but for my purposes it has been better than adopting Deno or Bun. Having said that… I think these are awesome projects nonetheless. They’re trying to accomplish something worth accomplishing. It’s an envelope we should keep pushing. Me though… I’m too boring for this stuff.

zem 3y ago
I'm using deno to write integration tests for a complex google sheets script. sharing code between frontend and backend may not be that much of a win, but testing js code with a CLI is a great boon.
WuxiFingerHold 3y ago
> I have Go for the backend now, and using Typescript on the backend feels like a serious disservice to my productivity and happiness Interesting, I feel the opposite. To me, Go is cumbersome and missing a lot of the nice APIs that Deno provides. I've switched from Go to Typescript (Node, for now, but considering Deno for better tooling and better APIs) and feel way more productive. But I'm curious about what your experience with Deno itself was, apart from Typescript.
- steve_adams_86 3y ago
  > I'm curious about what your experience with Deno itself was I'd describe it as mostly good, but not good enough. I prefer it over Node as a server runtime for several reasons (more secure by default is a huge deal, simpler yet better tool chain which "just works", APIs which respect web standards, plugin system is really cool) , and if I had to build a project based around Typescript in a monorepo I'd almost certainly prefer deno over Node. One thing I really liked at first was how easily you can write executable scripts... I didn't expect to like it, but Typescript is very expressive and sane enough that writing a script with it is relatively pleasant. However, the real snag is that you need deno on a machine to run them... I love writing scripts with Go too, and it's arguably much nicer off the shelf, so that plus quickly lost its appeal as well. I prefer portability too much not to stick with bash, or otherwise publish executable binaries. Regardless, it's a cool feature if you're on a team which uses deno; using TS across the stack, even in your scripts (without the gnarly barrier of npm or some other script runner) seems like it could be legitimately capable and productive, but also ergonomic without significant compromise in most cases. > Go is cumbersome and missing a lot of the nice APIs that Deno provides I would have agreed a few years ago, but I know I was personally just "holding it wrong". Go is very powerful and easy to use in the right hands. However, it could only be that I do relatively simple tasks with it, or those the language designers intended. I don't doubt for a second that you had a bad experience with it for legitimate reasons; I only mean that I had a rough time with it because I didn't understand the language deeply enough. Admittedly, I wanted to use Go like I used Typescript. They're much different languages underneath, but sometimes it feels as though you should be able to design things in similar ways. It's typically not the case, though. The type system is far different, and the fact that it supports concurrency so primitively means a lot of its constructs are designed quite differently than intuition might inform you if you're coming from the Node world. Otherwise, they lack overlap in terms of how objects work, Go's lack of prototypical inheritance, and so on. When you put it all together they're far different from each other, and their patterns less fungible, than they seemed to me at a glance. However, I'm not a classically trained computer scientist so I've often been prone to holding languages wrong, so to speak, until error and extensive reading pounded a proper grasp and understanding into my mind. > the nice APIs that Deno provides I'm curious, what are these missing APIs from your perspective?

zem 3y ago

I'm using deno to write integration tests for a complex google sheets script. sharing code between frontend and backend may not be that much of a win, but testing js code with a CLI is a great boon.

WuxiFingerHold 3y ago

> I have Go for the backend now, and using Typescript on the backend feels like a serious disservice to my productivity and happiness Interesting, I feel the opposite. To me, Go is cumbersome and missing a lot of the nice APIs that Deno provides. I've switched from Go to Typescript (Node, for now, but considering Deno for better tooling and better APIs) and feel way more productive. But I'm curious about what your experience with Deno itself was, apart from Typescript.

steve_adams_86 3y ago
> I'm curious about what your experience with Deno itself was I'd describe it as mostly good, but not good enough. I prefer it over Node as a server runtime for several reasons (more secure by default is a huge deal, simpler yet better tool chain which "just works", APIs which respect web standards, plugin system is really cool) , and if I had to build a project based around Typescript in a monorepo I'd almost certainly prefer deno over Node. One thing I really liked at first was how easily you can write executable scripts... I didn't expect to like it, but Typescript is very expressive and sane enough that writing a script with it is relatively pleasant. However, the real snag is that you need deno on a machine to run them... I love writing scripts with Go too, and it's arguably much nicer off the shelf, so that plus quickly lost its appeal as well. I prefer portability too much not to stick with bash, or otherwise publish executable binaries. Regardless, it's a cool feature if you're on a team which uses deno; using TS across the stack, even in your scripts (without the gnarly barrier of npm or some other script runner) seems like it could be legitimately capable and productive, but also ergonomic without significant compromise in most cases. > Go is cumbersome and missing a lot of the nice APIs that Deno provides I would have agreed a few years ago, but I know I was personally just "holding it wrong". Go is very powerful and easy to use in the right hands. However, it could only be that I do relatively simple tasks with it, or those the language designers intended. I don't doubt for a second that you had a bad experience with it for legitimate reasons; I only mean that I had a rough time with it because I didn't understand the language deeply enough. Admittedly, I wanted to use Go like I used Typescript. They're much different languages underneath, but sometimes it feels as though you should be able to design things in similar ways. It's typically not the case, though. The type system is far different, and the fact that it supports concurrency so primitively means a lot of its constructs are designed quite differently than intuition might inform you if you're coming from the Node world. Otherwise, they lack overlap in terms of how objects work, Go's lack of prototypical inheritance, and so on. When you put it all together they're far different from each other, and their patterns less fungible, than they seemed to me at a glance. However, I'm not a classically trained computer scientist so I've often been prone to holding languages wrong, so to speak, until error and extensive reading pounded a proper grasp and understanding into my mind. > the nice APIs that Deno provides I'm curious, what are these missing APIs from your perspective?