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 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."
Does anyone have some insight into those? I haven't watch any Deno talk (maybe one actually?) so it feel a bit strange to make people watch technical talks to find hints of the monetization strategy.
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.
Looks like https://deno.com/deploy will be a managed service - the implication seems to be that the default option will be to use their CDN to run code with an option to DIY if you prefer.
How does this business model survive Amazon AWS making a blog post, "Here's a template to run your deno code on Lambda!"? They'll never beat AWS on costs in the long term. They can burn VC cash to stay afloat and try I guess.
AWS sucks hairy balls at providing things that are simple for developers to use, so that could be their competitive advantage, but I'm just guessing here.
I find the idea that AWS will just eat the competition always a little silly as well. I've used AWS managed offerings that were far inferior to the alternatives.
Usually because the company already pays an AWS bill. No one will care if you add another Lambda function, but to use an alternative you’ll have to get past some gatekeepers.
And yet we've never seen anyone beat Amazon yet. Look at how much the PaaS area has churned over the last 10 years. Giants that stuck around like Docker are completely deflated and near worthless compared to their initial values and expectations. The smart ones like Heroku got out when the getting was good.
> And yet we've never seen anyone beat Amazon yet.
That largely depends on your definitions of "beat" and "win". There are plenty of software infrastructure firms out there that Amazon has yet to smash into the ground.
Nature seems to think (and I agree) simply existing is winning.
Lambda uses containers vs. cloudflare workers use v8 isolates. v8 Isolates are much much faster and more secure for serverless functions.
Deno seems to be targeting cloudflare as a competitor for their service... But it's probable that AWS will release a cloudflare worker competitor themselves if deno continues with the MIT license.
> Lambda uses containers vs. cloudflare workers use v8 isolates. v8 Isolates are much much faster and more secure for serverless functions.
You're right that v8 Isolates are blazing fast, but Lambda runs functions in a microvm spawn by Firecracker [0], which is likely to be more, not less, secure than Isolates [1].
> Firecracker [0], likely to be more, not less, secure than Isolates [1]
This is debatable. It's true that V8 is a much larger attack surface than Firecracker, therefore likely to have more security bugs than Firecracker itself. However, Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs when you're working from JS / Wasm and can control the code generation.
Ultimately I don't think you can really say one or the other model is more or less secure.
(Disclosure: I'm the tech lead for Cloudflare Workers so I am obviously biased here.)
> Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs...
I see your point. I mean, Google wouldn't put as much effort as they are on gVisor if KVMs were the best possible answer.
To be fair, gVisor also runs native code directly on hardware. Any modern VM-based system is still depending on the CPU to enforce boundaries. A big CPU bug could ruin that at any time. (Spectre has been pretty bad, but not quite a showstopper...)
That’s the goal of almost all startups. Your chances of being acquired by a FAANG company are millions of times greater than going IPO. It is almost always the exit strategy.
Workers is now a much capable platform. It supports eventual KV storage, caching large files, longer runtimes (30m+), WebSockets, WASM-executables, and distributed mail-boxes àla Erlang.
Lambda integrates with existing AWS services, whilst Cloudflare invents newer services to go along with the serverless-first paradigm. Different strategies but they do compete with each other.
Eh, Vercel pulled it off rather well with Next.js. Given that Guillermo Rauch is an investor in Deno, I wouldn't be surprised if they partnered in some way.
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.
Many companies would just never touch an AGPL package, and while there are other languages out there with commercial licenses (e.g. Delphi), those are not nearly as mainstream as the open & freely available ones.
Deno is competing against Node.js, which is MIT-licensed. Deno is arguably better, but it would have to be _so much better_ to get people to even give it a second look if it was commercial.
That's why you dual license, which is significantly more approachable. "This is AGPL/GPL unless you pay $200/month per developer seat" is a common licensing scheme for frameworks, people aren't scared by it.
In some places, the people who hold the purse strings are rather far removed from the actual developers, that it's a lot easier to just go with something that's "free".
I think this is one of the reasons why cloud computing monoliths like AWS are so successful. It's way easier to set up a $50/month VM on AWS then to get permission to spend $5/month on a VM elsewhere.
Enterprise sales requires paying salespeople for their network of potential customers and time to reach them. The sales cycle is long and risky for companies that can't absorb the cost of the sales salary and time to get revenue.
Unless you have a ridiculously good relationship with a handful of organizations or a perfect system for fitting into existing infrastructures, it's a big mistake to care about selling something to those organizations.
AWS is popular because it's free for companies with a high potential for getting big (like YC companies) and they can absorb the costs of the sales cycle.
> This is AGPL/GPL unless you pay $200/month per developer seat" is a common licensing scheme for frameworks, people aren't scared by it
Really ? I can think of QT - but that's such a huge body of work with some very specific use cases in which it doesn't really have competition (aside from DOM based shell for UI maybe, but that has it's own problems and is often a hassle to get working).
In this case Node is established, Deno is going to have an up hill battle to gain that mindshare on equal footing, adding a licensing restriction would probably kill it off the ground.
We most certainly did not, TypeScript is and continues to be a primary concern for us and we plan on continuing to support it as a first-class citizen of the ecosystem
Insofar as we take `.ts` files seamlessly yes -- though to be clear, one does not simply "run" TypeScript. There are no runtimes for TypeScript directly (there's AssemblyScript that _looks_ like TypeScript, but isn't exactly TypeScript)
We've simply incorporated the type-checking and transpiling steps into the deno cli, making it super simple to get going, no config needed.
Shouldn't require caveats, with the caveat being that there is no runtime for TS.
There is reason to believe that the extra information given from TS typings could be carried into runtime wins, and so there is absolutely pent up demand for an actual TS runtime.
Exactly. And I guess the package still needs to be compiled to JS before deploying to production? To avoid shipping a full TS compiler on a production server which would be a crazy thing to do.
No we didn't?! Where did you get this info from? Deno is made to work with TypeScript out of the box. The Deno Standard Library is written in TypeScript: https://deno.land/std. Most userland modules are TypeScript too.
I do find the messaging to be confusing, because what would you think I meant if I talked about the runtime of Elixir or Scala?
This is the marketing line on the front page of the Deno project:
> A secure runtime for JavaScript and TypeScript.
They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.
I can understand where the confusion comes from, but I think it's a matter of context. I would never have thought that they would want to build a runtime that runs TS directly. The effort would just be insane.
Hence the implied step that TS needs to first be transpiled to JS before getting executed in the runtime was always in the back of my head and I'm guessing this is the way most people think as well.
And from a black-box perspective, whether TS first gets transpiled to JS or run directly doesn't make a difference. In that sense one could argue that it is a "TS runtime". This is a petty semantics-fight I don't want to get into though and I've probably already said too much :).
If you are interested in something that gets close to a TS runtime though, have a look at AssemblyScript [0]. It compiles to WASM and tries to keep most of the syntax of TS. Very interesting project imo.
I feel like people are talking past each other here.
To me "TypeScript runtime" means running TypeScript in a mode that runs faster than JavaScript by actually using the type info to generate better machine code. It does not mean translating to JavaScript at runtime and running in V8.
For example at one time there was an experimental version of Chrome that had a Dart Runtime. A quick google finds this HN thread when they decided NOT to have a dart runtime
So can we get clear? Does Deno plan to execute TypeScript natively (not via V8 or via a heavily modified V8) or are the plans to continue compiling TypeScript to JavaScript internally and actually just run JavaScript
Unfortunately, the words "Deno", "TypeScript", and "removal" made for good headline material, and what was effectively a design document about performance optimization[1] became misinterpreted by many as heralding the removal of TypeScript from Deno, despite the document being updated with a explanatory warning that it was a very deep technical document about a specific part of architecture, and that Deno remains completely committed to supporting TypeScript forever.
No, because TS hints should also be able to translate to runtime savings.
I do find the messaging to be confusing, because what would you think I meant if I talked about the runtime of Elixir or Scala?
This is the marketing line on the front page of the Deno project:
> A secure runtime for JavaScript and TypeScript.
They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.
They had to remove it from the Deno build process so Deno internals didn't need a compiler. However TypeScript support remains untouched and receives constant updates
I don’t remember “TS runtime” as you’re meaning it ever being pitched. I don’t think Ryan would consider that in scope for Deno unless MS wanted to collaborate on it.
I do find the messaging to be confusing, because what would you think I meant if I talked about the runtime of Elixir or Scala?
This is the marketing line on the front page of the Deno project:
> A secure runtime for JavaScript and TypeScript.
They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.
I would say no. I think they should go public domain, as that's the future.
One of the funniest/best business models out there is SQlite (https://sqlite.org/copyright.html). They give it away to the public domain, but some lawyers wrongly claim that that is not enough, so they will "sell" you a warranty asserting it is all public domain.
Patent/copyright insurance? Sounds good, and not difficult to get a check written for, considering how much is spent on the service of open-source scanning.
Glad to see I'm not the only one having a hard time figuring out just how they intend to make money. My best guess was that they will offer a tailored Deno to companies that want to embed it (my comment about it is swimming somewhere here).
Other than that, there is the following vague statement at the end of the post:
> The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains.
Ah I read that statement in the end like it'll enable front-end devs to also write back-end code, like Node.js but better (APIs follow more the browser than in Node.js), but I didn't think it'd be related to the monetization?
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.
In other words, capitalise on the decreasing quality of software engineers by offering services to them at a high price because they don't have the ability to make any of these services themselves.
There's a semi-joke that goes "all companies are software companies now" but there is a lot of truth to that..
It comes to down where a company wants to put its effort.
Do you want to own/operate/maintain all your infrastructure and services (and all the challenges that come with retaining scarce talent that is capable of that work), requiring you to substantially invest in an area that is not core to your business?
Or do you want to spend that money (and let's be real, less money too) to pay a trusted third party provider who will do a better job than you would anyways, because that's their area of expertise?
Then you can focus your (likely limited) resources on delivering value to your business instead.
Any of the big 10 tech companies wouldn't mind owning this if it becomes the standard way of developing back end JS. It gives them influence and the ability to lock out competitors.
I know this isn't the SV-approach to things but maybe they intend to offer consulting services for those looking for some expertise with the ecosystem, bill hours, and retire in their 50s as millionaires instead of billionaires.
This might be surprising, but not everyone is looking to be a unicorn.
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.