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

151–160 of 235 posts

Re: Deno in 2023

#151

Post by tracker1 »

brundolf wrote: post #73
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…

I'm not sure using deno compile as a way of deploying to a controlled environment has much benefit anyway. Unlike some other languages/runtimes, only a single system dependency is really needed (a new-enough deno installation) to run your code In my view, deno compile is more about shipping command line tools to people with all sorts of personal environments (which may not have deno at all)

I've been really happy with using Deno as a general scripting runtime... A shebang at the top and external dependencies are loaded to a shared path on run.

I do wish there was support for Linux distributions based on musl (Alpine) directly for smaller containers.

In general I like the Deno approach better than Node. Would be cool to see the UI tooling flushed out. A material or fluent based component library where Deno can be used like Flutter would be very cool indeed.

Re: Deno in 2023

#152

Post by tracker1 »

littlestymaar wrote: post #57
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…

> Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again! While I agree with you that it's not optimal and should get fixed, 90MB doesn't sounds like it can stop you from deploying it either.

It adds up though... Personally, I'm fine with Deno in the path and scripts with a shebang in practice.

If reach one of my scripts was a separate build output from Deno that would be several GB of space.

Re: Deno in 2023

#153

Post by rglover »

mring33621 wrote: post #131
agos wrote: post #105

I'd love to use Fresh but a framework for web development which calls itself v1.x and yet only supports Tailwind for styling purposes feels very immature. The fact that for the next iteration they are prioritizing view transitions and not CSS bundling is baffling.

Hopefully, in a few years, someone will release an open-source library for javascript-based web development.

https://github.com/cheatcode/joystick

Re: Deno in 2023

#154

Post by dvlsg »

bheadmaster wrote: post #129
epolanski wrote: post #55

Earlier quoted context omitted.

Multithreading is achieved through workers and the event based architecture, it's not the same, but we should rather discuss the pros/cons of it.

Pros: Vertical scalability. Cons: All your async code becomes full of data races. I suppose adding multithreading to the Node ecosystem would be as hard (if not harder) than removing GIL from Python. At least Python has locking primitives. Node, as far as I know, has none.

> Node, as far as I know, has none.

Atomics are probably the closest. https://v8.dev/features/atomics

Re: Deno in 2023

#155

Post by tracker1 »

declaredapple wrote: post #138
ecmascript wrote: post #70

Earlier quoted context omitted.

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.

100MB at 1Gbps is ~0.8s to load. This especially sucks for FaaS and CI/CDs. This makes it difficult to use for on-demand use cases that are latency sensitive. That and that's likely 100MB that's going to be competing for memory now* , in FaaS environments especially that's a ton of resources and you increase latency to load that especially over network storage. This also inflates container sizes and just becomes a pa…

Could be worse, could be Java. At least in terms of container size, cold start times and overhead at runtime. And I know there are options for AOT, etc. that are all more complex to configure than Deno build.

Re: Deno in 2023

#156

Post by kibibu »

jokethrowaway wrote: post #130
RussianCow wrote: post #125

Earlier quoted context omitted.

It's not the JavaScript runtime that's faster but the built-in APIs. Supposedly (I haven't tested this myself), Deno has faster implementations of many Node.js APIs, which I have seen reflected in benchmarks for things like throughput in an HTTP server.

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

Re: Deno in 2023

#157

Post by tracker1 »

nonethewiser wrote: post #88
pachico wrote: post #68

I'm not a big fan of JavaScript but I admit I stayed away from it because I dislike nodejs and npm terribly. I was forced to start coding again in JS some weeks ago and I wanted to try Deno. I must say it's been a very smooth and fast experience so far. Very well done!

Can you comment on what you prefer about it? I find npm/js pretty smooth and the rough edges of Deno seem to kill the purported improvements at this point. That was just my gut-take several months ago and I was already steeped in the node/npm ecosystem so I'm curious about your perspective.

No Byzantine build config files,. As a start. Dependencies are downloaded to a shared location outside your project on demand instead of a separate npm install step.

TypeScript and esm/cjs usage without crazy syntax (writing modules, consuming cjs at least).

Lintinng and formatting in the box.

Can do shell scripts without package.json and nom install, just a shebang line at the top.

These are some of the things I like better.

Re: Deno in 2023

#158

Post by simlevesque »

I deployed 3 projects on Deno last year and I'm planning on launching 2 websites in the next couple of months. Mix of personal projects and some for clients.

Deno Deploy just works, albeit the cold start can be slow but I'm now using an hybrid setup with Fresh routes backed by a CDN.

The dev experience is great. I've used a couple of other solutions similar (Next, Nuxt and vite-ssr-plugin) and I sometimes I need to do somethings manually that would already exist on other platforms but in the end my projects stay simpler.

I love saaskit [1] and Netzo [2]

[1] https://deno.com/saaskit [2] https://github.com/netzo/netzo

Re: Deno in 2023

#159

Post by tracker1 »

wldlyinaccurate wrote: post #11

I deployed my first non-trivial Deno app to production in 2023. There were some teething issues with learning to keep the lock file in sync, especially in a repo with multiple entry points each with separate lock files. Some of the granular permissions stuff didn't work how I expected, to the point where I almost gave up and just allowed network to/from all hosts. But overall the experience was good, and I have posit…

I tend to put a shebang line on Deno scripts intended to be run... This has the permissions right there in the script.

Alternatively, like in my ~/bin, I'll put a shell script without a file extension to make it easier on myself.

Re: Deno in 2023

#160

Post by landr0id »

pygy_ wrote: post #99
FrostKiwi wrote: post #74

Earlier quoted context omitted.

Big fan of custom rendering approaches, but wouldn't such a Design system sidestep any and accessibility tools? Nothing for screenreader to hook into. Text and interfaces would be neither native nor DOM based.

Slint uses https://github.com/AccessKit/accesskit to provide cross-platform a11y.

> a11y

I apologize for this being so besides the point of your post, but I hate this trend so much.

Post reply on HN