Deno is just a marketing company dressed as a software startup
Reports of Deno's Demise Have Been Greatly Exaggerated
41–50 of 210 posts
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#42Earlier quoted context omitted.
Why would you use something other than a JS framework to build a web app back-end? You don't have to deal with OpenAPI or GraphQL, you can just use server actions.
You don't need to deal with those anyway. RPC it. fetch one one end, route on other.
> RPC it. fetch one one end, route on other.
What do you mean by this?
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#43Earlier quoted context omitted.
Because out of all the languages that stand a chance of being adopted at most workplaces, TypeScript is in my opinion the single most enjoyable to code in. It has an extremely expressive type system that gets out of your way and allows you to model almost anything you can come up with, it has great IDE integrations on both VS Code and JetBrains, it has strong first-class support for functional programming patterns. O…
I'm torn between Go (nicer runtime) and Node (get to use TS for nicer types!)
For me Go doesn't even come close. It's way too restrictive in what I can and can't do with it.
I might feel differently if I worked with a large number of people who I didn't trust, but on small to medium teams composed of very senior people using Go feels like coding with one hand tied behind my back.
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#44Earlier quoted context omitted.
maybe because async Python is painful, an async TypeScript / JS is the default.
Use another language where async isn't painful then? Since it's the backend, you have 100% control over what stack to chose, unless some other requirement gets in the way. And no, async isn't "the default" in at least JavaScript, not sure where you'd get that from.
> And no, async isn't "the default" in at least JavaScript, not sure where you'd get that from.
My bad. I was conflating common idioms and actuality.
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#45I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes with it. The whole selling point for me was that deno was node without the bullshit and baggage, but they dropped that and basically just turned it into node with built in typescript support and a few other minor things like the permissions. Similar story with…
Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty comprehensive. You can also stick with the libraries available on jsr.io if you’re satisfied with what you can find there.
If you want the developer experience of using something that’s not Node, you can still get it from Deno.
But it turns out that few people care that much about purity, so it’s fortunate that they’re not relying on that.
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#46Earlier quoted context omitted.
> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? What's the point? If you're in love with static types, but have to do JavaScript because you're targeting the browser, I kind of understand why'd you go for TypeScript. But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript which is a "Compile-to-JS" language? Yo…
Why would you use something other than a JS framework to build a web app back-end? You don't have to deal with OpenAPI or GraphQL, you can just use server actions.
Better/scalable performance, actual runtime type checking without wrapping everything with third-party libraries and paying the associated overhead, talent pool in my area, better (or even existing) libraries for the task at hand, better observability instrumentation, personal preference... is this really an honest question?
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#47Earlier quoted context omitted.
I dunno, HTTP works pretty well for me as a transport layer to communicate with clients. Otherwise Websockets. Not sure why you'd think that be a difficult thing?
> Not sure why you'd think that be a difficult thing? You aren't suggesting to handwrite an HTTP API client, right? You would have to set up either OpenAPI which is a mess, or GraphQL which is also a mess. LMK if you have a better solution.
What exactly is the problem you're encountering when trying to interact with HTTP APIs? If you really want to use OpenAPI for whatever reason, there are plenty of ways of doing that even in Clojure/Java, so I'm sure it's possible in other languages as well. But it's not like using OpenAPI or GraphQL are the only two options, if you're of that opinion I'm afraid you've drank way too much of the koolaid.
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#48Earlier quoted context omitted.
> Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere…
I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types". Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`…
I don’t understand the need to share types between frontend and backend. It’s like a strong incentive to take the wrong decisions down the lines instead of using the right data model for the domain.
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#49Earlier quoted context omitted.
> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? What's the point? If you're in love with static types, but have to do JavaScript because you're targeting the browser, I kind of understand why'd you go for TypeScript. But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript which is a "Compile-to-JS" language? Yo…
Because out of all the languages that stand a chance of being adopted at most workplaces, TypeScript is in my opinion the single most enjoyable to code in. It has an extremely expressive type system that gets out of your way and allows you to model almost anything you can come up with, it has great IDE integrations on both VS Code and JetBrains, it has strong first-class support for functional programming patterns. O…
Well there's C# / .NET, which ticks off all of those boxes, even the functional syntax is well supported since it added pattern matching and people write a lot of fluent functional style anyway with LINQ.
It also interops nicely with F#, so you can write a pure functional library in F# and call it from a C# program in the "functional core, imperative shell" style.
It has an incredibly solid runtime, and a good type system that balances letting you do what you want without being overly fussy.
Re: Reports of Deno's Demise Have Been Greatly Exaggerated
#50Earlier quoted context omitted.
> Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere…
I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types". Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`…
> I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else.
But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too?
It's not like TypeScript gives you some inherit benefit that makes it easier to convert to JavaScript, besides the fact that it's literally a "Compile-to-JS" language.