Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 2.8

deno.com

Post reply on HN
Print view View original

141–150 of 193 posts

Re: Deno 2.8

#141

Post by wpollock »

sirsinsalot wrote: post #137
wpollock wrote: post #128

Earlier quoted context omitted.

> Because "it doesn't exist". It's just a layer on top of js, ... C++ was originally a layer on top of C. The first C++ compiler, "cfront" was actually a transpiler to C. There is nothing preventing TypeScript from becoming "native" in a similar way.

It doesn't make any sense tho. Typescript is nothing much to do with runtime. It's a build/dev concern. To get JS from TS you're mostly removing the type annotations. Theres no reason to ship TS to an end user browser.

> Theres no reason to ship TS to an end user browser.

As things are now, developers write code in TypeScript, then debug and update code in Javascript. It might not be much of a reason, but a single language throughout is surely easier on developers and maintainers.

Re: Deno 2.8

#142

Post by nsonha »

dan_rock_wilson wrote: post #26

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extend…

"basic permission model" used to be the only thing Deno had going for, and the keyword is "basic". They pivot pretty late to become a drop-in replacement for nodejs (using the term drop-in loosely here).

Bun has a pragmatic approach from the beginning for being a all-in-one toolset (not just a runtime) and node's replacement. They also has gradual adoption paths such as using bun only as package manager and/or test runner.

Re: Deno 2.8

#143

Post by paulddraper »

dan_rock_wilson wrote: post #26

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extend…

Bun prioritized Node.js compatibility.

Deno since adjusted, but Bun gained a lot of market share in the meantime.

Re: Deno 2.8

#144

Post by rochacon »

danielcasper wrote: post #130

I literally just discovered Deno today. I wish there was Deno for Python / WASM path was really mature. Maybe I'm missing something here, but trying to secure both a Python runtime and JS runtime for AI.

For Python, `uv` [1] delivers a similar experience. Faster dependencies. Better dependency management with `pyproject.toml`. Just use it with `uv run` or `uvx`.

[1] https://github.com/astral-sh/uv

Re: Deno 2.8

#145

Post by arikrahman »

moron4hire wrote: post #116
coffeebeqn wrote: post #99

Earlier quoted context omitted.

In my area it feels like it’s competing against go which is a language purposefully designed for the thing we’re building and has a great tool chain already. I never really wanted JavaScript. It’s not a very thoughtfully designed language and the not very good design was made for the browser. I just used node because it was simple to get it working. And you have bun and things like that competing for the space too

> It’s not a very thoughtfully designed language... This meme has to die. It hasn't been true for longer than it was ever true. Yes, we all know Brendan Rich "designed JavaScript in a week" in 1995, but that initial design was A) actually quite elegant for its goals, and B) has really only been an historical curiosity since the ECMAScript standardization process started in 2005. There are people who were born, grew u…

It's not thoughtfully designed. Just look at the effort Rich Hickey took with Clojure and then compare. It's not even in the same league.

Re: Deno 2.8

#146

Post by arikrahman »

appplication wrote: post #40
neals wrote: post #16

Earlier quoted context omitted.

It's good to have some options, to prevent the ecosystem from stalling

I agree philosophically, but the JavaScript ecosystem has never been languishing for lack of options. If anything, excessive fragmentation is a real concern.

I agree that frameworks are abundant but there are not that many JS engine alternatives.

Re: Deno 2.8

#147

Post by pjmlp »

arikrahman wrote: post #146
appplication wrote: post #40

Earlier quoted context omitted.

I agree philosophically, but the JavaScript ecosystem has never been languishing for lack of options. If anything, excessive fragmentation is a real concern.

I agree that frameworks are abundant but there are not that many JS engine alternatives.

It has been raining JS engines since Netscape Application Server, alone on Wikipedia there are 22 listed.

Re: Deno 2.8

#148

Post by pjmlp »

ale wrote: post #57

I think if Deno had held on to their initial values for a little longer the pressure towards node compatibility would have been mended by AI agents, because a lot of the pressure is the result of skill issues: if the only way you know how to set up is using express.js then any subsequent tool or runtime must provide a similar abstraction for a “smooth” transition, regardless of how bad the first solution was in the f…

If the JS/TS SDK I get from a SaaS vendor doesn't work on Deno without changes, I am not going to spend one second to make it work.

Re: Deno 2.8

#149

Post by pjmlp »

wpollock wrote: post #128
hollowturtle wrote: post #49

Earlier quoted context omitted.

Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?

> Because "it doesn't exist". It's just a layer on top of js, ... C++ was originally a layer on top of C. The first C++ compiler, "cfront" was actually a transpiler to C. There is nothing preventing TypeScript from becoming "native" in a similar way.

Typescript is only a linter, except for types annotations it is regular JS, quite different from C with Classes.

If you are going to mention enum and namespaces, the team considers them a design error, and only keeps them around due to backwards compatibility.

Re: Deno 2.8

#150

Post by dmit »

moron4hire wrote: post #116
coffeebeqn wrote: post #99

Earlier quoted context omitted.

In my area it feels like it’s competing against go which is a language purposefully designed for the thing we’re building and has a great tool chain already. I never really wanted JavaScript. It’s not a very thoughtfully designed language and the not very good design was made for the browser. I just used node because it was simple to get it working. And you have bun and things like that competing for the space too

> It’s not a very thoughtfully designed language... This meme has to die. It hasn't been true for longer than it was ever true. Yes, we all know Brendan Rich "designed JavaScript in a week" in 1995, but that initial design was A) actually quite elegant for its goals, and B) has really only been an historical curiosity since the ECMAScript standardization process started in 2005. There are people who were born, grew u…

> no, JavaScript is not a perfect language

Such a brave stance against a claim literally nobody has ever staked.

Post reply on HN