Live data from Hacker News

The Deno Company

deno.com

201–210 of 446 posts

Re: The Deno Company

#201

Earlier quoted context omitted.

I'm not sure what you think could qualify Node as not keeping with the times, if not implementing the modern standard for async interfaces isn't it.

I agree with you that it would be nice if more of core supported promises, but I think there are probably plenty of examples of them keeping up with the times or charging ahead as well. Top-level await and optional chaining are a couple features that come to mind.

true, the language-evaluation side is keeping up. But isn't that just a case of integrating newer versions of v8? NodeJS doesn't implement its own JS engine.

Re: The Deno Company

#202
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…

Is the VSCode support good? I tried using Deno with WebStorm a few months ago and it wasn't a great experience.

It's getting there! They finished a rewrite of the extension recently and it's quite nice.

If you're on Windows like me, sadly there's still a nasty bug with path mismatches between the LSP server and the VSCode extension (https://github.com/denoland/deno/issues/9744) which requires reloading the window to fix spurious errors, but I'm sure it'll be fixed soon enough.

Re: The Deno Company

#203

Earlier quoted context omitted.

This is fascinating. As someone who programs primarily in Python, I have been struggling with adapting to a JS-heavy environment in the past several years. I have began utilizing Node + React for frontend use cases but find that my build pipelines become incredibly cluttered and esoteric rather quickly. Am going to explore wasm solutions, thanks :)

As someone who programs primarily in Python, I have been struggling with adapting... Would you mind providing some more details here? After Python packaging drove me batty for the last time, I wouldn't have described the switch to JS/CS/TS as "struggling"? With respect to "build pipelines", you don't have to use grunt, gulp, etc. It's totally fine to have regular bash commands in npm scripts.

Hm... I think the biggest issues I experience have more to do with frontend design rather than composing JS itself.

I love using it as a "one-off" scripting language which usually involves interaction with some sort of an existing codebase.

I'm also fairly confident in doing any sort of backend-centric work, in which existing components most likely exist as well (or at the very least something POC-esque to iterate on or scaffold from).

With that said I believe most of these difficulties stem from most of my experience being backend-centric roles, so when it comes time to implement a frontend from scratch, I become unsure of where to start. The sheer amount of technologies available and vast amount of flexibility is also very intimidating.

However I've been slowly but surely immersing myself in the stack(s), and have found that much like my experience with CSS the best way to learn is to simply do it-- making mistakes and learning from them in my exploratory learning.

I do appreciate what you said about build pipelines and feel much better about my current projects :-)

quick edit: I think my lack of experience in functional programming is another factor here, however Typescript's object orientated style is very attractive.

Re: The Deno Company

#204

Earlier quoted context omitted.

Unfortunately Deno gave up on their most unique differentiator, the TS [runtime].

We most certainly did not, TypeScript is and continues to be a primary concern for us and we plan on continuing to support it as a first-class citizen of the ecosystem

Is Deno still going for TS runtime?

> Deno is a runtime for JavaScript and TypeScript that is based on the V8 JavaScript engine and the Rust programming language.

Re: The Deno Company

#205

Earlier quoted context omitted.

No we didn't?! Where did you get this info from? Deno is made to work with TypeScript out of the box. The Deno Standard Library is written in TypeScript: https://deno.land/std . Most userland modules are TypeScript too.

Wasn't a TypeScript runtime the original Deno selling point? Didn't the project have to pivot away from that?

They had to remove it from the Deno build process so Deno internals didn't need a compiler. However TypeScript support remains untouched and receives constant updates

Re: The Deno Company

#206

Earlier quoted context omitted.

You're talking about control of the hardware/filesystem/etc, I'm talking about control of the application itself.

You're talking about the relationship between publisher and platform, and how there are web wins in the direction of managing and updating apps. But those wins must also be balanced with the loss of control due to those same platforms distrusting your app. Now your app, for all the wins it's going to achieve on maintenance and updating, is also going to take hits from its inability to do things that other people take…

Of course. Everybody here is aware of the tradeoff of using web technologies versus native ones. The fact that I emphasize what I see as the strongest benefits doesn't mean I'm not aware or ignore the tradeoff.

Re: The Deno Company

#207

> Many are more familiar with the Chrome DevTools console than they are with a Unix command-line prompt. More familiar with WebSockets than BSD sockets, MDN than man pages. Bash and Zsh scripts calling into native code will never go away. But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common. Many developers, we think, prefer web-first abstraction layers. Every time I read so…

Electron and React Native aren't popular because they're in JS. They're popular because you can write the application once and use it cross-platform. Mac/Windows or Android/iOS.

Electron is popular because when your application is in JavaScript writing and improving plugins for it is a breeze.

That was what propelled Atom and VSCode.

What you said is valid of course when you look at Slack and such, but you ommited most important cross-platform target.

Your app can run on Windows/Linux/Mac .. and the Web.

Re: The Deno Company

#208
post #87

Earlier quoted context omitted.

> Or if it just exists because JavaScript developers don’t want to learn something new. It's probably a big reason. But if you think about it from the other angle... you don't want to learn Javascript, which would be new to you :-)

Touché. I will admit I am resistant to learning JS. Part of this is that it seems like no one actually "likes" to program in it, they just have to because it is so ubiquitous. But I guess that just goes back to the Bjarne Stroustrup quote: "There are two kinds of programming languages: The ones people complain about and the ones nobody uses."

> Part of this is that it seems like no one actually "likes" to program in it

JavaScript consistently ranks as one of the most loved languages in Stack Overflow surveys...

I find plenty of counter-examples of this point on HN too - engineers who have worked across many different stacks and rank JS/TS as one of the best dev experiences they've had (there is one such comment in this comment tree)

Anecdotally, I feel as if pre-ES6 a lot of the complaints you read online were from users of the language. Nowadays, it's as if most of the complaints are from people who don't use it.

I think there is something to be said about refusing to learn anything but JS, as knowing different languages can be a boon for an engineer, but I believe it's an excellent tool to have in one's belt nowadays.

Re: The Deno Company

#209

Earlier quoted context omitted.

I recall Ryan regreting nodes full-permission approach. Not every script should be able to access the fs for securities sake.

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?

Re: The Deno Company

#210

Earlier quoted context omitted.

No we didn't?! Where did you get this info from? Deno is made to work with TypeScript out of the box. The Deno Standard Library is written in TypeScript: https://deno.land/std . Most userland modules are TypeScript too.

Wasn't a TypeScript runtime the original Deno selling point? Didn't the project have to pivot away from that?

No. Nothing has changed about Typescript support since 1.0. It is just as well supported as JS. We never removed support...
Post reply on HN