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

221–230 of 235 posts

Re: Deno in 2023

#221

Post by wiseowise »

pjmlp wrote: post #202
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…

Alternatively, they could maybe, just maybe, learn another programming language, but that is asking too much in today's culture it seems.

Nothing screams efficient use of time like learning programming languages for every little thing.

Re: Deno in 2023

#222

Post by pjmlp »

wiseowise wrote: post #221
pjmlp wrote: post #202

Earlier quoted context omitted.

Alternatively, they could maybe, just maybe, learn another programming language, but that is asking too much in today's culture it seems.

Nothing screams efficient use of time like learning programming languages for every little thing.

It isn't harder than learning new JavaScript frameworks every month.

Re: Deno in 2023

#223

Post by DanielHB »

OscarDC wrote: post #216
DanielHB wrote: post #200

Earlier quoted context omitted.

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())…

To add to this, a lot of those "W3C API" (most?) (to which I'll also add WHATWG API, like HTML5 - or fetch) have actually no relation to ECMAScript and thus aren't generally in v8 because they are not JavaScript. Those API could be thought as from the "environment" in which JavaScript run. For example we often call web-only APIs "DOM API": `fetch`, `xmlHttpRequest` and so on. Node.js also has its own environment. For…

Good points, I always wondered why it took so long for NodeJS to support fetch() and WebSockets and other standard APIs. I thought those were part of V8, but I guess not!

Re: Deno in 2023

#226

Post by archerx »

pests wrote: post #219
archerx wrote: post #193

Earlier quoted context omitted.

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.

If you can't tell a 1 apart from an L...

Thats not the point, but what about people that have vision impairments? Isnt the whole point about accessibility?

Re: Deno in 2023

#228

Post by int_19h »

kybishop wrote: post #94
user3939382 wrote: post #91

Earlier quoted context omitted.

I totally get the idea of bringing JS into new environments because it is so ubiquitous. On the other hand, I hate the language and wish we could replace it in the browser, the opposite direction. I'd be much happier with ClojureScript or PureScript or something being the standard with the ecosystem to go with it.

Typescript takes away a significant amount of the pain for me; the only hold up after that was getting an environment set up to compile it. Deno supporting typescript without any configuration is incredible.

TypeScript is mostly additive, so all the footguns are still there if you aren't careful to avoid them. It also doesn't do anything about the extremely meager standard library that is inferior to what other mainstream PLs had 20+ years ago.

Re: Deno in 2023

#229

Post by int_19h »

ecmascript wrote: post #209
surajrmal wrote: post #96

Earlier quoted context omitted.

This is whataboutism. Different sizes are acceptable for different people based on context. I worry about 10s of kilobytes for things I work on for instance.

Yes but there is a reason for it being 100mb. You get a self-contained app where you can get to write in javascript. You don't have to spend 100x the time in order to get the same app working in Rust. If size is such a big deal, then don't use Deno, Node or Bun. My issue is that most people that are working in restricted environments would never touch javascript since it's not well suited for those kinds of environme…

Your argument seems to be that those 100 Mb include the necessary libraries. The problem with this assertion is that much richer runtimes don't require that much. For example, a .NET Core console app published as self-contained is ~65 Mb, and it comes with more libraries than Deno.

Re: Deno in 2023

#230

Post by int_19h »

mborch wrote: post #114
fabiospampinato wrote: post #49

Earlier quoted context omitted.

Yes but now in non-linux systems you have the pretty large overhead of that.

On MacOS, you have built-in sandboxing via "sandbox-exec" which shouldn't incur any noticeable overhead. It's used by Chrome, Bazel, etc. Not sure what's available on Windows.

Windows has a lot of things in this department. https://github.com/microsoft/Windows-Sandbox-Utilities sounds similar to what you describe, but there are also finer-grained APIs: https://learn.microsoft.com/en-us/windows/win32/secauthz/app...
Post reply on HN