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

131–140 of 193 posts

Re: Deno 2.8

#131

Post by moron4hire »

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…

(I know it's Brendan Eich, I just didn't notice the damn glass keyboard made its own decisions on what I meant.)

Re: Deno 2.8

#132

Post by csjh »

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.

It should be pretty mature outside of Wasi. To be fair, there's really nothing that's super mature in terms of Wasi support, except maybe Wasmtime

Re: Deno 2.8

#133

Post by rutierut »

As someone who has used Deno on multiple hobby projects, I’m convinced Deno is where the JS ecosystem should be heading.

Professionally though, it’s complicated recommending it outside of specific and mostly tightly scoped use-cases. At some point the project just changes direction because of business reasons and you need node.

Re: Deno 2.8

#134

Post by syrusakbary »

It's great to see that since the release of Edge.js [1], they started to take Node.js compatibility more seriously (they went from ~40% to about 75% in just 2 months, so either coincidental or not this is clearly a step on the right direction).

Good work to everyone on the Deno team!

[1] https://edgejs.org/

Re: Deno 2.8

#135

Post by WorldMaker »

Curosinono wrote: post #125
WorldMaker wrote: post #54

Earlier quoted context omitted.

Because standardization is a political process that takes time and consensus to achieve? https://github.com/tc39/proposal-type-annotations

TypeScript is now 13 years old. They could have, by now, made it a lot easier to be able to use Typescript in a browser out of the box without magic behind it.

Typescript certainly hasn't been resting on its laurels.

Typescript has always worked pretty well in the browser. You can use the full Typescript LSP in vscode.dev or github.dev just fine.

I've even seen websites ship the Typescript compiler as a part of their bundle. It's not the most efficient use of bandwidth, but especially for corporate internal sites if it increases velocity it might not be a bad trade-off. Though it made more sense in the AMD and SystemJS days than in the ESM.

Typescript also support JSDoc mode very well where you have all your types in comments instead of inline. JSDoc type checked files run just fine in the browser without transpilation.

Typescript has also invested a lot into "Isolated Modules" and "Verbatim Module Syntax" and linting for such. This tooling makes it easier to keep modules cleanly type strippable without needing to run the full compiler. (This is something that Node support for Typescript requires, for example.) "Isolated Modules" also get code ready for the Type Annotations support if that gets to the next stage with TC-39. It also makes it possible to bundle a small, fast type stripper in the browser as a module loading plugin, should ESM get module loading plugins ahead of Type Annotations support. (There are proposals for that in front of TC-39 as well.)

Re: Deno 2.8

#136

Post by sirsinsalot »

freedomben wrote: post #6
vmsp wrote: post #5

I wonder how Deno's faring. Node's the stable solution and will be with us forever. You can now use TypeScript with it and, soon enough, you'll be able to build your app to a single executable -- including native deps. Bun's chaotic but, nonetheless, it's _fast_ and it's taking an interesting approach by including everything in the stdlib. Plus, bought by Anthropic. Deno had an awesome story with the sandbox and ease…

> and, soon enough, you'll be able to build your app to a single executable -- including native deps. Whoa, did not know that. That's a killer feature!

Code, as a single executable you say?! Whatever will they think of next?

Re: Deno 2.8

#137

Post by sirsinsalot »

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.

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.

Re: Deno 2.8

#138

Post by sirsinsalot »

hollowturtle wrote: post #124
VerifiedReports wrote: post #71

Earlier quoted context omitted.

All good questions. But... it would simply eliminate a step and result in a single language. Python supports types and is interpreted, right?

Interpreted that's right, in fact it's super slow and adding types adds up to parsing time. Javascript is jitted. Python types serves no purpose if not for documenting or letting the lsp doing some lightweight type checking. And btw typescript introduced many breaking changes and the spec is managed by microsoft something you don't want for the open web. What we would really benefinit from would be having WASM being…

I mean, all typescript does is serve no purpose except for an LSP and documenting type intention really. It isn't much different to Python type annotation.

Re: Deno 2.8

#139

Post by sirsinsalot »

antod wrote: post #127
VerifiedReports wrote: post #71

Earlier quoted context omitted.

All good questions. But... it would simply eliminate a step and result in a single language. Python supports types and is interpreted, right?

Python containing type hints doesn't get transpiled the way typescript does. The transpiling rewrites the TS to varying degrees depending on the target and the extra TS features being used. Python "just" (that word is doing a lot of work) updated the interpreter to ignore the type hints. It still runs the same way as code without hints. There's a bit more going on with TS that you couldn't just have the runtime ignor…

As I understand it you can, in fact node 23 has a type stripping feature. I could be wrong.

Re: Deno 2.8

#140

Post by sirsinsalot »

yoyohello13 wrote: post #73
Curosinono wrote: post #41

I don't get it why the hell is TypeScript still not nativly supported in modern browsers?

My gripe is why doesn't Webassembly fully support dom manipulation. If we got that working anyone could just bring any language to the browser and we would finally be free from the shackles of JS.

Or at least some kind of cursor based text buffer tree that wasm can bind to the dom/shadow tree, rather than a fuller API
Post reply on HN