I recently got a simple edge function working on Netlify for a tiny hobbyist project, with some minor confusion but it was fine. I'm wondering how Deno Deploy compares?
I'm really excited for when they also get state (Deno kv).
61–70 of 112 posts
I recently got a simple edge function working on Netlify for a tiny hobbyist project, with some minor confusion but it was fine. I'm wondering how Deno Deploy compares?
I'm really excited for when they also get state (Deno kv).
Earlier quoted context omitted.
Deno Deploy is the killer feature for me, and it’s ultimately the main product of Deno, Inc. too. Node support just makes it easier to get existing software running there. I don’t think it will suffer the same fate as Kotlin because a lot of the value add is in Deploy, Deno KV, etc.
What do you mean by "same fate as kotlin"? I would say Kotlin is doing great. Anything I missed?
Hey folks - I worked on this. AMA
Earlier quoted context omitted.
I disagree. people love a robust ecosystem, not innovation for innovation's sake.
I think you are both right. Some people love innovation, others love stability.
I do wonder about the long-term effects of Deno being Node-compatible; will it result in only Node programming being done since "Deno will handle it fine" and thus Deno specific stuff will not be developed?
I think you can analogize these server JS runtimes (Node, Deno) to browser runtimes (V8, JavaScriptCore, SpiderMonkey) and to the APIs that ship with those. When one browser JS engine invents and exposes a novel feature + API surface for it that the other engines don't, what happens? If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for so…
Could you please explain what Deno is like I am five? (three actually)
Deno is moving into a similar space as Kotlin started at by adding all this interop—they're trying to be the "better Node". Meanwhile Kotlin is frantically trying to differentiate itself because Java is closing the gap, but it's hard for them to do because they've spent so long piggybacking on the Java ecosystem. Deno is very vulnerable to the same fate. Yes, it's easier to get adoption if you can plug into an ecosys…
Personally, I haven't heard of any Kotlin devs going back to Java nor of any Deno devs going back to Node.
Deno is moving into a similar space as Kotlin started at by adding all this interop—they're trying to be the "better Node". Meanwhile Kotlin is frantically trying to differentiate itself because Java is closing the gap, but it's hard for them to do because they've spent so long piggybacking on the Java ecosystem. Deno is very vulnerable to the same fate. Yes, it's easier to get adoption if you can plug into an ecosys…
Deno Deploy is the killer feature for me, and it’s ultimately the main product of Deno, Inc. too. Node support just makes it easier to get existing software running there. I don’t think it will suffer the same fate as Kotlin because a lot of the value add is in Deploy, Deno KV, etc.