Live data from Hacker News

The Deno Company

deno.com

91–100 of 446 posts

Re: The Deno Company

#91
post #87

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

> 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 :-)

Speaking for myself, I have already learned JavaScript - I just don't want to have to use it.

Re: The Deno Company

#92

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

They answered this at the end of the article: “The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains.”

It takes time to learn an ecosystem, and when people know one ecosystem and not another, most people would rather do high skill, high value work in the ecosystem they know than start over as a noob in a new one.

The only thing unique about the web / JavaScript land is its ubiquity and size due to its place as the language of the browser. So anyone who can make an abstraction that lets JavaScript developers do stuff outside the browser without learning much new has a virtually guaranteed large audience of developers who are likely to think “I would love to be able to build X, I just don’t have time to learn a new ecosystem.” Those folks are then thrilled to dive in and use the new abstraction. And there are a lot of those people. And that’s why we are all stuck using Electron apps for so much stuff. :)

But that doesn’t have to be a bad thing. Electron can evolve to be less of a resource hog, and better alternatives are being tested all the time. The same is true for other non-browser applications of JavaScript.

I don’t know if this vision is reality, but I think that it may be that we’re in the early days of a transition toward the browser stack being the new “GUI.” Which is to say, back in the 80s there was a lot of debate around GUIs and whether they were a good idea etc., and while most people liked them to some degree, they also lamented the idea of losing the command line. But in the end, GUIs didn’t shrink the number of CLI tools in the world, rather they increased the size of the domain that computers are used for my making it more accessible to more people. I think that so far the web vs native debate seems to be following a similar trajectory.

Re: The Deno Company

#93

Earlier quoted context omitted.

I've only dipped my toes in the water with Deno, but it solves a few pain points I've felt with Node. Direct deps via url vs npm as middleman, a standard library (thank goodness!), and single binary distribution. Types are great too, but these other things would be enough for me.

The built-in Typescript support is amazing, but the selling feature for me was the ability to generate static binaries. Shipping is much easier when your built process can produce a single output!

You've been able to do that with Nexe for Node.js apps since basically forever.

Re: The Deno Company

#94
post #26

Earlier quoted context omitted.

Yeah, no kidding.. shots fired... As someone who uses Node but doesn't closely follow the steering/proposals side of things, I can't say I had this impression of that process.. Is Node really that bad compared to how JS/ES is innovated on in the browser?

That's very subjective As an outsider who likes to lurk, I have the impression both ECMA and Node committees are stuck in the "we're nice and therefore right" field. They made technological choices that broke the platform (eg. require vs import). It took ages of pain to innovate on things that matter (eg. promises, async) I wish Deno the best, but I'll just try to stay away from JS from now on (same as I've been avoi…

Interesting... thanks for sharing some insight.. :)

Re: The Deno Company

#95
I know this sounds crazy on the surface level, but I really wish I could do data engineering and machine learning with TypeScript instead of Python. TypeScript's type system is so good, it makes refactoring large projects so easy. Python's typing module leaves a lot to be desired, and on top of that PyCharm doesn't properly support everything. Perhaps I should switch to VSCode--but I do like IntelliJ, and it works really well for TypeScript.

Re: The Deno Company

#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. The practical use of LuaJIT is still very niche though. The lack of a comprehensive standard library, and being forever stuck on Lua 5.1 makes it even less generally appealing. I still love it for programming Nginx though..

Re: The Deno Company

#97

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

The web is eating the world because it's the easiest way to ship an application. It has nothing to do with whether developers like to do it or not.

Re: The Deno Company

#98

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

Typescript / Javascript have significant reason to exist in their own right.

Re: The Deno Company

#99

If I understood correctly this is how they intend to make money: > Not every use-case of server-side JavaScript needs to access the file system; our infrastructure makes it possible to compile out unnecessary bindings. This allows us to create custom runtimes for different applications: Electron-style GUIs, Cloudflare Worker-style Serverless Functions, embedded scripting for databases, etc. So it's basically more of…

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.

Re: The Deno Company

#100

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

AFAIK it hasn't been faster for a while, especially not in the GC area.
Post reply on HN