The Deno Company • Hacker News Board

Re: The Deno Company

#121

Post by TimTheTinker » Mon, Mar 29, 2021, 2:05 PM UTC

tomxor wrote: post #106

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

> I don't think the NPM ecosystem is as valuable as people think it is

Its value is less about the existing dependency tree of libraries and more about how many apps directly depend on libraries that are npm-hosted.

There are many 200+ kloc apps out there making millions/yr each that deeply depend on libraries and frameworks hosted in npm.

Re: The Deno Company

#122

Post by eatonphil » Mon, Mar 29, 2021, 2:05 PM UTC

glutamate wrote: post #115

eatonphil wrote: post #72

Earlier quoted context omitted.

I don't understand the connection being made between having a bytecode compiler and being a scripting language.

Java is definitely not a scripting language

Is JavaScript? Python? Ruby? All major implementations of all three are bytecode compilers/VMs.

Re: The Deno Company

#123

Post by marcosdumay » Mon, Mar 29, 2021, 2:06 PM UTC

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…

> Or if it just exists because JavaScript developers don’t want to learn something new.

Looks to me like they don't want to write stuff twice, and they would have had to write for the web anyway.

The web stack is not good by any measure. The native GUI toolkits are suffering form abandonment, so the web-based toolkits are among the best available (but not at the top). But if you don't have any reason to expect to create web code, your life will be better if you ignore the stack.

Re: The Deno Company

#124

Post by skrebbel » Mon, Mar 29, 2021, 2:06 PM UTC

throwaway99x99 wrote: post #54

xiaq wrote: post #47

Earlier quoted context omitted.

Sounds to me that they will build some sort of hosted service or maybe PaaS based on the Deno runtime (like AppEngine or AWS lambda), but yeah it's pretty vague.

> Sounds to me that they will build some sort of hosted service or maybe PaaS based on the Deno runtime (like AppEngine or AWS lambda) or like Joyent

How did Joyent manage to turn Nodejs into money though? I mean weren't they mostly selling unix services?

Re: The Deno Company

#125

Post by sublimefire » Mon, Mar 29, 2021, 2:07 PM UTC

oblio wrote: post #89

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…

I think raw (framework-less), modern (no J2EE, Spring) Java is most likely a much better language than raw, modern Javascript. Plus, aren't Deno libs compatible with Node libs?

> much better language

Maybe but who cares when your code does not execute instantly on Lambda and requires you to use GaalVM to convert bytecode to binary. Besides you have a lot of people who would say Kotlin is better.

Javascript, like Python wins here. Well Javascript kind of wins because it is interpreted but devs do not use it directly but rather with a bundler/compiler.

> Plus, aren't Deno libs compatible with Node libs

Not really, if your dependency relies on say `https` module then it'll not work on Deno as it does not have it. And in the case of Deno modules, they are not on `npm` to begin with but even if you import them then they are written in Typescript.

Re: The Deno Company

#126

Post by bin_bash » Mon, Mar 29, 2021, 2:07 PM UTC

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…

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.

Re: The Deno Company

#127

Post by marcosdumay » Mon, Mar 29, 2021, 2:08 PM UTC

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.

For web programming, WebAssembly is still not enough.

It solves the problem of how to run your non-web based code in a browser, but until it can interoperate with the DOM, JS will continue to be mandatory.

Re: The Deno Company

#128

Post by 40four » Mon, Mar 29, 2021, 2:08 PM UTC

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…

Respectfully, your comment is way off topic, and nothing to do with discussing The Deno Company, and what it means for the Deno ecosystem. Not to mention, this is a very worn out, tired complaint that's been talked about ad nauseam. Reading angry swipes at web developers is not very interesting.

Ok, you're not a web developer. So you stick to what pays the bills, why would you learn Node or Typescript? Same for web developers, why would they learn C++ or haskell? Some will take interest and cross over, some won't.

Who cares? Pretend like Deno doesn't exist and the world will continue to turn.

Re: The Deno Company

#129

Post by numpad0 » Mon, Mar 29, 2021, 2:08 PM UTC

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 New Way prints money much more reliably. It gets more people involved in the process. It forces deeper coordination across communities in and out of tech, strengthening connections.

The old way gets _your_ job done _effortlessly_. idk, I guess that’s not ideal in the meat world.

Re: The Deno Company

#130

Post by giobox » Mon, Mar 29, 2021, 2:09 PM UTC

k1rcher wrote: post #109

bluejekyll wrote: post #102

Earlier quoted context omitted.

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

I’ve long been of the opinion you must learn JS today regardless of what your preferred language might be - it’s more or less (thanks to browser vendors and the web) the closest thing we have to a “zero” dependency runtime on all platforms. Learning a WASM based workaround to avoid learning JavaScript is not helping you or the products you might want to make. There is a huge ecosystem of existing JavaScript code to adopt or extend in the client out there too. Expecting or wishing the market to bend to your preferred language or style is an often great way to become a very unhappy developer.