I’ve never been interested in JS as I mostly work in C++ but the ease of install/use of Deno over Node made me actually want to try it. It’s nice to have access to a bunch of web tech with a single binary. Very excited to see where this project goes!
I played with an early version of Deno a few years back and it was already way more comfortable to use than node. It's a real counterexample to second-system syndrome.
The only reason I didn't continue was a lack of ARM support.
It was a few years back and I was mainly playing with a few early projects. I was very productive, but wanted to target my Raspberry Pi and it just wasn't there. I ended up going 100% rust instead.
There are still no RPi builds as far as I am aware, which is a shame as there are now Mac silicon builds so not sure what the hold up is. I do wonder if there are.more Raspberry Pi's out there than M1/M2 Macs :)
The M1 builds are made manually by us, as github doesnt provide any runners. the same problem does apply for linux arm, however we don't have any arm linux systems any one of the members use; and building on a pi is a no-go, as that can take 70+ minutes, so that would make our release cycle a lot more complicated. Either way, we are investigating potential possibilities besides waiting for github to have runners available
Have you tried building in a rpi virtual machine on a Mac? I have no idea what the performance would look like, but it’d be easy enough to try, especially since you are already managing your own max builders.
I want to say I followed these instructions for doing so recently:
I had a very different experience. I very much wanted to make it work, but trying to use it with existing npm packages and import maps was incredibly painful, and I ultimately switched over to node for that project.
I think they should get a reasonable return. Deno has a lot of hype and Node has a lot of cultural weight, as does Ryan himself. Not sure about unicorns though! It does not seem like a unicorn product, but I'm not a VC
VCs see a tiny chance that it can be a 100X return. So raising $20M at say a $50-100M valuation now, that means betting on a $5B+ exit. In return for getting money to take a shot at that level of artificially-fueled revenue growth, the founders are willing to cede control of the community to professional financiers. As others wrote, that's the VC model: make a ton of these bets, and as long as 2-4 turn out, the lottery winners pay for the bankruptcies.
Given every big company uses JS, and thus many SaaS VCs have JS in their annual set of thesis bets, it's reasonable that Deno got picked by a top group given their team & growth. Same story with npm, netlify, etc.
I wish the team luck in hitting significant revenue in the next 9-12mo, as that will determine a lot of what happens to the community. A lot of pressure & culture change to work through!
The main base expectations are that out of all of Sequoias bets, some will become $5B+ co's, and for the next 18mo, deno can grow headcount with salaries unrelated to sustainability
Some people involved might expect more, and I'm sure hope for more, but I'm a language designer & CEO, not a mind reader :)
What is their actual business model? I know there's Deno Deploy, and presumably they offer some kind of enterprise-support type deal. But the first is easily copied by competitors (in an already-crowded market), and the other isn't super lucrative. Is there anything else?
I love Deno and want it to succeed, but it doesn't feel like a unicorn, and I'm worried about it being expected to become one
Open source ecosystems that become big enough often end up either producing unicorns, or failing that, producing unicorn-level returns for existing companies.
There’s no guarantee that the creator of the ecosystem will be one of the unicorns, but they’re as good a bet as any other company to pull it off. VCs aren’t looking for 100% certainty, just a plausible path.
Warren Buffett only invests in companies with what he calls a "moat" that make it hard for any other company to offer a similar product or service.
Apple's moat, for example, is its institutional knowledge of design and maybe its relationships with its suppliers, e.g., their deal with TSMC to lock up most of TSMC's capacity on the 5-nm node. Another moat Apple has is consumers who do not like engaging in sysadmin battles with their consumer electronics. One of my friends, a 79-year-old woman, for example, told me once that she wouldn't consider buying a computer from any company except Apple. (I could probably induce her to change her mind on that, but it would take persistence and patient explanation on my part, and also I'm probably the only person who could change it.) The main way Apple has maintained (for 38 years!) its dominance in institutional knowledge of design is probably the fact that most of the young talented designers want to work for Apple (partly because most of the people willing to pay extra from good design in consumer electronics buy from Apple).
Google Search's moat seems to be institutional knowledge on how to build a good search engine and access to data on what people search for and which search results they click. Strengthening the latter moat is the reason they're so interesting in having all traffic from the consumer's browser encrypted: namely, so that the consumer's ISP cannot sell data on the consumer's interactions with Google's search engine to any competing search engines. Another moat Google has is that most consumers will not take the trouble to change the default choice of the search engine used when the consumer types a non-URL into the location bar of the browser. Strengthening that moat explains Google's willingness to pay Apple and Mozilla to be the default search engine and Google's interest in giving away Chrome and Android.
Microsoft's moat: practically every organization uses computers and needs employees who know how to use those computers. They mostly choose Windows and Office because that is what most prospective employees know. In turn, when a young person improves his or her attractiveness to prospective employers by learning computer skills, they usually choose to learn Windows and Office because that is what is running on the computers of prospective employers.
The three companies alone do have these moats but are outliers of outliers. Stuff we haven’t seen much of before. Combined they are worth $5.5T. All US public companies are worth $40T. The Nasdaq that they are all in has a total market cap of all companies of under $20T. Besides the two mentioned exchanges, Shanghai, and Euronext, these three companies alone might come up 5th in total market cap. They are right alongside Tokyo and Shenzen. Definitely dwarf Hong Kong and LSE.
The other big moats off the top of my head aren’t as strong but ASML, TSMC (for now), Tencent, Baidu, Yandex, Kakao Daum, are all worthy but still peanuts comparatively. I’m sure some Indian companies too.
Facebook has a sizable moat: it is easy for me to join a new social network, but it is kind of pointless unless everyone I want to communicate with also joins, and it is hard to motivate them to do so. The fact that Facebook was not the first social network is evidence that that kind of moat can be crossed, but still it would be hard. And if a company starts getting traction, FB will probably offer to acquire it like they did Instagram and WhatsApp (which never was a social network, but might've become one by gradually adding features if it hadn't been acquired).
But I agree with your point: it is really hard for a new company to create a large revenue stream with a strong moat around it.
Considering that one of those competitors is Netlify, then either the incumbent (i.e. Netlify) is in a great position to benefit from a succeeding Deno, or Deno Deploy does succeed and Netlify can profit from that. A bunch of other participants (GitHub/Nat Friedman, Automattic) seem like they could benefit from a thriving ecosystem around Deno as well, even if Deno Deploy isn't particularly successful.
Netlify Edge Functions use Deno Deploy, as do Supabase Edge Functions. I'd imagine that's a significant part of their revenue.
(I work at Netlify, but have no insight into the financials of this arrangement)
I genuinely don't even understand it. I was either taught wrong, learned wrong or this doesn't make sense. O(100) is constant time, so it's no different to saying O(1) or whatever, I've only ever used O to talk about how we care about the time complexity of a function, e.g. comparing linear time to quadratic time. 1 is the same as 100, irrelevant.
I think they're trying to communicate that those are worst case latency numbers. You're correct in that formal use of Big O notation doesn't distinguish constants.
It's that easy to raise money these days, at the 10% inflation mark. Spin up a webpage full of nonsense promises and they'll come chasing after you to take their cash.
I'm not sure, I'm pretty sure they're trying to communicate that these are worst case estimates. ~100 seems like it's communicating average case estimates (big theta notation), which isn't really the same thing
Big Theta isn't "average case". It describes an algorithm with the same asymptotic lower and upper bounds. How would you even formally define an average case, when the result depends on the input?
I would read ~100 to mean "approximately 100", while O(100) to me reads like "measured in the hundreds". So 200-600ms cold starts are O(100) and 3-7s cold starts are O(1000).
As a second data point, I added the same effect to my blog back in, I don’t know, 2002 and all my friends complained about getting a headache as well, so I turned it off
For some reason it never had that same negative effect on me
I suspect that it basically confuses your brain because it tries to adjust the "white balance" so that the background becomes normal white. But the background is just saturated enough and changing so quickly that it just can't follow.
Unfortunately browser's don't really give you an easy way to control this. Changing system-wide settings just because one website is bad is quite the ask ask.
Same, and a bit of a persistent queasy feeling. I think it’s something to do with how it’s slightly off white but pulsing, so your brain tries to cancel it out.
It reminds me of the feeling after surfing when you lie in bed with your eyes closed and still feel the waves going up and down.
Hot take: investors really are stupid enough to think ”servers/datacenters are a massive cost for large companies. A serverless solution should save them lots of money”
It's not a hot take, it's just a bad take, and a complete failure to understand the value proposition of these types of offerings (and why we're seeing so many of them pop up these days)
> are there real-world, commercial products actually running on """serverless""" architecture?
Yeah, thousands I would imagine. The last two companies I have worked at have been 100% serverless or nearly 100%.
> no matter how much I think about that whole concept, I see no application for it that couldn't be done better, faster and easier with regular tools
Considering you have to ask if there are _any_ products running in a serverless environment, I would imagine you need more exposure to the concept before you make such a large judgement on it.
I'd rather not list my last two companies or their scale, but I can assure you they are real companies that exist, have users, and make money. I'm not sure why I even would be asked to.
> Yeah, thousands I would imagine. The last two companies I have worked at have been 100% serverless or nearly 100%.
If you can answer (for legal or other reasons you might not be able to): What kind of monthly bills did your setup have and how many req/s did you serve (in lack of a better metric)? It'd also be useful to know average min/max response time if that's something you remember.
I wish that was a good way of evaluating "performance / price" but that's really hard... If someone know a better way to frame the question regarding price, it would be very helpful.
I can't list that, but both companies migrated to serverless and both companies are glad they did.
There is more than "raw dollar amount on monthly bill" to account for in cost, as well. For one, there's stability and the toll that takes on both your team and your customers. Not saying non-serverless apps are not stable by nature, but I've now been part of two teams that have seen the same types of benefits and those benefits line up with the "sales pitch" benefits.
I'm not particularly interested in serverless but my understanding is a developer doesn't need to know the server configuration and drops some code in. The service figures out how to route the domain to code and handle the storage, caching, etc
I rather know my configuration and use one big server with the static files on a CDN
Yes, there are many real-world completely serverless products and architectures. I've been working exclusively on serverless architectures for many years now, I have no plans on going back to provisioning servers or working with containers.
It depends on what you categorize as “serverless”. I wrote about how Khan Academy is built on essentially serverless architecture and has millions of monthly users:
There's plenty of real-world, commercial products which do not get extremely high loads but earn much more money on each request. They're mostly in B2B without sexy names and media coverage, though.
In my opinion (and at most places I've worked) serverless has been a great _complement_ to traditional deployment models (usually k8s).
For example, you have some background tasks (sending email, processing files, etc). It's very convenient to just push those into a queue and have serverless functions chew through them. They scale to zero, cold start time has no negative impact on the workload, you don't have to worry about k8s resource requests and scaling, etc.
I too am skeptical of using any serverless offering for serving HTTP API's or server-side rendered pages, atleast for non-trivial amounts of traffic. CloudRun can do it but only because it's a thin management layer on k8s/knative and even then networking config for anything other than CloudSQL is tedious (you have to deploy a proxy to access your VPC).
Running little processes on the server without the VM/K8s expensive abstraction has a lot of potential. I'm sure Deno will do great! At least this way of deploying web apps has a lot of potential.
It’s amusing to see a whole generation of senior developers (“senior” as in 5+ years of experience) that haven’t experienced web development without React[0] and who proceed to reinvent PHP/ASP.NET/RoR.
[0] Used here as shorthand for “modern js driven development”
Nobody is reinventing PHP or RoR development. What is happening is the community taking all our favorite parts of these stacks and combining and implementing them in ways that facilitate a dev experience that we could only have dreamed of back in the PHP/RoR days.
- Senior dev that started off in the PHP and then RoR days
Another developer here who’s been around for the tech you mention.
The evolution has been 2 steps forward but 1 step back. It’s how many complex systems evolve and it’s fine. Just because you see that some problems/solutions resemble what you saw 10 years ago doesn’t mean nothing was improved along the way.
We could really do without this kind of snark here. Not only is it condescending, but it's also just plain wrong, either on purpose or due to the writer not being familiar with the subject at hand.
Personally I've been using both PHP and Node/React extensively and let me tell you there are very good reasons for the React/Node/JS ecosystem to exist and they are decidedly not borne out of ignorance of the PHP ecosystem. Ryan Dahl (inventor of Node and Deno) said that he created (paraphrasing) "the PHP of this generation" and React was invented within the probably the largest PHP shop to date.
PHP is an unsafe, slow by default (execution model - the language itself fast), hard to use well, clunky, limiting and bloated language that is kept together by duct tape and the incredible effort and ingenuity of it's open source community by educating developers and improving/cleaning up the language at full blast, unfortunately often by breaking backwards compatibility.
Whether JS (including Deno) is a good alternative or the right answer is up for debate. But people who try to mimic some of the benefits of PHP in the JS ecosystem are not doing so accidentally or because of lack of experience.
Been writing web stuff since before the dot-com bust. Preact + TypeScript is probably my favorite front-end programming combo yet. I liked VB6 and C# WinForms, though, so maybe I’m an invalid sample.
C# WinForms was super comfy for when you just wanted to throw together some simple GUI tool for internal use. As powerful as WPF and similar frameworks are they definitely lose to WinForms in ease of use.
WebForms was WinForms for the web and for all the criticism it got, it was amazingly productive. The new Blazor framework is finally approaching that speed of development again.
I changed my view on this―I hated how things were going full circle. But in reality, human civilization loves overdoing a particular direction and then reverts to the mean. You see this with the economy, moral fashions, everything.
I am an optimist in that I (have started to) believe that this slowly allows us to converge on better solutions for everything.
PHP was easy to set up, easy to host, easy to understand and easy to build stuff with, but it resulted in an unmaintainable mess over the long run.
Then Node was all of that, but JS was a better language than PHP. Then Node grew warts in the form of the clutter that is npm, then it grew complex build systems and unstable libraries.
Now there's Deno. It uses TypeScript by default, which is a surprisingly useful and productive language, it rethinks some things, it's much more secure by default, and now we're back at the PHP-level easiness to host using Deno Deploy.
We've ended up with an overall better solution and it only took us 20 years :)
Lambda and most similar technologies use variants of containers, not VMs.
Outside HN that distinction might not be important. Here being pedantically correct does matter on this because the VM abstraction has been around for a long time, whereas containers were an enabling technology for serverless.
And containers and the fast startup, security and resource consumption guarantees they offer is a big difference to the old days of shared PHP hosting.
And this is why "reinvention" with new technology is different.
Firecracker is a virtual machine monitor (VMM) that uses the Linux Kernel-based Virtual Machine (KVM) to create and manage microVMs. Firecracker has a minimalist design. It excludes unnecessary devices and guest functionality to reduce the memory footprint and attack surface area of each microVM
It's worse this time, in that the old shared hosting environments (e.g. Apache with FastCGI and suexec, or nginx with fpm) were open source, and there were countless shared hosts. The new generation of multi-tenant isolate-based JS runtimes are proprietary, and AFAIK one can count the number of hosts on one hand.
Anyone who has had to maintain a shared PHP server would say that's very different. I used PHP for years, and now use serverless functions (both Lambda and Deno). Serverless means you don't need to worry about anything except the code. It scales automatically. It never needs updating. It doesn't go down in the middle of the night. It can roll back deploys instantly. Sure, you could pay for managed hosting, and then pay more for scaling, and set up automation for deploys, but give me serverless functions any day of the week. They just work.
Where's the angle for the investors - what will Deno do to produce the returns necessary for such a high amount? I thought Deno would be the eradication of Node and bring stability to Javascript. From the outside it seems to be firmly on it's way to being just another Zeit/Vercel. :(
CloudFlare workers is on my radar because of an ecology of other "edge" products that are in the works or already released. That's what Deno would need to catchup on to be on the table for discussion for me. Otherwise it remains a toy I use in my spare time (which I do enjoy at the moment).
As someone who dabbled with both workers and Deno Deploy: Deno Deploy actually works.
I was very excited about the idea of workers but their tooling is (or at least was when I tried it last) abysmal, buggy and hard to understand. To this day I don't know how to setup a basic dev vs. production in workers.toml. Local debugging was buggy for naked domains (even found a GitHub issue for it that languished for months with no bugfix or clear explanation / workaround) and very slow.
Great idea killed by poor dev tooling.
Deno deploy is the opposite of that: deploys are instant and it's obvious how to deploy. You can develop and test locally.
Cloudflare released wrangler v2 (which dropped rust for node) and maybe it's better now but the one experience I had with wrangler v2 was trying to deploy a small static website (pages) and it failed due to their backend throwing 50x errors.
So much so that I wrote Denoflare (https://denoflare.dev/) to make writing Cloudflare Workers using standard Deno a breeze: no wrangler, toml, webpack, npm etc required
Neither is Deno Deploy, really. The limits on CPU time etc are very similar, with Cloudflare being more flexible on CPU and Deno Deploy being more flexible on bundle size.
Yes Deno Deploy is for HTTP (just like CF Workers) but my point is that Deno is more of a generalist runtime compared to Workers and has a much broader appeal than just Deno Deploy.
Here's an example. Deno is like any other backend runtime and has regular DB clients. CF Workers do not. If you want to use Workers with PG, the CF docs point you to Supabase which provides REST over PG using PostgREST.
With all due respect, there's a point I think you're missing here.
What I'm saying is that, even if you're only going to use Deno Deploy, it is an objectively better proposition because Deno (the runtime) has a much broader use case.
Would you rather use something that (for now) can only be used on a single cloud provider for (let's call them) "edge HTTP" workloads and integrations with services of that single cloud provider...
... or use something that can be used on any cloud/hosting provider, for any HTTP workload (plus many other non-HTTP use cases), which also happens to have an "edge HTTP" service custom tailored for it?
And let's not forget, Deno (the company), is much more focused on real developer needs. Workers still have a mediocre DX (although it has improved considerably lately) and still no framework for Workers like Fresh.
I'm happily deploying Deno projects to Cloudflare Workers. Outside of Deno.* (not like any isolate-based serverless thing has processes or files), it's all APIs specced by browsers.
Interesting how this will play out. It's an ambitious goal to consolidate client side and server side javascript ecosystems which is quite fragmented today. On the other hand, this may only increase fragmentation further by introducing another target to develop for (wait for transpilers that can automagically convert between deno and node code). I will always look at javascript as this problem kid that cannot get its shit together in life, perpetually chasing the romance of utopia.
There is already a system for building a NPM node package from a Deno package, called dnt (deno to node). It's maintained by some Deno team members. Here's a blog post they wrote about porting "Oak" (a deno HTTP server framework) to Node: https://deno.com/blog/dnt-oak
The nice thing about Deno conceptually, is that it's much more similar to the browser platform than node is. It uses ES6 only, has things like `fetch` built-in by default, and generally follows browser standards around interfaces like Request, Response, etc. Instead of needing a complicated build process to make Node code work on the browser, now we have a complicated build process to make Deno/Browser code work on Node. ¯\_(ツ)_/¯
Not to take away from the rest of your message, I thought you wanted to get up to speed on that `fetch` is now available in nodejs core since version 17 or something like that (think it got included early this year).
That's an old blog post; the current release is 18.4.0, which supports `fetch` without a command-line argument. You do get this warning the first time it's invoked, though:
(node:340760) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
Javascript is Typescript - TS is a superset of JS, so valid JS is valid TS, although you'd almost certainly get lint errors in dev complaining about lack of types.
Can the same build pipelines be reused for CF/Fastly workers? The DX for workers is horrible with multiple buggy Wrangler implementations and zero observability into deployed workers.
It's a battle of ideals, you could have have a high entropy ecosystem that's constantly evolving and perhaps "appears" unstable, or an ecosystem that's "gotten it's shit together" and probably trends toward stagnation and apathy
Deno code is really close to browser code. If you have ESM code that runs in the browser and doesn't need access to the DOM then it's a good bet it'll run on Deno, and vice versa. They use web standards for most things, and anything proprietary is put on the Deno global object. For standards that need adapting to work outside the browser, they're working with Cloudflare and others on WinterCG, which is defining a common baseline for these non-browser runtimes.
I do think Deno is a step in the right direction, by reducing the need for transpiler steps (e.g. TS to JS) and embracing JS standards instead of building their own (which is what NodeJS did, but this was in a time when JS had no standard for dependencies or per-file isolation).
Comments are a bit negative. I for one think they are onto something here. Surprised it's only 21M. I would have expected in these market conditions to beef up more for the next 2-3 years.
Indeed, especially when you compare with a company such as Supabase (which is working on way less interesting technology imho) who just raised $80M: https://news.ycombinator.com/item?id=31328783
Deno probably would have raised $80M if they'd raised the same time Supabase did. Investors got quite a bit more tight fisted between January and April.
Can someone more knowledgeable highlight what kind of security model do these Deno deployments have compared to virtual machines and containers, if they are isolated at the process level.
You're expected to read it out loud (in English), where one of the conventional readings of O(f) is "order of f". Conveniently "order of 100" is usually taken to mean not asymptotic behavior bounded by a constant multiple of 100, but a range within an order of magnitude or so of 100.
Which is to say, they're saying Deno has a cold start time of ~100 ms, package size ~10M, a physical machine can support ~1k instances.
cool, it is good to know but, at the same time, it is weird. I would use x convention to deliver that message. That comparison table is there for a reason and that is to deliver a marketing message. I'm sure there could be some better ways to deliver that message.
This question is going to make me sound like a jerk, but why do you want to write your back-end in JS? Deno looks like a great improvement over node.js, but I don't feel compelled to use it. It seems like people jumped to node based on some performance promises that didn't really pay off (IMO). And since then, we have newer options like Rust, Go, and Elixir as performant back-end options, and even older choices like Ruby and Python have continued to improve.
Seems like the standard arguments would be that developers already know JS, and that you can share code with the browser. I don't find these highly compelling.
EDIT: I haven't learned typescript yet, based on the replies, it seems like that could be a good reason to choose it. Seems like a nice middle-ground between typical scripting and compiled languages.
Not OP, but one answer I've often heard and experienced myself is that statically typed datastructures feel painful when you come from dynamic languages like Python, Ruby or JavaScript.
> Rust seems complicated. I don't think I'm smart or committed enough to get anywhere with rust.
Rust is a bit rough yet to do the front and backend development, but IMHO it will catch in a year or two. Also for backend rust now with (actix and axum) looks pretty similar to expressjs, so you will feel like home there, but for the frontend there's still no killer framework nor a settled architecture that fits better rust model.
>I never want to write Go that interacts with a database again.
I LOVE Go ! I think it's the bee's knees until you have to write DB code ! I'm hoping "go generics" will take care of some of the table-mapping/orms/multiple-types etc madness.
You're kinda stuck writing JS on the frontend. The (only) advantage of also using it on the backend is that you can share code. In some cases, I could see that being compelling.
FWIW, I think Typescript would make an even stronger case. And I think(?) that's one thing Deno is trying to do.
Sharing code is great, I've moved processing between backend and front-end or even share the same code in both. Makes SSR+SPA possible using the same code.
Typescript is a must for me, but I don't need Deno for that. I haven't used beyond scripting but for the time being I don't see a mayor benefit over node or ts-node other than easier/zero project setup.
I use Deno from time to time, and in my opinion more than a back-end language it's a really powerful scripting language. Being able to reference libraries by URL and the Go-like standard library mixed with Typescript async makes it a breeze to develop simple one-use CLI tools!
It uses typescript predominantly, and only compiles down to JavaScript. (I think you can code in plain JavaScript directly but I don't think anyone would want to do that)
The benefits are in my mind not that you can share code directly but more that the std lib is the same (mostly) between backend and frontend. This means no mental context switching for developers.
The other bonus is that typescript is just such a lovely thing to code in. Expressive, universal and ubiquitous, performant - modern JS is a joy to use (...if you don't need to use NPM... If you need to use NPM at all then it is a shit show)
I may be the odd one out, but for me node.js (and hopefully in the future Deno) isn't about the backend, but instead it's a pretty nice scripting environment for tooling and automation. I've been using mainly Python for this in the past, but got burned out quite a bit by the python2=>3 transition.
(but still: don't underestimate the raw performance of V8, for many things it's definitely good enough)
I completely understand what you're saying, but Python is a lot better now. You don't have to worry about Python 2 anymore and the tooling is a lot better as well (Black, Flake8, Poetry are all really nice).
I've written up an at-scale production backend in Node.js and can very much stand by the decision to use Node over Elixir or Go (which I was considering at the time). I think fundamentally, the power of a JS-based backend is its pragmatism--it's not the best at most things, but it comes very close to it in so many categories that it's a safe option for a lot of use cases.
> It seems like people jumped to node based on some performance promises that didn't really pay off (IMO). And since then, we have newer options like Rust, Go, and Elixir as performant back-end options, and even older choices like Ruby and Python have continued to improve.
I'd agree that Node.js performance is generally not the best reason to be writing a backend in it since a static language will often yield better performance, but for the amount of dynamic power you get, it's extremely performant by default[1]. The next most performant dynamic language for I/O is, like you said, probably Erlang/Elixir, but V8 is generally understood to have better CPU-bound performance than BEAM.
> Seems like the standard arguments would be that developers already know JS, and that you can share code with the browser. I don't find these highly compelling.
I've found that developers already knowing JS is a very practical reason, if not ideological. I'm in a team with a lot of generalists who like to work full-stack, and being able to use the same mental models and syntax is a lot of cognitive load lifted off our shoulders. It also doubles the hiring pool of people who can hit the ground running on the backend, because now anyone who has experience with JS on the frontend can jump over to the backend with relatively little training.
The other key reason for a backend in JS is that the community is extremely large, which means that a lot of the troubleshooting I'd have to do in languages with smaller communities is done for me by someone who was kind enough to post a workaround online. This saves me a lot of time and energy, as does the plethora of packages.
And the performance argument isn't even just about CPU time, right? The fact that JS is heavily event-friendly, and all of its IO APIs are non-blocking by default, gives it an automatic advantage over busy-waiting languages like Python, and also languages where concurrency means writing threads manually. If your web server spends most of its time on IO (network, DB, file system), as many do, JS acts as a lightweight task-delegator to a highly parallel and performant native runtime.
I haven't worked on a large-scale JS back-end myself, but this is the case I've heard others make
Sure, if you use Python's async feature. But my understanding is that it's relatively uncommon; blocking IO is still the norm, right? I for one have worked in or around a couple of nontrivial Python servers, and I've never once seen an await statement. My understanding (correct me if I'm wrong) is that this comes down to it being newer, and having worse ecosystem support (more "synchronous-colored" APIs, less battle-tested frameworks, etc). It's not a first-class citizen like it is in the JS ecosystem [1]
[1] Technically JavaScript's async/await syntax came later, but it's just sugar over Promises which have been around for a much longer time, and those are built atop the event loop, which has been core to the language since day 1
In non-async Python, generally the thing that blocks is a thread -- something Javascript doesn't even have! A different thread will happily run in the meanwhile.
Right, but some other JavaScript on the same thread will run while a different piece of JavaScript is awaiting. That's why JavaScript can get away with not having threads. Also- any number of background threads will be running at any given time to read data off of disk, load and process network requests, load data from a DB, delegate commands to system processes, etc, in true parallel with the JS code. When one finishes, it'll put an event on the event loop and JS will pick it up when it gets the chance.
I've written backends using C#, PHP back in the day, a little bit of Go, Java and naked SQL, and I prefer Typescript language and npm ecosystem, hands down. May be not for writing highload distributed systems that are critical at RAM & CPU, but IO-heavy business logic where managing requirements and their changes is the hardest challenge, it's a godsend.
I think developers knowing JS/TS is a highly compelling argument given the fact that most companies are struggling to find any devs at all. I would argue finding Rust/Go/Elixir developers is going to be _a lot_ harder for a lot of companies than finding JS developers.
Also then sufficiently proficient frontend Devs have an easy in into backend development which has turned out to be a very good thing at 5 different companies I have worked for in the last 4 years.
In addition to that not every backend or service needs much performance. I have written quite a few services that get hit maybe 3 or 4 times a minute at best and Node was great for that. Actually I have yet to work anywhere where performance was limited by the language choice and not by architectural decisions or inconsidered use of databases and data structures. I am not saying this does not exist but it does not mirror my experience with the majority of companies at all.
I'd also say that despite npm and dependency hell being a real problem there is a vast ecosystem of packages out there. I know python has that going for it too. But Elixir is much less developed in that regard - simply by being less popular.
Sharing code with the browser can be really sweet. At a past job we used TypeScript, and I had whipped up some shared types that our API was forced to conform to, and that automatically generated a strongly typed API client for the frontend to use. Sure, you can do that with some other protocol or server like GraphQL/Hasura/writing up a JSON schema, but it was pretty sweet that A) any of our engineers could figure out how to make the endpoints they needed to implement a new feature, B) these types could generally be inferred from the actual API implementation without having to explicitly write types out which completely eliminated bugs around API misuse with minimal extra code, and C) all of the code we wrote followed the same linters, formatters, idioms, and utilities (fetching, logging, error handling, and so on). There are projects out now that wrap up a lot of what I had done like tRPC [1], as a testament to the value of the shared abstractions.
To me its very powerful to have the same developers do both front end and back end. With modern frameworks its probably easier for front end devs to do back end work than Rust/Go/Elixir devs to dirty themselves with JS. So even though ts is suboptimal it allows one language, one set of tools and developers.
- Synchronous execution + async-everything is a great combo.
- First class Promise abstraction.
- Good general purpose language. Its warts are mostly smoothed over. It's not like Javascript from 20 years ago.
I like writing Javascript. I certainly prefer it over the other popular dynamically typed languages. (I don't see what Ruby or Python offer me over JS as general languages)
Rust and Go make different trade-offs. I would never default to either for general purpose projects. Meanwhile JS is my default for networked code.
I like js too, but both python and ruby are much better languages. It's just that js won distribution, which means it won adoption, which means you have 10MM devs smoothing it's rough edges. Just to take one language feature, consider pythons list and map comprehensions. js has nothing like that - but it also has 10 high quality libraries that do that and more, like lodash. Consider also the ridiculousness around javascript's "OOP" features, like the use of "this", or it's behavior around truthiness, or (arguably) the misfeature of prototypal inheretance - all of which can be forgiven because functions are, after all, first class in javascript, which means you can, with enough effort, fix all the things.
In truth if you want to understand absolutely everything about your runtime, and have some feeling of safety in a sandbox, then the jvm is the best. The vmspec is great, as is the langspec. It's very fast. The tools are mature. Lots of languages are written for it. It's behavior under load is well-understood. Like PHP there is a lot of bad code written for it, which gives it a bad name, but it's still a real gem.
Well, they asked why someone would use JS if there were other options, and I'm saying that I don't think Ruby nor Python are better languages than JS. Part of that is due to their bolt-on async vs JS async everything, part of that is due to TS, but there's more.
For example, you bring up Python's collection comprehensions, but I could easily point out Python's gimped lambda support and thus poor FP abstractions and the need for a special comprehension abstraction.
I don't think it's worth arguing about. But I had to chime in before someone thinks there really are no objective nor subjective reasons why someone might prefer Javascript. I do.
> then [X] is the best.
Btw, there is no best. There are only trade-offs.
One of my points is that you can't say something is the best. The only thing you can do is enumerate the trade-offs that made sense for you, and much of that is only personal/aesthetic.
You can. And you did. When you say something is your favorite, this is like saying it is the best, all things being equal, in your view. For network connected server processes, I say the jvm is the best runtime. Redbean, interestingly enough, may take that crown, but I'm only now playing with it, but I love its tiny simplicity. In some ways this is like love - do you shy away from saying that your woman is the best? I hope not. And I hope no-one holds your feet to the fire if you do.
Prototypal inheritance isn't a misfeature, it's an interesting and powerful language design choice used by several different languages [1]
It may not be your cup of tea, but having written code in most mainstream languages since the 80's, I can tell you I definitely prefer it to alternatives like class based inheritance.
Runtime mixins are one of the most powerful composable concepts in any language, and this is a breeze with js. Take a look at the hoops c# had to jump through to come up with something similar but less powerful, as an example. Or the nightmare of multiple inheritance in C++.
Something is wrong in this thread. People have misquoted me, twice. In this case you cut out "(arguably)" implying my position is stronger than it is. Elsewhere, they cut out the conditional in my endorsement of the jvm, implying my statement was absolute, and proceeded to lecture me on trade-offs.
Not sure what it is, but I don't like it and won't participate.
As a Deno fan I was surprised to learn that the free tier for Deno Deploy includes 100k requests per day and 100GB of bandwidth monthly. I know I'll be trying it out now.
I think Deno Deploy and using Deno on fly.io could be a powerful combo. Deno has some advantages that definitely lend themselves to having control of your entire MicroVMs. An app could easily be split between serverless-friendly and non-serverless-friendly parts of the stack by using both together.
So less than 17 minutes of CPU time per day - not a lot, but also not nothing.. But at 10ms per request, what would one use it for? Just server-side rendering for something simple?
proper applications as well. example is the https://deno.land website has an average CPU time of 6ms. CPU time means it doesnt include any IO bound operations, so ie doing a fetch request wont really contribute to the CPU time.
Bear in mind this is CPU time, not wall clock time. I work with both AWS Lambda functions and Deno Deploy functions every day. I hit the 10s Lambda timeout all the time (things like slow API calls or network requests), but I never hit the timeout for Deno Deploy. You can even use it for things like Server-Sent Events or Websockets. It'll keep the connection open indefinitely, as long as it's not using the CPU.
I'm not deep in Node world but I use it and see it being used, who is using Deno out there? Have there been some notable/major ship jumps? Or is it not that kind of situation (perception from when it came on the scene is that's exactly what it is, constantly trying to woo Node devs over). And also there's alot of recognizable brand competition out there from things like Cloudflare, Netlify (but they're an investor in this?), Vercel on fire the last year or two, and not to mention the big FAANG types. Again, who's using this?
See now that's interesting - All of those have very out-there brand reach and recognition but who knew they were using Deno, nobody heh. Okay, then, so it's a bit under the radar but ticking away down there, hence the raise. Fairplay.
If you're not following those companies' offerings then it stands to reason you haven't heard about it but all three of them did broadcast pretty widely that they were using Deno, I would assume quite a few people were aware of this.
I think it's still pretty early days but it's clearly far superior to Node so I think we'll see more and more people use it.
The biggest barrier is the library ecosystem. JS's insane packaging history means a lot of NPM libraries don't work seamlessly with Deno even if they don't use Node APIs.
I imagine you are already aware, but the creator of Node, Ryan Dahl, is also the creator for Deno. He is trying to create a new language which integrates what he learned from building Node.
It's all JavaScript, so language is probably not the right word to use. Runtime is correct, but both technically sit on top of V8. Although Node leverages C++ on the backend, and Deno leverages Rust.
396 comments
[ 4.8 ms ] story [ 299 ms ] threadThe only reason I didn't continue was a lack of ARM support.
Someone is doing the builds here - been using them and seem ok: https://github.com/LukeChannings/deno-arm64
I want to say I followed these instructions for doing so recently:
https://gist.github.com/plembo/c4920016312f058209f5765cb9a3a...
- Investors want unicorn returns.
Good luck!
Do you think that investors see every company that isn't a unicorn as "nothing"? I think you're living in a fairytale
Given every big company uses JS, and thus many SaaS VCs have JS in their annual set of thesis bets, it's reasonable that Deno got picked by a top group given their team & growth. Same story with npm, netlify, etc.
I wish the team luck in hitting significant revenue in the next 9-12mo, as that will determine a lot of what happens to the community. A lot of pressure & culture change to work through!
EDIT: the comment I responded to was completely rewritten and replaced with a different one. Please don’t do this
Some people involved might expect more, and I'm sure hope for more, but I'm a language designer & CEO, not a mind reader :)
If Deno reaches 30% of the impact of Node, their company could be worth billions.
In the meantime, we get a better open source runtime because they have money to build it out.
there are lots of companies, which are technically "unicorns", but haven't even got any revenue yet (Rivian and Nikola come to mind)
I love Deno and want it to succeed, but it doesn't feel like a unicorn, and I'm worried about it being expected to become one
There’s no guarantee that the creator of the ecosystem will be one of the unicorns, but they’re as good a bet as any other company to pull it off. VCs aren’t looking for 100% certainty, just a plausible path.
They charge you for CPU and bandwidth more than they pay for it.
Apple's moat, for example, is its institutional knowledge of design and maybe its relationships with its suppliers, e.g., their deal with TSMC to lock up most of TSMC's capacity on the 5-nm node. Another moat Apple has is consumers who do not like engaging in sysadmin battles with their consumer electronics. One of my friends, a 79-year-old woman, for example, told me once that she wouldn't consider buying a computer from any company except Apple. (I could probably induce her to change her mind on that, but it would take persistence and patient explanation on my part, and also I'm probably the only person who could change it.) The main way Apple has maintained (for 38 years!) its dominance in institutional knowledge of design is probably the fact that most of the young talented designers want to work for Apple (partly because most of the people willing to pay extra from good design in consumer electronics buy from Apple).
Google Search's moat seems to be institutional knowledge on how to build a good search engine and access to data on what people search for and which search results they click. Strengthening the latter moat is the reason they're so interesting in having all traffic from the consumer's browser encrypted: namely, so that the consumer's ISP cannot sell data on the consumer's interactions with Google's search engine to any competing search engines. Another moat Google has is that most consumers will not take the trouble to change the default choice of the search engine used when the consumer types a non-URL into the location bar of the browser. Strengthening that moat explains Google's willingness to pay Apple and Mozilla to be the default search engine and Google's interest in giving away Chrome and Android.
Microsoft's moat: practically every organization uses computers and needs employees who know how to use those computers. They mostly choose Windows and Office because that is what most prospective employees know. In turn, when a young person improves his or her attractiveness to prospective employers by learning computer skills, they usually choose to learn Windows and Office because that is what is running on the computers of prospective employers.
The other big moats off the top of my head aren’t as strong but ASML, TSMC (for now), Tencent, Baidu, Yandex, Kakao Daum, are all worthy but still peanuts comparatively. I’m sure some Indian companies too.
But I agree with your point: it is really hard for a new company to create a large revenue stream with a strong moat around it.
(I'd bet this will be, or already is, the more profitable side of the business.)
I think ~100 ~1000 ~10000 would be clearer than using the big O notation, since this has nothing to do with fuinctions.
https://deno.com/deploy
I like Deno in principle, but I'd love to see how Slack, Github and Netlify are using it.
For some reason it never had that same negative effect on me
/s
We have web accessibility standards and companies get sued for not following them.
https://docs.netlify.com/netlify-labs/experimental-features/...
All this dynamic processing happens in a secure runtime based on Deno directly from the worldwide network edge location closest to each user.
It reminds me of the feeling after surfing when you lie in bed with your eyes closed and still feel the waves going up and down.
Slack: "Run on Slack"
Netlify: "Netlify Edge Functions"
They're both listed in the Showcase: https://deno.land/showcase
no matter how much I think about that whole concept, I see no application for it that couldn't be done better, faster and easier with regular tools
Yeah, thousands I would imagine. The last two companies I have worked at have been 100% serverless or nearly 100%.
> no matter how much I think about that whole concept, I see no application for it that couldn't be done better, faster and easier with regular tools
Considering you have to ask if there are _any_ products running in a serverless environment, I would imagine you need more exposure to the concept before you make such a large judgement on it.
If you can answer (for legal or other reasons you might not be able to): What kind of monthly bills did your setup have and how many req/s did you serve (in lack of a better metric)? It'd also be useful to know average min/max response time if that's something you remember.
I wish that was a good way of evaluating "performance / price" but that's really hard... If someone know a better way to frame the question regarding price, it would be very helpful.
There is more than "raw dollar amount on monthly bill" to account for in cost, as well. For one, there's stability and the toll that takes on both your team and your customers. Not saying non-serverless apps are not stable by nature, but I've now been part of two teams that have seen the same types of benefits and those benefits line up with the "sales pitch" benefits.
I rather know my configuration and use one big server with the static files on a CDN
https://blog.khanacademy.org/the-original-serverless-archite...
For example, you have some background tasks (sending email, processing files, etc). It's very convenient to just push those into a queue and have serverless functions chew through them. They scale to zero, cold start time has no negative impact on the workload, you don't have to worry about k8s resource requests and scaling, etc.
I too am skeptical of using any serverless offering for serving HTTP API's or server-side rendered pages, atleast for non-trivial amounts of traffic. CloudRun can do it but only because it's a thin management layer on k8s/knative and even then networking config for anything other than CloudSQL is tedious (you have to deploy a proxy to access your VPC).
This is funny to me because serverless sounds to me like the return of PHP (etc) shared hosting. What's old is new again?
[0] Used here as shorthand for “modern js driven development”
Nobody is reinventing PHP or RoR development. What is happening is the community taking all our favorite parts of these stacks and combining and implementing them in ways that facilitate a dev experience that we could only have dreamed of back in the PHP/RoR days.
- Senior dev that started off in the PHP and then RoR days
- Engineering Lead who got his start in PHP/ASP(pre .net) and loves the modern ecosystem despite its flaws
The evolution has been 2 steps forward but 1 step back. It’s how many complex systems evolve and it’s fine. Just because you see that some problems/solutions resemble what you saw 10 years ago doesn’t mean nothing was improved along the way.
PHP is an unsafe, slow by default (execution model - the language itself fast), hard to use well, clunky, limiting and bloated language that is kept together by duct tape and the incredible effort and ingenuity of it's open source community by educating developers and improving/cleaning up the language at full blast, unfortunately often by breaking backwards compatibility.
Whether JS (including Deno) is a good alternative or the right answer is up for debate. But people who try to mimic some of the benefits of PHP in the JS ecosystem are not doing so accidentally or because of lack of experience.
I am an optimist in that I (have started to) believe that this slowly allows us to converge on better solutions for everything.
PHP was easy to set up, easy to host, easy to understand and easy to build stuff with, but it resulted in an unmaintainable mess over the long run.
Then Node was all of that, but JS was a better language than PHP. Then Node grew warts in the form of the clutter that is npm, then it grew complex build systems and unstable libraries.
Now there's Deno. It uses TypeScript by default, which is a surprisingly useful and productive language, it rethinks some things, it's much more secure by default, and now we're back at the PHP-level easiness to host using Deno Deploy.
We've ended up with an overall better solution and it only took us 20 years :)
https://www.fermyon.com/blog/wasm-wasi-wagi
https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic
Ya. Like a spiral. Or a spring, if you want to get fancy (add z-axis for time).
Each revolution seems redundant, but can be exploring a slightly different problem space, or trying a solution with a new angle.
rolls eyes
Outside HN that distinction might not be important. Here being pedantically correct does matter on this because the VM abstraction has been around for a long time, whereas containers were an enabling technology for serverless.
And containers and the fast startup, security and resource consumption guarantees they offer is a big difference to the old days of shared PHP hosting.
And this is why "reinvention" with new technology is different.
https://firecracker-microvm.github.io/
Firecracker is a virtual machine monitor (VMM) that uses the Linux Kernel-based Virtual Machine (KVM) to create and manage microVMs. Firecracker has a minimalist design. It excludes unnecessary devices and guest functionality to reduce the memory footprint and attack surface area of each microVM
“How AWS’s Firecracker Virtual Machines work”
https://m.youtube.com/watch?v=BIRv2FnHJAg
The Lambda service team always emphasizes the level of isolation that Firecracker VMs gives you that containers don’t.
That's being addressed by the new Web-interoperable Runtimes Community Group https://wintercg.org/, driven by Deno and others.
Netlify is using Deploy
Or, in simpler terms, O(x) = “approximately x, to one significant figure”
It's misusing big-O notation for "order of magnitude", but after I initially tripped over it, it seemed clear enough.
Competition is good.
I was very excited about the idea of workers but their tooling is (or at least was when I tried it last) abysmal, buggy and hard to understand. To this day I don't know how to setup a basic dev vs. production in workers.toml. Local debugging was buggy for naked domains (even found a GitHub issue for it that languished for months with no bugfix or clear explanation / workaround) and very slow.
Great idea killed by poor dev tooling.
Deno deploy is the opposite of that: deploys are instant and it's obvious how to deploy. You can develop and test locally.
Cloudflare released wrangler v2 (which dropped rust for node) and maybe it's better now but the one experience I had with wrangler v2 was trying to deploy a small static website (pages) and it failed due to their backend throwing 50x errors.
So much so that I wrote Denoflare (https://denoflare.dev/) to make writing Cloudflare Workers using standard Deno a breeze: no wrangler, toml, webpack, npm etc required
https://deno.com/deploy/docs/pricing-and-limits https://developers.cloudflare.com/workers/platform/limits/
Here's an example. Deno is like any other backend runtime and has regular DB clients. CF Workers do not. If you want to use Workers with PG, the CF docs point you to Supabase which provides REST over PG using PostgREST.
https://developers.cloudflare.com/workers/tutorials/postgres...
Deno Deploy doesn't have much of a moat, and Cloudflare is better funded. Both are promising to be open source & self hostable (https://twitter.com/KentonVarda/status/1523666343412654081). We shall see.
Even when CF open sources Workers, they will be useless for anything non-HTTP related.
> Deno deploy seems cool and all, but I haven't seen any great rationale for using their service over say Cloudflare Workers.
Note "their service". You replied with
> Workers are not meant as a generalist runtime.
So, we really were talking about Cloudflare Workers vs Deno Deploy.
Deno is something different, for sure. But it seems Deno Land Inc. is betting on Deno Deploy. Which makes grandparents' question interesting.
What I'm saying is that, even if you're only going to use Deno Deploy, it is an objectively better proposition because Deno (the runtime) has a much broader use case.
Would you rather use something that (for now) can only be used on a single cloud provider for (let's call them) "edge HTTP" workloads and integrations with services of that single cloud provider...
... or use something that can be used on any cloud/hosting provider, for any HTTP workload (plus many other non-HTTP use cases), which also happens to have an "edge HTTP" service custom tailored for it?
And let's not forget, Deno (the company), is much more focused on real developer needs. Workers still have a mediocre DX (although it has improved considerably lately) and still no framework for Workers like Fresh.
https://fresh.deno.dev/
The nice thing about Deno conceptually, is that it's much more similar to the browser platform than node is. It uses ES6 only, has things like `fetch` built-in by default, and generally follows browser standards around interfaces like Request, Response, etc. Instead of needing a complicated build process to make Node code work on the browser, now we have a complicated build process to make Deno/Browser code work on Node. ¯\_(ツ)_/¯
https://github.com/esm-dev/esm.sh/issues?q=is%3Aissue+is%3Ao...
https://blog.cloudflare.com/introducing-the-wintercg/
Grandparent confuses correlation for causation.
Indeed, especially when you compare with a company such as Supabase (which is working on way less interesting technology imho) who just raised $80M: https://news.ycombinator.com/item?id=31328783
so I think in their notaion O(10) has greater magnitude than (>) O(1)
Which is to say, they're saying Deno has a cold start time of ~100 ms, package size ~10M, a physical machine can support ~1k instances.
Seems like the standard arguments would be that developers already know JS, and that you can share code with the browser. I don't find these highly compelling.
EDIT: I haven't learned typescript yet, based on the replies, it seems like that could be a good reason to choose it. Seems like a nice middle-ground between typical scripting and compiled languages.
I'm coming around on Elixir.
I never want to write Go that interacts with a database again.
Rust seems complicated. I don't think I'm smart or committed enough to get anywhere with rust.
Why? I’ve been using sqlx and it seems fine.
Rust is a bit rough yet to do the front and backend development, but IMHO it will catch in a year or two. Also for backend rust now with (actix and axum) looks pretty similar to expressjs, so you will feel like home there, but for the frontend there's still no killer framework nor a settled architecture that fits better rust model.
I LOVE Go ! I think it's the bee's knees until you have to write DB code ! I'm hoping "go generics" will take care of some of the table-mapping/orms/multiple-types etc madness.
But yea, I still love go :)
FWIW, I think Typescript would make an even stronger case. And I think(?) that's one thing Deno is trying to do.
The benefits are in my mind not that you can share code directly but more that the std lib is the same (mostly) between backend and frontend. This means no mental context switching for developers.
The other bonus is that typescript is just such a lovely thing to code in. Expressive, universal and ubiquitous, performant - modern JS is a joy to use (...if you don't need to use NPM... If you need to use NPM at all then it is a shit show)
(but still: don't underestimate the raw performance of V8, for many things it's definitely good enough)
> It seems like people jumped to node based on some performance promises that didn't really pay off (IMO). And since then, we have newer options like Rust, Go, and Elixir as performant back-end options, and even older choices like Ruby and Python have continued to improve.
I'd agree that Node.js performance is generally not the best reason to be writing a backend in it since a static language will often yield better performance, but for the amount of dynamic power you get, it's extremely performant by default[1]. The next most performant dynamic language for I/O is, like you said, probably Erlang/Elixir, but V8 is generally understood to have better CPU-bound performance than BEAM.
[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Seems like the standard arguments would be that developers already know JS, and that you can share code with the browser. I don't find these highly compelling.
I've found that developers already knowing JS is a very practical reason, if not ideological. I'm in a team with a lot of generalists who like to work full-stack, and being able to use the same mental models and syntax is a lot of cognitive load lifted off our shoulders. It also doubles the hiring pool of people who can hit the ground running on the backend, because now anyone who has experience with JS on the frontend can jump over to the backend with relatively little training.
The other key reason for a backend in JS is that the community is extremely large, which means that a lot of the troubleshooting I'd have to do in languages with smaller communities is done for me by someone who was kind enough to post a workaround online. This saves me a lot of time and energy, as does the plethora of packages.
I haven't worked on a large-scale JS back-end myself, but this is the case I've heard others make
Blocking is NOT the same as busy wait.
Still, despite that it seems like there's a big advantage to be had
What's the actual difference between (JS):
vs (Python)[1] Technically JavaScript's async/await syntax came later, but it's just sugar over Promises which have been around for a much longer time, and those are built atop the event loop, which has been core to the language since day 1
Part of the reason is I am already using node for tooling for the front end.
It is less powerful than say C# for example in multitasking - but for hobby projects that rarely matters.
Typescript makes a big difference.
There is a lot of community support: stackoverflow, npm packages etc. Every SDK has a JS version.
It is fast enough for my needs.
NextJS is another good reason.
Also then sufficiently proficient frontend Devs have an easy in into backend development which has turned out to be a very good thing at 5 different companies I have worked for in the last 4 years.
In addition to that not every backend or service needs much performance. I have written quite a few services that get hit maybe 3 or 4 times a minute at best and Node was great for that. Actually I have yet to work anywhere where performance was limited by the language choice and not by architectural decisions or inconsidered use of databases and data structures. I am not saying this does not exist but it does not mirror my experience with the majority of companies at all.
I'd also say that despite npm and dependency hell being a real problem there is a vast ecosystem of packages out there. I know python has that going for it too. But Elixir is much less developed in that regard - simply by being less popular.
[1] https://trpc.io/
- Synchronous execution + async-everything is a great combo.
- First class Promise abstraction.
- Good general purpose language. Its warts are mostly smoothed over. It's not like Javascript from 20 years ago.
I like writing Javascript. I certainly prefer it over the other popular dynamically typed languages. (I don't see what Ruby or Python offer me over JS as general languages)
Rust and Go make different trade-offs. I would never default to either for general purpose projects. Meanwhile JS is my default for networked code.
I like js too, but both python and ruby are much better languages. It's just that js won distribution, which means it won adoption, which means you have 10MM devs smoothing it's rough edges. Just to take one language feature, consider pythons list and map comprehensions. js has nothing like that - but it also has 10 high quality libraries that do that and more, like lodash. Consider also the ridiculousness around javascript's "OOP" features, like the use of "this", or it's behavior around truthiness, or (arguably) the misfeature of prototypal inheretance - all of which can be forgiven because functions are, after all, first class in javascript, which means you can, with enough effort, fix all the things.
In truth if you want to understand absolutely everything about your runtime, and have some feeling of safety in a sandbox, then the jvm is the best. The vmspec is great, as is the langspec. It's very fast. The tools are mature. Lots of languages are written for it. It's behavior under load is well-understood. Like PHP there is a lot of bad code written for it, which gives it a bad name, but it's still a real gem.
For example, you bring up Python's collection comprehensions, but I could easily point out Python's gimped lambda support and thus poor FP abstractions and the need for a special comprehension abstraction.
I don't think it's worth arguing about. But I had to chime in before someone thinks there really are no objective nor subjective reasons why someone might prefer Javascript. I do.
> then [X] is the best.
Btw, there is no best. There are only trade-offs.
One of my points is that you can't say something is the best. The only thing you can do is enumerate the trade-offs that made sense for you, and much of that is only personal/aesthetic.
You can. And you did. When you say something is your favorite, this is like saying it is the best, all things being equal, in your view. For network connected server processes, I say the jvm is the best runtime. Redbean, interestingly enough, may take that crown, but I'm only now playing with it, but I love its tiny simplicity. In some ways this is like love - do you shy away from saying that your woman is the best? I hope not. And I hope no-one holds your feet to the fire if you do.
Prototypal inheritance isn't a misfeature, it's an interesting and powerful language design choice used by several different languages [1]
It may not be your cup of tea, but having written code in most mainstream languages since the 80's, I can tell you I definitely prefer it to alternatives like class based inheritance.
Runtime mixins are one of the most powerful composable concepts in any language, and this is a breeze with js. Take a look at the hoops c# had to jump through to come up with something similar but less powerful, as an example. Or the nightmare of multiple inheritance in C++.
[1] https://en.m.wikipedia.org/wiki/Prototype-based_programming
Not sure what it is, but I don't like it and won't participate.
(promise abstraction since 2010, async/await since 2012)
So less than 17 minutes of CPU time per day - not a lot, but also not nothing.. But at 10ms per request, what would one use it for? Just server-side rendering for something simple?
I've had to switch multiple webapps to Cloudflare Workers' "unbound" mode to go beyond CPU time limits.
The biggest barrier is the library ecosystem. JS's insane packaging history means a lot of NPM libraries don't work seamlessly with Deno even if they don't use Node APIs.