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

101–110 of 446 posts

Re: The Deno Company

#101

Post by hinkley »

int_19h wrote: post #91
oblio wrote: 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 :-)

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

What I learned about myself working as a NodeJS developer:

I’m okay writing JavaScript as long as I don’t have to spend all day every day writing it.

Re: The Deno Company

#102

Post by bluejekyll »

int_19h wrote: post #91
oblio wrote: 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 :-)

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

With WebAssembly, now you don’t have to. You do need a JS shim to load the WebAssembly, but after that, pick your favorite source language that can target wasm.

Re: The Deno Company

#103

Post by int_19h »

lucacasonato wrote: post #11
kostarelo wrote: post #10

From the last paragraph: > But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common. Why is WebAssembly a key concept here? How does Deno uses it?

We use it for the hash module in our standard library for example: https://deno.land/std@0.91.0/hash . The wasm version is magnitudes faster than a pure JS implementation. Another example is sqlite, running in WASM: https://deno.land/x/sqlite@v2.4.0 . Fully sandboxed sqlite :-)

It will be the ultimate irony if, 20 years down the line, Deno is still around, but solely as a de facto standard / cross-platform WebAssembly execution engine.

Re: The Deno Company

#104

Post by spion »

prussian wrote: post #77
beaconstudios wrote: post #33

Earlier quoted context omitted.

Node is only just now getting around to adding promise based APIs to the core. Any time you interact with the Node core APIs you have to drop back to using callbacks - that's at least one area where Node is behind the times.

util.promisify() seems to work for many of the node stuff I use a lot, like pipeline(), readFile(), etc. Perhaps require('xyz/promises') is a newer development.

do you really want to keep util.promisifying everything? I know I don't.

Streams (and event emitters, and the ecosystem bits that rely on them) still haven't fully caught up with promises either, e.g. async iterators and generators are still quite awkward

Re: The Deno Company

#105

Post by juancampa »

spark3k wrote: post #98
celeritascelery wrote: post #85

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

There's a big difference between "interpreted" and "JIT compiled". Both of these end up JIT compiled in most cases

Re: The Deno Company

#106

Post by tomxor »

sublimefire wrote: post #81

Deno makes sense in a variety of situations. The build pipelines of Typescript are excessively complicated and Deno hides that complication away (less dev effort). Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes. I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), clien…

This probably either sounds nuts or over opinionated but I don't think the NPM ecosystem is as valuable as people think it is... stuff is deprecated continuously anyway - when you find a way to move away from 10k dependencies (because your shortsighted previous self decided to depend on a single package without looking closer), it's a damn relief. I hate how needlessly complicated the NPM ecosystem is, I would actually like it if no one built bridges to Deno, it could be a clean start with lessons learned.

Most of the packages on NPM are complete garbage - most not all - (and I say this as a full time JS dev who actually likes JS), liking the technology does not have to mean liking what people do with it, and JS is the worst, both in terms of the crap on NPM and the web.

Re: The Deno Company

#107

Post by dgellow »

IAmNotAFix wrote: post #97
celeritascelery wrote: post #85

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

And because web app publishers have full control. If I have a web application, I can update it right now and it will be updated for ALL my users at the same time. No store policies bullshit, no need to somehow notify users that a new version has to be downloaded and installed, no fragmentation of your user base because half of your customers stay at an old version due to whatever reasons out of your reach.

Re: The Deno Company

#108

Post by int_19h »

tsujp wrote: post #12
kostarelo wrote: post #10

From the last paragraph: > But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common. Why is WebAssembly a key concept here? How does Deno uses it?

You can write in other languages beyond JavaScript or TypeScript and generate WebAssembly. This means that say someone wrote a nice library or utility in C# you can compile that C# down to WebAssembly and use that library or utility in JavaScript or TypeScript (or anything else that can access WebAssembly). This is analogous perhaps to C# and F# within .NET currently. C# and F# have the same BCL (base common layer) s…

WebAssembly would be analogous to CLI (Common Language Infrastructure) in .NET land, which includes CIL (Common Intermediate Language - bytecode) and CLR (Common Language Runtime - VM).

.NET BCL is the Base Class Library. Outside of a few classes in it that are fundamental to the runtime (e.g. Object, String, Array), it's not actually required for cross-language interop on .NET platforms. E.g. if you have two different C compilers both outputting CIL, they can interop just fine without any objects in the picture. WebAssembly interop is really more like that, and doesn't have the high-level object model layer that .NET also has (and which is used in practice).

Re: The Deno Company

#109

Post by k1rcher »

bluejekyll wrote: post #102
int_19h wrote: post #91

Earlier quoted context omitted.

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

With WebAssembly, now you don’t have to. You do need a JS shim to load the WebAssembly, but after that, pick your favorite source language that can target wasm.

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

Re: The Deno Company

#110

Post by burlesona »

IAmNotAFix wrote: post #97
celeritascelery wrote: post #85

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

The OP didn’t sound like it was referencing client / server applications, rather writing native applications using web abstractions.
Post reply on HN