by elisee on 3/29/21, 11:31 AM with 431 comments
by franciscop on 3/29/21, 12:50 PM
"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."
"If you watch our conference talks, you will find we've been hinting at commercial applications of this infrastructure for years. We are bullish about the technology stack we've built and intend to pursue those commercial applications ourselves. Our business will build on the open source project, not attempt to monetize it directly."
PS, if I was a rich investor I'd throw money at this project even as a donation, so no complain at all, but I'm very curious on the monetization plan.
by elisee on 3/29/21, 12:07 PM
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 the types just as we're serving the script files, so that there is no extra build time, it feels like TypeScript is Web-native and we can share typed code with the server.
[1] Not yet launched but we ran a preview past weekend with hundreds of players over WebSockets: https://twitter.com/MasterOfTheGrid/status/13757583007179735... - https://sparks.land
by davnicwil on 3/29/21, 1:21 PM
> Our infrastructure makes it possible to... create custom runtimes for different applications [like] Cloudflare Worker-style Serverless Functions
Fascinated to see what happens here. The serverless / edge compute paradigm fits Javascript hand-in-glove philosophically, but until now it's always felt quite clunky to me. When I've tried it out, I've always been left thinking "but this would just be so much easier with a server".
Reading this has made it click for me why that is. A new paradigm needs a new set of tools native to that paradigm.
The entire server-side JS ecosystem is currently structured around Node, a fundamentally stateful-server paradigm. You can try to abstract over it, but only so far. It's not the serverless paradigm that's clunky, per se, it's that the tools right now were built for another way of doing things.
As a concrete example - Deno has an import system based on URLs, rather than on-disk node_modules. I thought that was a cool feature for convenience, less overhead, more open and sharable packages, etc. But now I realise the full intent of it. It's much more than all that, it's a fundamental shift in the paradigm: no implied dependency on stateful disk in the runtime itself.
by kostarelo on 3/29/21, 12:00 PM
wow lots of bold statements there. And another one for the usual "JavaScript is fragmented, let's create another tool to fix 'em all.".
by sublimefire on 3/29/21, 1:30 PM
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.
by ravenstine on 3/29/21, 4:22 PM
- Typescript as a first class citizen
- An actual `window` global with familiar browser APIs
- Sandboxing w/ permissions
- URL-based imports (no need for NPM)
- Bundling into self-contained binaries
- Things like top-level-await which Node.js still treats as experimental.
- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks)
To me, those aren't just minor details. This has the potential to create a new epoch in server-size JavaScript.
by kibleopard on 3/29/21, 3:07 PM
And is that really worth dumping loads of money into developing further? I just find it hard to believe people are going to bother with Deno any time soon - we’ve gone too far down the NodeJS road.
by not_knuth on 3/29/21, 12:16 PM
> 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 a Redhat approach to making money from open source? They intend to build tailored services on top of Deno for companies that request them?
by munro on 3/29/21, 1:43 PM
by madjam002 on 3/29/21, 2:04 PM
by oauea on 3/29/21, 11:57 AM
by syrusakbary on 3/29/21, 12:07 PM
Keep up the great work Ryan, Bert & team. Exciting times!
by alfl on 3/29/21, 11:53 AM
We were consultants scaling node to production for a major international bank, circa 2016.
Love the security improvements in deno, will have to give it a look.
by turadg on 3/29/21, 3:36 PM
The leading app framework for that is Nextjs and I hope the Rauch Capital investment sígnals Vercel will be supporting Deno.
Anyone know?
by Woung1938 on 3/30/21, 11:09 AM
$ deno run --unstable --allow-write=output.png https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/hello-triangle/mod.ts
Download https://crux.land/2arQ9t
Download https://crux.land/api/get/2arQ9t
error: Import 'https://crux.land/api/get/2arQ9t' failed: 404 Not Found
at https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/deps.ts:4:0
Another one:
$ deno run https://deno.land/v1.8/permission_api.ts
error: An unsupported media type was attempted to be imported as a module.
Specifier: https://deno.land/v1.8/permission_api.ts
MediaType: Unknown
by kostarelo on 3/29/21, 12:01 PM
> 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?
by jedahan on 3/29/21, 3:01 PM
Clicking on 'Learn more about Deno Deploy' leads to https://github.com/apps/deno-deploy , which does not tell me more.
What does 'act on your behalf' mean for Deno Deploy?
by huhtenberg on 3/29/21, 12:47 PM
Anyone else is running into this?
by mellosouls on 3/29/21, 1:32 PM
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.
by VWWHFSfQ on 3/29/21, 1:43 PM
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..
by spark3k on 3/29/21, 1:12 PM
by feb on 3/29/21, 2:53 PM
Why is the Mozilla Corporation an investor in a Chrome based technology startup ?
by nilshauk on 3/30/21, 11:05 AM
My only gripe with the Deno company is that taking investor funding is a double-edged sword. Yes, they'll get to hire very skilled developers. However naturally the investors want a tidy exit, and I wonder if that would be to be bought out by Amazon, Microsoft or Google.
Edit: Just realized that there's a key difference in that Deno does not have something like NPM to be bought and sold because dependencies are URLs and thus decentralized. Also, Deno itself is open-source.
by paperwork on 3/29/21, 5:52 PM
I can see that Deno.listen returns an object which implements reader and writer interfaces, but it isn't clear to my how to look for events, such as disconnect or that new data is available.
I wish there were examples showing how to correctly parse frames or implement protocols.
I'm sure these things will be expanded over time, partly by programmers in the community, but from the outside, things are still a bit rough.
by TheMagicHorsey on 3/29/21, 4:20 PM
Well, I wish they would stop using it period, but at least in the browser it makes some sense.
Edit: to be clear, I have no beef with Typescript, Dart, Clojurescript, and the many other languages that compile into JS. It's JS itself I have issue with. I feel like it gives too much flexibility to young programmers to screw things up. There don't seem to be enough safeguards or training wheels. On large projects its my nightmare.
by xixixao on 3/29/21, 7:21 PM
I know this might be hard to see, but Rust is actually in the same domain. It is also, among other things, enabling product/frontend/web engineers to build backend/native/browser-less applications.
I'd bet Rust will be more successful here, especially given its amazing ability to change itself and innovate.
by latexr on 3/31/21, 9:56 AM
Many developers, I think, don’t look past web-first abstraction layers.
I can’t tell you how many times I’ve seen CLI tools which are huge chunks of node wrapping a thin bash command. They are multiple files, orders of magnitude larger than they need to be, and require external dependencies because these developers are fixated on their proverbial hammer.
by bullen on 3/29/21, 3:06 PM
It uses comet-stream instead of WebSockets.
But it's fully "joint" parallel on all cores.
by loopback_device on 3/29/21, 3:41 PM
In my opinion, the best part of node is (or was) that it didn't adhere to the browser APIs. That brought in some fresh air, and gave us buffers, native bindings, streams etc.
by rglover on 3/29/21, 1:58 PM
by justicezyx on 3/29/21, 7:14 PM
Ryan and the team should be capturing some of the value produced by their creation. And because of Deno's a developer tool, it's actually capturing the far minor part of the whole value and enable a much bigger value creation!
by Freknf on 3/29/21, 2:18 PM
Trying to sell something based on FUD is always a bad sign.
by ChrisArchitect on 3/29/21, 4:28 PM
by _qua_di_q_ on 3/29/21, 6:45 PM
However, I personally would prefer Go or .NET Core for my backend any day. We need to wait and see where it's going ...
Good luck and success anyway!
by PudgePacket on 3/29/21, 12:15 PM
by colesantiago on 3/29/21, 11:49 AM
by camdenlock on 3/29/21, 5:42 PM
by appleflaxen on 3/29/21, 1:08 PM
My sense is that GPL3 gets a ton of criticism on HN, but isn't it the perfect defense against freeloaders?
* license the code for proprietary use in your stack * use GPL3 if you have a non-commercial use, and are willing to accept the requirement to open source your own code.
I don't understand why this option isn't used more by open source projects that want to be able to fund themselves.
Can anyone explain? (Even better if there are examples / case studies)
by kizer on 3/29/21, 2:55 PM
Also, it's nice that they're using Tokio for the HTTP server instead of a JS implementation (from what I understand). I want to see Deno near the top of the TechEmpower benchmarks.
by semitones on 3/29/21, 3:34 PM
by csbartus on 3/29/21, 1:06 PM
by skratlo on 3/30/21, 3:08 AM
Haha, this made me laugh hard, stopped reading
by celeritascelery on 3/29/21, 1:35 PM
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.
by gnrlst on 3/29/21, 12:12 PM
by psim1 on 3/29/21, 1:00 PM
Most popular, I can agree. Fastest, & only one with industrial standardization process? Have they met Erlang?
edit: you have to be kidding me, downvoted to oblivion for an honest observation. Sorry I hurt javascript's feelings.
by Freknf on 3/29/21, 2:13 PM