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

291–300 of 446 posts

Re: The Deno Company

#291

Post by schnable »

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. -…

> An actual `window` global with familiar browser APIs

This doesn't seem good?

Re: The Deno Company

#292

Post by paperwork »

I'm excited about Deno, but I'm finding that the docs still need to be improved. For example, I'm trying to build a tcp server. I'm not able to get information on how back-pressure is handled.

I can see that Deno.listen returns an object which implements reader and writer interfaces, but it isn't clear to my how to look for events, such as disconnect or that new data is available.

I wish there were examples showing how to correctly parse frames or implement protocols.

I'm sure these things will be expanded over time, partly by programmers in the community, but from the outside, things are still a bit rough.

Re: The Deno Company

#293

Post by ericlewis »

seer wrote: post #285
ericlewis wrote: post #278

Earlier quoted context omitted.

- 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 an…

While I also think url based imports are a weird idea, it might just stem from the fact that I haven’t used it much, it might be wonderful, who knows. But what I’d like to question is why the idea of parsing everything is considered bad. Semver itself, while miles ahead of what came before, is still just lies we tell the compiler. You can never actually rely on the fact that a miner fix will not be a breaking change…

I've used imports in this manner before and the issue with having a non-centralized place where packages defined has 2 sides:

1. people will import packages willy-nilly and not think about what they are doing and it becomes harder to understand WHAT they imported (the why becomes more clear imo), I am aware that is very much so JS culture today but I also believe that to be harmful.

2. Having to parse all files to find deps takes time, obviously not a ton of time, but it takes time, it simply doesn't scale appropriately

Working in finance - I think personally that it is really important to make changing the dependency chain something everyone should be VERY aware of.

Re: The Deno Company

#294

Post by ericlewis »

hombre_fatal wrote: post #290
ericlewis wrote: post #288

Earlier quoted context omitted.

top-level await isn't really trivial implementation or action wise. But as a feature it seems obvious until you step into all the edge cases it can create.

It's cute for scripts. Otherwise there's the trivial top-level wrapper runProgram.catch(console.error) entry point. It's just not a detail that does much to sell Deno. Though I admit it's not that fun for me to come in here to poopoo Deno.

I am not trying to do that either - I think the work they're doing is great and important, but the reasons listed above ain't it.

Re: The Deno Company

#295

Post by ravenstine »

ericlewis wrote: post #288
hombre_fatal wrote: post #283

Earlier quoted context omitted.

Those still are all trivial in the "too little too late" sense. URL-based imports are already something you can do in package.json if you really thought that was great. Top-level await really is trivial. The permissions system does very little for you since they are process-level permissions when I'm scared of transitive dep attacks. Typescript in Node is good and Deno has to catch up in tooling. If Deno was where it…

top-level await isn't really trivial implementation or action wise. But as a feature it seems obvious until you step into all the edge cases it can create.

Care to share some examples of said edge cases?

I write a lot of short JS files that aren't part of a big cohesive backend, and little things like top-level await make the code somewhat easier to read. Yes, you can just do an async IIFE, but that's just another thing for the eye to parse and feels quite vestigial.

EDIT: And since I can't respond to your other comment, I'll ask this here; what do you consider great and important about Deno that doesn't fall under the bullet-points I listed? I'm simply curious.

Re: The Deno Company

#296

Post by cozuya »

elisee wrote: post #15

Happy to see Deno get some financial backing! I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use. The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip…

Are you running multiple cores/threads of deno? If so how are you holding/communicating state server side?

Re: The Deno Company

#297

Post by rhencke »

threatofrain wrote: post #265
lucacasonato wrote: post #223

Earlier quoted context omitted.

Heck yeah

I don't know where I got so misinformed. I thought Deno had stopped going for a TS runtime.

Unfortunately, the words "Deno", "TypeScript", and "removal" made for good headline material, and what was effectively a design document about performance optimization[1] became misinterpreted by many as heralding the removal of TypeScript from Deno, despite the document being updated with a explanatory warning that it was a very deep technical document about a specific part of architecture, and that Deno remains completely committed to supporting TypeScript forever.

1: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...

Re: The Deno Company

#298

Post by paxys »

srmarm wrote: post #64
franciscop wrote: post #42

Nice to see! How do they plan to monetize? I either became blind or missed it somehow. The article does say how they DON'T plan on monetize: "Rest assured that Deno will remain MIT licensed. For Deno to grow and be maximally useful, it must remain permissively free. We don’t believe the “open core” business model is right for a programming platform like Deno." There are some hints though: "If you watch our conference…

Looks like https://deno.com/deploy will be a managed service - the implication seems to be that the default option will be to use their CDN to run code with an option to DIY if you prefer.

I'll be very surprised if "quick and easy hosting" is still a viable business model, considering how crowded the space is by now.

Re: The Deno Company

#299

Post by ericlewis »

j-pb wrote: post #289
ericlewis wrote: post #278

Earlier quoted context omitted.

- 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 an…

- I've had the typescript compiler do WEIRD errors on me, depending on configuration, a zero configuration, no brain environment is a godsent - it makes a ton of sense if you don't want to maintain two different versions of the same library. With WASM there is zero need for Node native modules anymore, so there is no need to have platform specific idiosyncrasies that go beyond Web APS's. Is the fact that it's called…

- TS also lets anyone do whatever they want so not a great thing to support, I have always said TS would be better if people couldn't configure it without a PR to TS itself

- we have the chance to define a new and better API, we should do it - you are already adopting something different

- I agree, but its not a selling point, these things are probably in containers already and my OS should be doing most of the work

- window: just no, call it global if you must. perpetuating ideas like this isn't good for anyone but the lazy.

- I think the cmd aspect of shipping a whole binary is cool for sure, but lets not conflate this as a "compiled language" its not. you are shipping a runtime and a scripting language together.

Re: The Deno Company

#300

Post by ericlewis »

ravenstine wrote: post #295
ericlewis wrote: post #288

Earlier quoted context omitted.

top-level await isn't really trivial implementation or action wise. But as a feature it seems obvious until you step into all the edge cases it can create.

Care to share some examples of said edge cases? I write a lot of short JS files that aren't part of a big cohesive backend, and little things like top-level await make the code somewhat easier to read. Yes, you can just do an async IIFE, but that's just another thing for the eye to parse and feels quite vestigial. EDIT: And since I can't respond to your other comment, I'll ask this here; what do you consider great an…

I think deno is really interesting in the aspects of how it is parsed and handled, I have a lot of hope they can continue to do cool things with it too. I would like to continue seeing them take strong opinions on things that improve the language, and hope to see it evolve beyond javascript. But thus far - it has been: stealing code from node.js and taking strong opinions on things that make the overall DX worse. Deno's strength will being a scripting language on its current path.

Edit: just realized I gave no example.. an example would be a dep that has gone missing and there is no backup for it. Deno sort of handles this but all we have actually added is no centralized way to describe dependence. So if you dynamically import a package via its package manager you also need to write some code to ensure it even exists. how is that better?

Post reply on HN