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

81–90 of 446 posts

Re: The Deno Company

#81

Post by sublimefire »

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), client side bundlers (eg webpack), serverside frameworks (eg express), etc. But because Deno is solving some of the issues for those who run sensitive code in production (eg Lambda functions) it'll most likely gonna become another VM on the public cloud providers' list.

All in all Javascript interpreter is becoming something like a JVM. Everyone wants to use it but without writing vanilla Javascript.

Re: The Deno Company

#82

Post by mellosouls »

I understand that the authors have very strong pedigree in their field, but given a lot of the motivation stems from regretted node design decisions, is the rust etc expertise on the project deep enough to not make equivalent mistakes that will be rued in another few years?

Genuine question (I assume it is, but presumably it was before with c++) - it just strikes me that once something becomes as successful as node, and given that nothing is ever perfect it might be useful to clarify why the technical insight might be better this time around - at least regarding the idioms of the underlying tech; the added experience at the architectural and implementation side a given.

Re: The Deno Company

#83

Post by nerdponx »

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…

This is probably a stupid question, but is AGPL/commercial dual-licensing a viable option for something like this? Instead of relying on goodwill donations & maybe assigning 1-2 devs from major corporations, just explicitly charge them money if they refuse to ship source code to end-users.

Re: The Deno Company

#84

Post by bryanrasmussen »

q-big wrote: post #74
bryanrasmussen wrote: post #62

Earlier quoted context omitted.

no they're not, a large number are - maybe 13% https://www.moneycontrol.com/news/science/13-people-are-path... , what it is is that most people just aren't that self-aware or have a better opinion of themselves than is perhaps warranted. So let me make clear here, if I ever start a company based on open source principles and it looks like I am going to get squeezed out of business by Amazon if I keep sticking to thos…

> So let me make clear here, if I ever start a company based on open source principles and it looks like I am going to get squeezed out of business by Amazon if I keep sticking to those principles I will probably abandon those principles (unless I'm already a billionaire and have something really cool I want to work on anyway) because damned if I would let Amazon beat me. The chance of my abandoning those principles…

I don't really see myself as ever wanting to start a company under open source principles as I believe the whole Elastic / Amazon situation is highly instructive in this regards, at any rate none of the projects in my big projects list relies on being open source for gaining traction.

Re: The Deno Company

#85

Post by celeritascelery »

> 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 something like this I realize how much in the minority I am. I am not a web developer. I have never written JavaScript before in my life. I hate working with “web-first abstractions”. I feel like it is just massive bloat on top of true native application. But given the popularity of things like electron, react-native, Node, and Deno I don’t speak for the majority.

And the thing is, I don’t know if I just learned web dev if I would love this new approach to software that is eating the world and I would “get it”. Or if it just exists because JavaScript developers don’t want to learn something new.

Re: The Deno Company

#86

Post by user-the-name »

bayindirh wrote: post #17
kostarelo wrote: post #8

> Extending web programming beyond the browser is not a novel idea. Indeed, we have done that with moderate success in our “Node.js” project. But over a decade later, we find server-side JavaScript hopelessly fragmented, deeply tied to bad infrastructure, and irrevocably ruled by committees without the incentive to innovate. As the browser platform moves forward at a rapid pace, server-side JavaScript has stagnated.…

[flagged]

Literally everyone has seen this. There's no chuckle.

Re: The Deno Company

#87

Post by oblio »

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.

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

Re: The Deno Company

#88

Post by tannhaeuser »

gorjusborg wrote: post #23
oauea wrote: post #7

I've always been very skeptical of the value-add of Deno over Node, and this only increased my skepticism. Good luck making money, I guess.

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.

> a standard library (thank goodness!)

What's a "standard" for you? Whatever definition, I think it implies there are > 1 implementations of it.

Node.js is based on CommonJS APIs, an initiative lead and implemented by earlier server-side JavaScript (SSJS) runtimes at the time such as v8cgi/TeaJs, Helma, etc. until Node.js dominated SSJS around 2011. Remember, SSJS is as old as the hills, starting 1996/7 with Netscape's LifeWire, and arguably has seen even longer use than Java as a mainstream server-side language.

Also not a "standard" in the above sense is TypeScript.

As to "standard library", the core packages on npmjs plus package.json are the standard library of Node.js on top of core Node.js APIs, and were developed in that spirit.

Re: The Deno Company

#89

Post by oblio »

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?

Re: The Deno Company

#90

Post by sbarre »

not_knuth wrote: post #71
sbarre wrote: post #28

Earlier quoted context omitted.

I'm not sure that they meant those specific runtimes would be premium products. My read was that anyone could more easily configure a runtime to expose (or not expose) the underlying bindings that it requires, vs. just having them all in there by default. I think "us" in that statement is the Deno community, not Deno the company. But maybe I'm wrong.

Clicking around the website and reading more comments leads me to believe that this is the product they intend to monetize with: https://deno.com/deploy I still find it strange that there is no mention of it in the post...

That makes sense...

So if you're up for it, you can still roll your own deployment infrastructure and tailor your builds as needed etc.. and support all of that internally.

Or you can pay Deno to handle it for you and you can focus on building your apps.

Post reply on HN