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

Deno in 2023

deno.com

Post reply on HN
Print view View original

171–180 of 235 posts

Re: Deno in 2023

#171

Post by landr0id »

refulgentis wrote: post #169
landr0id wrote: post #168

Earlier quoted context omitted.

i18n has been around for ever and makes sense since in code it’s a bit long. Then k8s, which never made sense to me. I don’t know if it’s appropriate to call it a trend, but I’ve seen people doing it more frequently. The irony with this example is people with screen readers will hear something like “aEleveny” and it looks like “ally”.

People with screen readers are aware of acronyms even if they have poor vision, and it's unclear to me what the problem is, a11y has been around forever and in code it's a bit long. Reading again, is the trend you detest...abbreviations that have a number representing letter count? Based on the existence of k8s and a11y?

I’m just stating my opinion that I find these abbreviations annoying, yes. They are so unintuitive that unless someone explicitly calls out what it’s abbreviating, you probably wouldn’t pick up on it (e.g. the MDN page for Accessibility) and just leaves people confused (like me!). I suspect there’s a reason AccessKit isn’t named `a11yKit`

Re: Deno in 2023

#172

Post by apitman »

Are there any libraries or frameworks to facilitate writing code that accesses things like the filesystem and network, but also works in Node, Deno, and Bun (bunodeno)?

Re: Deno in 2023

#173

Post by pests »

landr0id wrote: post #171
refulgentis wrote: post #169

Earlier quoted context omitted.

People with screen readers are aware of acronyms even if they have poor vision, and it's unclear to me what the problem is, a11y has been around forever and in code it's a bit long. Reading again, is the trend you detest...abbreviations that have a number representing letter count? Based on the existence of k8s and a11y?

I’m just stating my opinion that I find these abbreviations annoying, yes. They are so unintuitive that unless someone explicitly calls out what it’s abbreviating, you probably wouldn’t pick up on it (e.g. the MDN page for Accessibility) and just leaves people confused (like me!). I suspect there’s a reason AccessKit isn’t named `a11yKit`

Aren't a lot of abbreviations unintuitive until you learn what they mean?

Didn't we just have a thread the other day about the meaning of "MDN" - which also many people didn't know.

I see on this site "IMO" "FWIW" "IANAL" "TLDR" all the time. You generally can't tell what these mean either without looking them up or just knowing already because of them being so engrained in culture.

Re: Deno in 2023

#174

Post by 0x457 »

ecmascript wrote: post #70
dingdingdang wrote: post #36

Would love to see the compile situation fixed - the generated executables are ~90MB+ at this stage and do now allow compression without erroring out. Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again! The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than…

When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript. Most of it is the international libraries anyway so. I find it pretty ridicolous since I go to a website today and it's at least 15MB each time I refresh but 100MB on the server is a problem? Dude cmon.

Modern games aren't 700Gb, there are a very few very large games. One of them is large on purpose to make to delete other games.

Updates for games are large because they aren't "just updated files", but a giant blob that can't be rearranged since it's optimized for loading order later.

Giant self-contained deploys like that are bad because their use case is CLI/GUI tools shipped to the end user. To give you context: my /usr/bin is ~900 binaries and total size is 109mb.

Re: Deno in 2023

#175

Post by factormeta »

ijustlovemath wrote: post #115
dns_snek wrote: post #93

Earlier quoted context omitted.

Isn't QuickJS order(s) of magnitude slower than V8? That doesn't seem like a practical tradeoff to make outside of embedded.

Like I said, I wasn't sure of their requirements. I can say QuickJS is orders of magnitude easier to embed and understand than V8, which is why I adopted it for my use case.

Thanks for sharing that info!

Would like to see more runtime independent JS project such Hono. Although I'm not sure if it supports QuickJS.

Re: Deno in 2023

#176

Post by 0x457 »

dmattia wrote: post #124
fshr wrote: post #117

Earlier quoted context omitted.

The compiled option isn’t intended for serverless or edge uses, you just deploy the source files and the platform takes over.

Some serverless use cases work like you say, but Docker-based options such as AWS ECS, Docker-based Lambda functions, or Kubernetes would all commonly make use of compiled options

No, you won't use compiled option in k8s or any other container based deployment.

You would use deno as base layer, your dependencies in another layer, your code is in the last layer.

Re: Deno in 2023

#177

Post by factormeta »

kibibu wrote: post #156
jokethrowaway wrote: post #130

Earlier quoted context omitted.

Same with bun, it looks like node is leaving some performance on the table (maybe for backward compatibility or maybe because nobody bothered to improve it)

Bun doesn't use V8, so there are other performance differences there

It is fair to note, that JavascriptCore outperforms V8 already. However, it is in Zig. And Deno is in Rust.

Re: Deno in 2023

#178

Post by whstl »

pjmlp wrote: post #28
vorticalbox wrote: post #22

Earlier quoted context omitted.

> If node.js decided to include functionality similar to what is available on Bun/Deno, both projects would probably lose traction quickly. I believe this too. The big appeal for me is not having to install typescript, eslint, jest AND then set up all the configs. deno has nice defaults, though the importing via URLS and browser compatible API do make deno very tempting

Except they are playing catch up with what Microsoft says Typescript is supposed to mean. I rather have pure JavaScript, or use the Typescript from source, without having to figure out if a type analysis bug is from me, or the tool that is catching up to Typescript vlatest.

> without having to figure out if a type analysis bug is from me, or the tool

Deno uses regular Typescript for static type checking, it's just built-in. Bun also doesn't do type checking by itself, they recommend using tsc [2].

[1] https://docs.deno.com/runtime/manual/advanced/typescript/faq...

[2] https://bun.sh/docs/runtime/typescript#running-ts-files

Re: Deno in 2023

#179

Post by [deleted] »

refulgentis wrote: post #169
landr0id wrote: post #168

Earlier quoted context omitted.

i18n has been around for ever and makes sense since in code it’s a bit long. Then k8s, which never made sense to me. I don’t know if it’s appropriate to call it a trend, but I’ve seen people doing it more frequently. The irony with this example is people with screen readers will hear something like “aEleveny” and it looks like “ally”.

People with screen readers are aware of acronyms even if they have poor vision, and it's unclear to me what the problem is, a11y has been around forever and in code it's a bit long. Reading again, is the trend you detest...abbreviations that have a number representing letter count? Based on the existence of k8s and a11y?

[deleted]

Re: Deno in 2023

#180

Post by moal »

themerone wrote: post #128
ogoffart wrote: post #126

Earlier quoted context omitted.

FLTK and other libraries cannot be used from JavaScript. JavaScript is one of the most popular programming language. But a JavaScript dev who needs to make a desktop GUI will usually need to use Electron to bring up a browser for the GUI. This means actually two JavaScript engine (Node and Chromium) The reason it has to do with Deno is that you need a JavaScript/TypeScript runtime. But you may not need a browser. So…

FLTK is permanently stuck in the 90s. It doesn't have full unicode support, right-to-left & bidirectional text, and doesn't support accessibility tools. Not to mention that development has been stagnant for 15 years since it's flagship application (Nuke), was ported to QT.

Actually FLTK has full unicode support, right-to-left and bidi text. The limiting factor is the OS. For rtl and bidi, it depends on the OS. On linux for example, if FLTK is built with pango support, it'll support them just fine. On windows and macos, these work out of the box. As for accessibility, the only thing missing is screen reader support. Otherwise tab navigation, ime and other modalities are supported. FLTK's bindings in Rust provide an accesskit adapter which supports screen readers using the accesskit crate.
Post reply on HN