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

The Deno Company

deno.com

Post reply on HN
Print view View original

271–280 of 446 posts

Re: The Deno Company

#271

Post by gutino »

VWWHFSfQ wrote: post #96

> Of the myriad ways to program computers, scripting languages are the most effortless and practical variety. Of these, the web browser scripting language (JavaScript) is the fastest, most popular, and the only one with an industrial standardization process. I haven't fully investigated in a few years, but isn't it still true that LuaJIT is is faster than V8 JavaScript? The last I saw it was outperforming V8 by a lot…

Probably the benchamark you saw was just a iteration of any math calc. In real programs V8 js is orders of magnitude faster than LuaJit

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: The Deno Company

#272

Post by colejohnson66 »

rhencke wrote: post #171
breck wrote: post #149

Earlier quoted context omitted.

I would say no. I think they should go public domain, as that's the future. One of the funniest/best business models out there is SQlite ( https://sqlite.org/copyright.html ). They give it away to the public domain, but some lawyers wrongly claim that that is not enough, so they will "sell" you a warranty asserting it is all public domain.

Those lawyers are correct. Not all jurisdictions of the world legally recognize the concept of 'public domain'.

There does exist the CC0 license[0] which attempts to alleviate it, but I haven’t heard if it’s been tested in the courts.

[0]: https://creativecommons.org/publicdomain/zero/1.0/

Re: The Deno Company

#273

Post by jhgb »

pknopf wrote: post #247
ivan888 wrote: post #244

Earlier quoted context omitted.

> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think th…

There will likely be some kind of npm at some point.

If the goal is to get rid of NPM, why would you add another one in the future?

Re: The Deno Company

#274

Post by threatofrain »

kevincox wrote: post #178
threatofrain wrote: post #139

Earlier quoted context omitted.

But you don’t get full control, and that’s why people go native. Because platforms rightly distrust web apps. This will likely be true for a long time as security becomes a bigger deal everyday.

Most "modern" platforms distrust native apps too. (Android, iOS and increasingly macOS, Windows and even Linux) This is one of the main reason that I often prefer web apps. (my preference obviously depends on the use case) I would much rather run a random company's messaging/video chat/whatever app inside my browser with strong sandboxing. Because browsers have truly accepted that applications should be considered ma…

But in those more modern platforms, web apps still have a big disparity vs native in terms of privilege, and it's not obvious why the gap should shrink; after all, apps that run native have passed their internal bureaucracy process and are thus more trustworthy.

Re: The Deno Company

#276

Post by elisee »

sbarre wrote: post #253
elisee wrote: post #183

Earlier quoted context omitted.

Correct! In production we've got Cloudflare in the middle, so we're only using sucrase on-the-fly for each .ts file during development. So far it's unnoticeable in terms of loading times. > I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach? Not that I can tell. But if we need to, we can always do a minified bundle in production…

Wait, so you're running Sucrase in a Cloudflare Worker? It compiles, and then caches the output I assume? That's a really cool use case I hadn't thought of..

Not quite, I'm running Sucrase on my Deno HTTP server: if the extension is ".ts", I put the file through sucrase before serving it as text/javascript. In development, it happens every single time I reload (and it's fast enough that I don't even notice). In production, Cloudflare requests the .ts file from my server once (triggering sucrase), and then caches it.

Re: The Deno Company

#277

Post by forty »

pknopf wrote: post #247
ivan888 wrote: post #244

Earlier quoted context omitted.

> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think th…

There will likely be some kind of npm at some point.

Yes, i think recreating an npm kind of central place for your project dependencies seems almost required if you want to avoid depending on a different version of a lib in each file of your project.

I cannot understand the benefit of this scheme honestly. I would have preferred they fix something npm is lacking, like adding the ability to sign packages

Re: The Deno Company

#278

Post by ericlewis »

ravenstine wrote: post #240

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…

- AFAIK - it still compiles into normal JS nor does the TS team work on deno (hope I am wrong) so it's not really FCC as most would think

- this doesn't make sense, its bad API design and shoe horning in a completely different paradigm is not a good idea, it should have moved somewhere less familiar and more oriented to the environment (I know that sounds weird but giving a quick answer, there are better solutions and this aint a browser)

- not bad, but seems odd to me as a language feature in some ways, there are plenty of ways to achieve this. (macOS will do this to your node scripts even itself, why do we need more of it)

- this is subject to the same problems NPM could have, but I guess it is easier? Now you have to lexically parse all files to determine an import and you also have to remember where you keep your 3rd party packages without a centralized way to know it (edit: this seems to harm the previous point)

- bundling isn't that interesting in this context as it just bundles the whole runtime with the package, which is terrible for size of packages and doesn't net a lot of benefit since they are also now tied together - if there is a security flaw you now must fix the entire binary and hopefully it still compiles. (edit: technically swift did this a long time too... but they also were reasonably sure they could include their runtime with the OS itself once ABI was stable, I am not sure if Deno has a path for this or if we just get fat binaries forever)

- top level await is a weird one to me, there are valid reasons its not in node currently. but yeah- no one likes having to write janky init code to work around this

final edit: I have a lot of opinions on this and would love to learn more about why deno is great. from what I can tell, its just a faster language of js which, imo, is great. But the points drawn from GP are just bizarre to me.

Re: The Deno Company

#280

Post by zastrowm »

tannhaeuser wrote: post #209
Griffinsauce wrote: post #99

Earlier quoted context omitted.

Deno's permissions are per-process though, it's a big jump for sure, but also still leaves the door wide open for abuse by dependencies of any serious project.

How is that different from Node.js which also runs in a single process? Or does Deno create per-request processes (or v8 "isolates" etc) like CGI does?

I think the point was that it's not different from Node.js - and thus not much of a benefit.

If it was more along the lines of "I want to use this array helper library, but it shouldn't have any permissions" then it would be a lot more useful, but right now if your Deno app needs any file or network access, then all of your dependencies get access too.

Post reply on HN