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

191–200 of 235 posts

Re: Deno in 2023

#191

Post by yellowapple »

ogoffart wrote: post #126
CyberDildonics wrote: post #119

Earlier quoted context omitted.

What does it have to do with Deno and why do any of that to draw boxes and text on the screen? FLTK could do GUIs that took almost no CPU power starting with 100KB binaries 30 years ago. People doing hardware accelerated GUIs have been using openGL for almost as long. This doesn't need to be a science project or a rabbit hole, drawing a GUI quickly is well worn territory.

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 and other libraries cannot be used from JavaScript.

What's the obstacle to using it via FFI (which Deno seems to support)?

Re: Deno in 2023

#192

Post by archerx »

landr0id wrote: post #160
pygy_ wrote: post #99

Earlier quoted context omitted.

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.

Yes it’s awful, “A eleven Y” or is it “A one one Y” Is stupid, inaccessible and the people who use it and came up with it should feel bad.

Re: Deno in 2023

#193

Post by archerx »

pests wrote: post #173
landr0id wrote: post #171

Earlier quoted context omitted.

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.

No it’s not the same, a11y creates a dissonance in the mind because part if it wants to see it as “ally”, the other part wants to see it as “A eleven Y” and the other part cringes and thinks its stupid.

Re: Deno in 2023

#194

Post by Kyiro »

ravenstine wrote: post #163
papruapap wrote: post #50

Earlier quoted context omitted.

Agree. This feature just make it worse as a script language, which are supposed to have rapid development.

Why? `--allow-all` is the epitome of trivial. You can even wrap the deno executable in a script that passes that to it every time if that's what you really need.

Even better, you can do `-A`

Re: Deno in 2023

#195

Post by Kyiro »

ecmascript wrote: post #27

I have a deno app in production and it is working just fine. However, I still think node is superior when you self host when you are not using docker. Deno afaik still doesn't support any way of running one process for every CPU like the cluster module in Node.js. I like to run my shit on the metal and without Docker and it feels like Deno was designed to run on Docker or some other kind of virtual containerized envi…

You can do it using Workers, just like you would in a web browser

Re: Deno in 2023

#196

Post by nikisweeting »

Awesome work Deno team! I've been hard on ya'll in the past to add NPM package support and I can now officially retract all of my earlier criticisms.

It's amazing to see Deno mature so fast while staying well-thought-out, and I'm excited to use it in as many projects as I can now.

Re: Deno in 2023

#197

Post by ogoffart »

yellowapple wrote: post #191
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 and other libraries cannot be used from JavaScript. What's the obstacle to using it via FFI (which Deno seems to support)?

Someone has to first write bindings to the library using said FFI. This is not something most JavaScript dev can do. This has to be written by someone who knows C++ and JavaScript, and be good at both to understand all the details. (How the two interacts, how the lifetime of C++ objects play with the garbage collector, how do the inventloop mixes, ...) Writing such binding is a huge work as they the whole API need to be wrapped. And sometimes concept from the one language don't map easily in the other. (eg. templates)

And then you still have to ship an extra binary in addition to Deno itself.

Re: Deno in 2023

#198

Post by pjmlp »

whstl wrote: post #178
pjmlp wrote: post #28

Earlier quoted context omitted.

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

Until they bundle Microsoft's compiler, it isn't the same thing.

It is like tracking down if a C bug in GCC relates to developer, or GCC understanding of ISO C documentation.

Just this alone proves it isn't the same thing,

=> Deno tries to keep up to date with general releases of TypeScript, providing them in the next patch or minor release of Deno.

Re: Deno in 2023

#199

Post by DanielHB »

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.

NPM used to be reaaaaaallly bad due to lack of lockfiles and how it used to handle diamond dependencies Added to the propencity of JS projects to have a ton of deps...

It has mostly been sorted out by all package managers. The node_modules debacle is still a hotly contested topic, it creates a lot of problems, but it also solves a lot of them compared to alternative approaches.

Then you have install performance which is mostly fine by now in all package managers, but if you really have problems with it you can use pnpm or yarn2.

As the python ecosystem grows and dependency trees move away from "django only" you can see they having the same types of problems that JS used to have.

Re: Deno in 2023

#200

Post by DanielHB »

satvikpendem wrote: post #190
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.

What does that mean, though? Does Deno create an HTTP server in Rust directly?

A ton of NodeJS modules are not part of V8 at all, like "fs" or "path" because those don't really make sense in a browser context. Basically everything that is not a W3C standard is probably not implemented in V8.

Like, for example, I recently found out that there are 3 separate ReadbleStream objects in NodeJS, one from "stream" (older one used in Request), one from "stream/web" (W3C standard, used by global.fetch()) and another one I forgot where it comes from. It doesn't help that two of them have the same name and you run into errors like "ReadableStream is not of type ReadableStream".

I assume the one from "stream/web" directly calls into V8 APIs because since it is a standard it would be implemented in V8 (it is used in the browser's window.fetch() after all). While the one from "stream" is built and maintained by NodeJS Foundation.

It is not really reasonable to expect the NodeJS Foundation to have enough resources to optimise all this modules to the max. And the W3C doesn't seem interested in building standards for server-side only things.

Post reply on HN