It's just so different, lots of people could claim different killer features. A strong contender for one section of the community might be the first class typescript support. Other people might like the way you can run so much from a single executable.
Anyway, node is a pretty mature platform now, if it dies, it'll die like java-the-language is dying. Very very slowly, and with parts of its platform holding out much longer than other parts. Or alternatively it'll evolve and slowly adopt things from other ecosystems.
I don't think we're at the stage where we can say that a bet on deno is definitely right, but it has a lot of interesting ideas and lots of people will be picking it up where they can.
Java is still the best choice for many backend systems. C# and Go still don't have nearly the breadth of open source libraries available. And performance between the three is very similar, besides Java's new GC's are far better.
For a majority of enterprise type integrations, which I would argue are the majority of software projects, Java and C# are still the only viable choices. And I don't see that changing any time soon. Go and JS haven't really touched that space despite widespread use for webapps.
If you need a big enterprise MMORPG type system with tendrils reaching across the cosmos into your stagnant data ponds, creaky AS400, and React customer facing mirage, Java is the legendary weapon. It's your only choice, your destiny.
Well, part of my point is that it's very very slow, and because of that, there are all kinds of points I could pick for 'since when'.
Maybe I'd pick when apple removed the default install from mac os, or maybe I'd pick when browsers made it impossible to run applets, or maybe I'd pick when the major java IDEs started pushing other languages like kotlin or xtend, or maybe I'd pick the oracle acquisition (never a good thing), or maybe I'd pick the release of go - a language squarely targetting pretty much the only niche that java has left (enterprise development of servers by mixed ability teams), maybe I'd pick the point when java development felt like it became more like configuring metadata for frameworks than actually coding, or maybe I'd pick when google started showing kotlin as the default language for developing on Android rather than Java.
This doesn’t refute his point, Java the language is separate from the JVM. And those big companies will follow the decreasing Java usage trend due to developer supply and demand. Anecdotally, it seems pretty obvious some of those companies are already doing this by writing new stuff in other, better languages when possible! To me that’s a good indicator a language is slowly dying, maybe you use a different definition.
Pretty much any language running on the JVM will make it dead simple to import and use libraries written in Java - in fact one of the main reasons to choose the JVM is the huge amount of high quality libraries available. So while true that Java != JVM, it’s not as simple as that either.
I mean, I know tons of Scala and Clojure devs who don’t touch Java at all in their day to day work. I don’t think the user(s) above were referring to the implementation of the JVM.
Then something blows on their face and they are completely lost, because they don't know what powers their code or the boilerplate magic that they generate to pretend to be Java for the JVM.
I have seen a couple of those guys, where I get called to sort out their problems.
But this is still compatible with Java slowly dying. It is possible that in a future Java role in the JVM will share some similarities with C's role in CPython.
Java mindshare has been dying for a long time. That said, it's still taught in schools and all sorts of companies still use it (including "cool" ones like Google and Apple).
It is nothing about Java or even mindshare, it is all about money, shareholders, new companies, or even just have to reshape a wheel again. This type of subject is a pseudo-proposition. When many people are using Java, some guys need to create something new (may not really new) to gain the financial interest. Of course they have to pick up something bad about Java or whatever languages and then fill his new stuff in the marketplace, but actually nothing really new. C, C++, Java, Php, Ruby, Python and do on. When everyone is familiar with something or know something for long, the capital and money stop moving, which is bad for game players such as new companies in Silicon Valley and money makers from Wall Street.
I'd ask, what is sustaining java? Where are the replacement techies picking up the torch, where are youngsters seeing java?
I have some answers. It's not a lost cause. Death is not likely, & I do appreciate a lot of java (cdi rocks, microprofile is doing great, performance is good, it has excellent big data tools & many serious pieces of infra are built with it). But how java can retain liveliness, over time, & how the experience & knowledge base continues, is a real challenge. Being on Android helps a lot but also it's a radically different immensely unlike the server side world, with its own elaborate platform specific architectures & libraries. There's not a lot of places java has a hold on UI/ux centered systems, outside Android, so it risks becoming too invisible.
Funny you should ask that. If a high school kid takes Advanced Placement (AP) Computer Science in the US (including the kids here in my neighborhood in Silicon Valley), the only language taught is Java. Kids who want my help with their programming projects or classes here in the Valley, even the undergrad CS majors at Stanford, are always going to ask about one of three languages: Python, JavaScript, or Java.
In the shadow of the Apple spaceship, the iPhone is exactly as Apple intends: an appliance for you to communicate with friends and buy things from Apple, certainly not a computer for you to program. Nobody ever asks me about Swift. If you want to program a computer--sorry, "code"--it's always and only Python, JavaScript, or Java.
When SAP rewrites their stack to something else other than Java, Amazon or Alibaba stop contributing to Java, then I start worrying.
Microsoft decided that Java death is so imminent that they are now an OpenJDK contributor, collaborate with Red-Hat on VSCode Java support, have bought jClarity and Java has first class support on Azure.
I guess a Roman, asked circa 300 AD how he feels about the decline of the empire, would have replied similarly.
Java’s mindshare just isn’t where the exciting things in this field are happening. It’s more the domain of overengineered “big data” platforms and clunky enterprise software. Yes, SAP employs a ton of java developers I’m sure, but many devs would rather switch careers than work on anything resembling a crufty ERP.
Thus, the ecosystem stagnates, due to the dead see effect - everyone who could push it forward into new areas has no interest being anywhere near it. And stagnation is a long, drawn out death all the same. It still has a ton of momentum, and millions of outsourcing devs who only know Java, so it will be with us for a while - but make no mistake, the decline started quite a while ago.
Personally I find the Java engineering to be excellent & not overblown, & I appreciate so many of their patterns. Making Service Provider Interfaces for everything? Epic awesomely powerful. Maven? Shockingly regular & predictable & clear, although what a lot of the plugins do is wild. I really don't understand most people's grief & complaints about Java, they seem abstract & emotional, but I for one don't mind typing, & don't feel bogged down in JAva.
There's some good words in the grandparent about who uses Java, that I respect a lot & holds enormous truth.
I don't know anything about COBOL. But neither do any of my programmer friends. But COBOL is also far from dead, yet it might as well be to the rest of the programming world, I feel like. It has no mutual impact, it's too far removed from the regular happenings, & I'm not sure how or where dialog would open.
So yes, like, I think the Roman example is really good. Communication are getting cut off, people are stuck. Things might be good here, but the world is regressing to a pre-Romanized status, with little overland travel, unable to harvest the breadth & intelligence of the many great citizens, that Java used to be a contributing key part of.
I don't think Java is stagnant or dead, it's not so glum. Micro-profile is being wonderful. DropWizard is a very lovely quite popular scene still. But right now, Java's presence in the AP Computer Science curriculum is doing an enormous amount of heavy lifting for Java, and once that dam breaks- and it doesn't seem like there are many fitting replacements atm, with all the nice neoclassical columns & facades to make the language feel academic/computer-science-y- it's gonna be harder days for Java, & the weakness within, the being more cut off, is going to hurt.
On my domains only Java or .NET stand a chance to win RFPs, and if anything .NET is the one having troubles, because many are unsure what Microsoft actually wants to do with it, and slowly pissed with the multiple rewrites where there is always something left behind.
I only see RFPs for Java based technology going up.
Kind of, Microsoft seems to trying to fix UWP, while trying to turn .NET into a cross platform runtime that has an eco-system that has been Windows only for the last 20 years.
So while they are doing lots of nice performance improvements, there are plenty of business not so happy that their 20 year investments don't run on .NET Core, and if a rewrite is needed (e.g. WCF vs gRPC) then why not just jump into something else.
Just see the lengthy roadmap, and the considerations that not everyone was happy with "AOT" (packing everything into an exe that unzips on execution).
Most of the world uses Java, including "happening" companies. Please be highly aware of HN bias. If one only reads HN, one can get a highly distorted view of the reality of software engineering.
> Most of the world uses Java, including "happening" companies.
On the contrary, even boring enterprises often don't actively use Java. Sure, lots of places do, but lots of places have either never adopted or dropped (or at least relegated to certain legacy systems) Java, especially, on the enterprise side, places that at some point became largely Microsoft shops, where even if they've since moved beyond that, they probably didn't go back to Java except maybe for any Android work.
I guess you are in a different bubble. Netflix's backend is mostly all Java, Apple Backend (apple media products engineering) is Java based. Neither of these companies will ever become a Microsoft shop.
The fact that you bring up salaries perfectly represents everything wrong with SAP.
A job is more than a money maker, it's a platform for expressing yourself.
SAP wouldn't understand that though, so they hire the mediocre (to write Java, a language explicitly designed to cater to less capable programmers) to produce joyless, soulless stuff.
Of course they pay well, they have big customers with no taste for good work, but plenty of money, nobody in their right mind would take on a SAP job if the money wouldn't make up for the grueling tedium.
If you think that it's either SAP or node, oh boy, thats a false dicotomy of hilarious proportions.
And BTW, I've heard that Cobol salaries are quite high too.
The way you get the job done is also an expression of yourself. There is never only one way to do things.
The issue is that if you work for a company like SAP, you most likely don't have enough personal flavour to come to interesting or meaningfull solutions. If you don't have passion, be it even for correctness, you'll build mediocre things.
Germany paid SAP millions for their Covid tracking app. Reaearchers had already worked out a protocol for them, apple and google had already implemented it. All they had to do was write a simple frontend and be done.
But politicians decided that such a big and important job, needs to go to big and important companies like SAP and T-SYSTEMS, for millions of euros.
SAP tried to be cool and agile, they even forced their employees to create github profiles (something none of the had done prior).
In the end they delivered a month too late, with critical bugs. And millions of server maintenance fees.
A system that was already 90% implemented, with network requirements that can be satisfied by fiber to the home connections, or a single S3 instance.
Why? Because they used mediocre people, who didn't have enough passion to create github profiles. Because they used the least common denominator, Java, and reinvented stuff that was already implemented.
And because everybody just wanted to get the job done and go home, no expression of self involved.
We are building the noosphere here. We don't all have to wear that mantle, but some of us should have hopes and ambitions in our jobs. They don't even have to be consuming, but simply seeing this as an ongoing continual project seems due. We're coming close to RFC10000. No one goes home. We strive to open possibilities for humanity so we can all each keep exploring & going further.
Edit: oh good to see you again pjmlp, after last week. We fell to different sides then too, but I have continually enjoyed your writing, & again, while I talk & disagree, I would also not say you are wrong. You are more than correct, in the vast amount of cases. But I would suggest that this field in particular must also be heads up looking up & about, that just a job doesn't fully describe us all.
Well UNIX (or Linux more importantly) is "losing" C, C++ and more recently Rust are slowly displacing it. It's still probably going to be the ABI everything is based on but the language itself is not a first choice for many and that number is increasing over time.
Is that what you were implying ? It doesn't sound like it from the rest of the comment because you seem to disagree that Java is losing mindshare on JVM.
.NET Core also doesn't run in all platforms where there is a Java implementation and not everyone is happy to rewrite their .NET Framework into Core, while Microsoft is in mix of leaving again stuff behind like the ongoing discussions about CoreRT, .NET Native, Project Reunion, MAUI vs Blazor vs WPF vs Forms show.
The problem with .NET is that Microsoft have a proven history of seeing the next shiny over the hill and dropping support for existing frameworks and libs while the "new and improved" framework is rolled out. See ! This way is better! Well, until the next better way comes up within a few years.
I know of teams who have moved to Java simply to avoid the churn. Many folks prefer the boring but stable Java ecosystem.
As well as this, I think it's also perceived to be a clunky old language. Our modern languages have much more ergonomic build systems, are much less verbose and have coding conventions tailored to modern tastes.
This is important, so I predict that over the next few years, as the 20-30 year olds of today gain more senior positions, they're going to choose python, JavaScript, kotlin, golang or rust for new projects.
> What’s the killer feature that will lead to node developers switching over in droves?
The killer feature is that it offers nothing new or distinguishing. It looks like other JS elsewhere. It offers WebSockets via the same sort of WebSocket support you'd have in the browser. You read files via the FileReader api you'd use in the browser.
The killer feature is native developers who have an easy te embedding or writing add-ons for deno, not end of line developers.
This killer feature / mass adoption mindset is such an ugly poison. The size of a community is far down the list of considerations, a proxy only for easy consumability & fitting within current pop-culture sensibilities myths & current styles. Think different. Look for what really may matter.
I have been running nodejs in production since 0.6 (2012) and I'm not emotionally involved with nodejs, being actually a scala person who happened to work on a nodejs project. I'm curious and interested by new things, so I looked at deno with interest. And honestly, for now, I don't see a single practical benefit that would make me switch over.
I'm still happy that deno exists, experiment is good and if they ever find something that could make nodejs better, then it could be used to actually improve nodejs, which everyone will benefit from.
It's better aligned with browser technology and with Rust. I think that in time it will run JavaScript apps that depend on browser APIs and/or Rust APIs better than Node. If it also leads to lots of people switching to Rust I don't think Deno's creators would have a problem with that.
What are you trying to say? You come over as being threatened by either Deno or parent comment or both. What are your thoughts on Deno then, besides that people around you are not talking about it?
I don't understand your questions nor your tone. [edit: see posts below, I understand now. Sorry I misread the parent post]
I was just contesting the assertion of "switching in droves" by parent post. Find me a case of a nodejs community "switching in droves" to deno if you know some, or even a high impact project in nodejs currently switching to deno, if your intention is to assert that parent's assertion is correct.
My thoughts are that atm there is no reason to switch your project(s) to it and that, for the features Deno offers right now, it was indeed severely overhyped
They're pointing out that anecdotally, Deno seems to be a non-player right now. Which is pretty spot on: it's still very new, and hasn't found a critical application yet (e.g. would Node have taken off the way it did without Express? Probably not). So right now, it's an enthusiast's plaything, even if the architectural principles are much cleaner (wrt modern JS) than Node can ever become - without a rewrite so drastic it'll split the Node community like Perl 5/6 or Python 2/3, at least.
The node.js has a big blm banner for example and claims that white surpremacy and police brutality is global issues when it's really just very US-based.
I just don't see how that has anything to do with javascript development.
It takes different forms. In the US, the it was slavery, segregation and today police brutality and ideological oppression.
Yet the US, isn't alone in this. It never has been. For example, although the famous poem Whiteman Burden was about the American-Phillipine war, it was written by a British poet based on his view of British Imperialism. That legacy of colonialism lives on today throughout everywhere in the English speaking world.
As for the French, the less said about how they exploit the CFA zone countries, the better.
The Russians? Currently the leaders of European racism.
This isn't simply a topic isolated to a parochial country, far far away from the ideologically pure Old World. What occurs in the US was merely a Flashpoint.
Ok tell me how white supremacy and police brutality is a problem in let's say... Japan? A country with basically no white population or violence of any kind. Americans may be shocked to find out that whites are actually a very underrepresented group in global terms and there are a lot of countries where white people are in such a minority that basically all of them are immigrants.
They explicitly state that these issues are global and thus must be an issue in every country. Sure you can pick a few countries where there are big issues, since there is a lot of them. But there are also a lot of countries where it isn't a big issue. These countries, like Japan, may have other issues but not explicitly those stated.
This is definitive proof that they are pushing a specific, american political agenda where you paint with big brushes over the entire world. It's also objectively and demonstratively false. My country for example, Sweden, rather have the opposite issue of police brutality, the police basically use too little force and this creates a bunch of issues where criminality reign rampant.
To show that something is a global issue, I merely have to display instances world-wide, not in every single country (that's the difference between global/ubiquitous and 'universal').
Having the issue in Africa, North and South America, Europe, and Australia is enough to satisfy that. I'll have to defer to others experiences in Asia, as keeping up with 4 continents is enough for me ;)
Additionally, this ideology expresses itself in different ways per country. The issue of white supremacy in for instance Togo, is not that there are white police officers and segregated drinking fountains. It's that the French forcibly colonized the area, then set up an exploitative trade zone after WW2, and continues to prop up brutal dictatorships merely because the leaders are willing to cede economic control to France. It's that the French are forcing their language & culture on a country as part of a 'trade' agreement (to the point where the government must buy French textbooks), but there isn't any reverse requirement of cultural exchange.
White supremacy is a global issue.
Yet all global issues won't affect every country equally.
Climate change may have global effects, but as the Fins famously said 'we live in the mountains, we will be the last to drown!'.
White supremacy is NOT a global issue. I am from India and these banners irritate me to no end. They really need to add a regional/geographical check before pushing national agendas worldwide.
I strongly disagree, if that is the definition for a global issue. Then basically every issue is a global issue. It just doesn't make sense. If you claim white supremacy is an issue today because of history, well then so is black supremacy, asian supremacy etc. Should we still claim the Djingis Khan to be an issue today since a lot of us are descendants?
At some point, you pass the line and you become ridicolous. I think you and a lot of others have crossed that line. I feel so disconnected from your views and the people who write BLM-banners like those on nodejs.org that we could live on different planets. It is hard to even have a rational conversation because of this and for what? It has nothing to do with tech or javascript development. It's inherently stupid.
> Fins famously said 'we live in the mountains, we will be the last to drown!'
I suppose you don't think of the Finnish people? Because these guys mostly don't live in the mountains. :)
When people say they don't want tech companies/organisations to be political they're actually bummed out that those political views don't align with they're own.
For me, two small things that haven't yet been mentioned here.
Dependency management that's much more friendlier to forks. Very often I want to patch something small in a public NPM library and point my company's private project to the fork that contains that patch, not having to wait for the maintainer to accept the PR. Publishing a separate private or public version of this is still a chore.
Typescript support. The current "building" from Typescript to JS is something that mostly works, but still feels icky and sometimes breaks down. Setting up a great debug environment in Typescript/NodeJS codebase is still a pain, and mostly I don't even bother.
I see that none of those are "killer" or seem very important, but it's enough just to try it for some small project in the future. And then, who knows? May be it'll just turn out to be better in general.
If that's the question you're pondering in order to decide whether or not to switch, you basically have no reason to switch yet. Stick with Node.
However, if you've gotten more and more annoyed with Node's legacy method of requiring modules (because it predates modern modules) and legacy method of dealing with asynchronous code (because it predates promises and async/await), then you already know why Deno might -once it's matured a bit, because it's super early days still- be worth your time.
Me and my friend use it in production for hobby projects. It works great so far with very few issues but you kind of have to keep up to date and the updates are coming really, really fast.
For me, "production" is the stable, tested version you ship that runs constantly. The one facing most users.
You can have hobby projects with users, and 24x7 uptimes being a goal. It makes sense to distinguish "dev" from "prod" with those and to use mechanized testing and CI/CD, just as with commercial projects.
A lot of open source projects fall into this category.
Deno not supporting TLS isn't a show stopper, in my opinion. Not many production environments expose Deno (or Node) instances directly, but rather have a reverse proxy sitting in front providing SSL and routing.
Better leave that to a terminator/proxy anyway unless you’re interested in hotpatching your app layer every month. It’s usually less problematic to upgrade a proxy.
We definitely want to improve docs, but the Rust side of things changes so much it is really difficult to keep stuff up to date. A lot of refactoring is happening currently, but once that settles down some, it will make more sense to write proper docs.
I just started digging into it a few hours back, so I can't give you a concrete answer. A hello world example for the deno_core to give an idea on how the Ops and ResourceIds should be used. The examples given are not really clear at a glance what they are doing and I had to read through a few of the test cases before I got some idea how JsRuntime should work.
Can someone explain like I'm five what Deno is and what it's for? Is it for the desktop or web applications? What practical things can you / should you do with it? I just can't get my head around what it does.
Well, nodejs was kinda: lol, what happens if you put v8 js engine inside a c++ event loop?
Now, some years later, deno is more like: ok, we know what happened. But now browser js have some new apis we could (should) re-use (modules, fetching resources) - and this typescript thing looks good. So what if we put typescript inside a rust event loop, and surfaced some of the sandboxing ideas that browsers use (eg: no file system access by default)?
deno is 'node' shifted by two letters. What do you use nodejs for? That's what you use deno for. It exists in the same space.
So in short, deno is a javascript interpreter suitable for local scripting, server/services, etc. Just like node.
You can probably use it for desktop applications, but it more closely targets server code, again like node.
So how does deno differ from node? It has a different module system and stdlib (better, more modern). It has first-class typescript support. It has much better security controls so that it's possible to use it to interpret untrusted code (this is not security advice).
The 'untrusted code' bit means deno's also gunning a little for the niche lua and other embedded scripting languages occupy, but I don't think it has much of a foothold there yet.
Any experience embedding deno in a c++ application? I absolutely lovehow seamlessly lua integrates into my code, but I just find the language itself absolutely unpleasant to work with.
If it's the syntax that troubles you, you could have a look at MoonScript, a little language that compiles to Lua, inspired by CoffeeScript and bringing with it some niceties.
I think QuickJS is the best option for embedding a JS interpreter. It’s a bit on the heavy side, but it supports a lot of modern ES2020 stuff.
https://bellard.org/quickjs/quickjs.html
It's a lot like Node.js, a js runtime built on v8 w/ bindings to the filesystem, network, etc. However, it is redesigned around recent changes to js. It eliminates commonjs and package.json in favor of es modules, and eliminates callbacks in favor of promises. It also gives scripts zero permissions by default, so you can give each script you run access only to what it needs.
If you hadn't realized, JS is a scripting language, which does not have an official runtime.
What that means is... How is JS code executed?
You need some other program to interpret (and possibly JIT compile) the JavaScript and actually execute it.
Normally that "other program" is a web browser like Chrome, FireFox, Safari, Opera, etc.
But those programs run JavaScript in a restricted way. That is, they only execute JavaScript attached to a web page that they loaded and within the context of that page, and they limit what the JavaScript can do to the operating system. Like can it delete files on your disk? Can it listen to an open port? Etc.
Also, those programs don't let you run JavaScript conveniently outside the context of a webpage. You can't just do at the command line: `chrome myscript.js`
Thus if you wanted to use JavaScript to write command line applications or desktop applications, using a web browser wouldn't work.
So we need another program that lets you run JavaScript from the command line, or as an executable, and we need that program to provide more facilities to the JavaScript code which allows it to do more things to the OS, such as deleting files from the disk, listening to a port, connecting to arbitrary remote servers, etc.
The first such program to appear was NodeJS. And some people don't like it. They don't like the way it runs JavaScript and the way it has exposed to JavaScript those additional OS facilities. Thus they decided to create another one called Deno.
Most languages have one defacto run-time, for example for Python it's CPython, for Ruby it is MRI, for Java it is OpenJDK, etc.
And if they have alternative ones, like Ruby also has JRuby for example. They normally copy the same language APIs, so that code for one works on the other.
In the case of Deno this is not the case. Deno decided that the NodeJS exposed JavaScript APIs arn't great, so it has a different set of language APIs. That means JavaScript code written for NodeJS will not work for Deno and vice versa.
It's really rare to see such a split in mainstream established languages, because the cost of breaking compatibility with established "in-production" code is normally too high. For example, Microsoft has build .NET core, as a new run-time for C#, but it tried really hard to provide all of the old .NET framework APIs, yet not all of them, so it did break se backwards compatibility. I believe Deno will break much more.
I've only seen this happen in the past for less popular languages, like Smalltalk has a bunch of slightly incompatible runtimes: Squeak, VisualWorks, Pharo, Cuis, etc.
And when that happens, sometimes people even consider it a whole new language, like a dialect. So in some ways, you could almost consider NodeJS and Deno to be dialects of JavaScript, since their code isn't compatible and their APIs and some of their features will differ. Similarly, their code will not always run in a browser either without rewrite, because again, the capabilities and APIs differ.
Hope this helps, I know it's kind of complicated, but at the same time it's simple. You need a runtime to run JavaScript. Each runtime can expose different APIs to the JavaScript to use, and each runtime can choose to support custom extensions of JavaScript or choose to not support certain features of JavaScript, etc. Deno and NodeJS are two such runtimes for JavaScript that are both making different choices.
Thank you for explaining like I'm five, and not assuming prior domain knowledge! You've greatly increased my understanding of the nature of Deno and NodeJS and how they relate to each other, I'm starting to get it.
What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages. Why not Python or Go or Rust or literally anything else? But perhaps that ship has sailed, and the answer now is just inertia, people use JavaScript because people are already using JavaScript :P
> What I still don't fully understand is why people want to write non-webpage software in JavaScript
Many good sibling answers already - but another thing to note - is that if you want a modern (js) front-end and optional server side rendering (for faster initial load/display and/or to present something nice to search engine crawlers) - you'll probably end up having to execute js on the server side too.
Also, there's the hope of being able to re-use code for business logic, like validating data - you can (should) validate client side for better ux (quick feedback on misding/wrong data) - but since you cannot trust the client you have to validate server side.
Obviously it seems attractive to write that validation code in one place, always having it in sync between client and server.
> What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages.
There are multiple reasons, but it mainly comes down to
1) JavaScript is simple and widely used. And as many people are using it, those many people often also have the wish to use it outside the web for other things.
2) Webpage-Software has evolved to Application-Software in the last decade, and nowadays you can create proper interfaces with javascript&css&html which can compete with native desktop-software in terms of ability and somewhat performance.
3) You have one sourcecode for all devices. You only need to write it once, and use it everywhere with a little bit of tweaking. Which is cheaper and faster than writing separate software for every platform and device.
Because Typescript is one of the best languages we have today and has major advantages over all others mentioned? I write (or have written, in the case of Go) all 4 professionally.
- a vast ecosystem all based on async IO, sidestepping the colored function problem, as opposed to the clusterfuck that is Python’s asyncio ecosystem
- a powerful and expressive structural typing system that allows you to make illegal states unrepresentable in many cases, similar to Rust, as opposed to the language of interface{} and if err != nil
- I feel silly comparing it to Rust because the Venn diagram of what problems these 2 languages are appropriate for looks like 2 disjoint circles to me. Yes, technically you could write your backends in Rust, and your competitor using Node will launch their MVP 2 years before you do.
> What I still don't fully understand is why people want to write non-webpage software in JavaScript, a language designed to run in web pages. Why not Python or Go or Rust or literally anything else?
I would say familiarity is a big one. Lots of people now learn JavaScript first, and once you know it well, having to re-learn a whole other language might seem like a big hurdle that if you can avoid seems like a good proposition.
Another one is this new concept of "full stack". While most JS code in browser and in server won't work as is, there's still a lot of overlap. So you can have subsets of code that you can copy/paste from your front-end into your backend and vice versa.
This also means that as a dev, if you want to do backend and frontend work, you only need to learn one language, that's 50% less effort on your part than having to learn two languages :p
Something else that kind of happened as a lucky accident is that JavaScript was designed for event driven programming mostly, due to it being used as a language to handle user events on webpages for interactivity. Now it turns out that the problem of managing interactive user interfaces is highly concurrent in nature. At the same time, it happened that most backend code needed to scale horizontally, which meant that it too needed to become highly concurrent. This was the innovation brought by NodeJS to the backend. It was one of the first run-time for backend that was designed exclusively in an event driven model, which actually allowed it to scale quite well for non CPU intensive workloads. In that sense NodeJS was a pioneer on the back end side as well, and other runtimes are just catching up.
Finally, writing an optimized runtime for any language is a huge endeavour. It requires lots of dev work and effort, which is quite expensive. Since web browsers make a ton of money and are backed by the richest companies around, and they care a lot about the performance of JavaScript in their browsers, there's actually an immense amount of investment made to the JS interpreter and virtual machines to have it be as efficient and optimized as can be. In practice it means that there exists JS VMs that outperform all of Ruby, Python, PHP, Perl, and almost all other dynamic programming language interpreter/VM out there. There's not many things that can rival that, you've got Go, JDK, .Net, GCC, and the Rust compiler maybe. The former because they've also had ton of money poured into them, and the latter because its entire language design and everything targets performance. Also you've got OCaml, Haskell, CommonLisp and Scheme runtimes of yore that might rival it due to how long they've had dedicated researchers and volunteers contribute. In any case, it means JS VMs are quite competitive performance wise.
> In practice it means that there exists JS VMs that outperform all of Ruby, Python, PHP, Perl, and almost all other dynamic programming language interpreter/VM out there.
Except for the various Lisp flavors that have really high speed implementations.
> The first such program to appear was NodeJS. And some people don't like it. They don't like the way it runs JavaScript and the way it has exposed to JavaScript those additional OS facilities. Thus they decided to create another one called Deno.
The only thing I would object to here is the context. The guy who created Deno isn't just "some people", but in fact is the same person who created NodeJS.
Deno might turn out to be a failed experiment, but it's coming from someone who knows the warts of NodeJS intimately.
https://github.com/denoland/deno/issues/1968