This is fantastic! I hope they succeed. I love JavaScript as a language, and it would be good for this legal cloud to be gone. I also have to mention that deno, since 2.0, is absolutely fantastic...
This is fantastic! I hope they succeed. I love JavaScript as a language, and it would be good for this legal cloud to be gone. I also have to mention that deno, since 2.0, is absolutely fantastic to work with. I didn’t like every decision that they made in Deno 1, and 2 fixed most of my complaints. I don’t see any reason to use anything except deno for any modern JavaScript project.
Deno is made by the same guy who originally made node. His goal is to make a modern JS runtime that fixes all the bad decisions that are in Node. It is also attempting to replace the entire tech...
Deno is made by the same guy who originally made node. His goal is to make a modern JS runtime that fixes all the bad decisions that are in Node. It is also attempting to replace the entire tech stack for node. Npm is replaced with deno install. Prettier is replaced with deno format. Eslint is replaced with deno lint. They removed the bundler in v2, but they are trying to add it back in at some point. It runs typescript natively, so no need for tsc or ts-node. They also made jsr.io, a modern replacement for the npm registry. It is TS first, and I think it can even be used with npm/bun/yarn/etc. When it first came out, it wasn’t actually compatible with node, but with v2 they are advertising 100% node and npm compatibility (code written with deno in mind can be slightly different than code written for npm/node, but deno is backwards compatible with package.json, so you should be able to drop deno in to replace node and npm without issue).
The Deno 2.0 release announcement might be a good place to start. It doesn’t really compare against node, but if you are already familiar with node it should make sense why it’s better. The deno...
The Deno 2.0 release announcement might be a good place to start. It doesn’t really compare against node, but if you are already familiar with node it should make sense why it’s better.
Ryan Dahl gave a talk when deno first launched. That article links the video. I think the article gives a written overview of his talk, but I only glanced at the article and listened to the talk a long time ago. Keep in mind that this is from the original deno launch. The project changed considerably with v2. For example, deno originally didn’t have node compatibility explicitly, and now it tries to have 100% compatibility, including a node_modules folder if required.
Edit: they also have Deno Deploy, which is their hosted serverless infrastructure offering. On the surface, it isn't terribly exciting, but if you look closer at the details, I think it's really compelling. It's the only true competitor I have found to Cloudflare Workers. I think Workers are fantastic, and I have made some projects based on Workers and Pages Functions, but I try to avoid Cloudflare now because of their terrible sales tactics. What makes Workers unique is the level at which your code shares infrastructure with other customers' code.
In a serverless environment like Google Cloud Run, your cloud invocations are docker containers that respond to a request or job and then go back to a waiting state. Google keeps your container running for a short amount of time to respond to future requests and then kills the container. When you get a new request, Google has to load the image and startup an entirely new container. Often this means the first response will be unusually slow (called a "cold start"). AWS Lambda is almost identical to this, but they have some developer experience improvements. I think they also have docker containers they build themselves for specific languages that optimize this cold start time. But no matter the improvements, you still have to have an entire fraction of a server running an entire VM just for your code.
Cloudflare workers run your code in V8 isolates. This is a way to run separate untrusted code on the same V8 thread. Because of javascript's promise based async programming model, if your code is waiting for a network request or some other promise, that thread can easily run someone else's code without affecting anything. Also, since V8 is continuously running, a cold start only requires loading your code into the interpreter, making cold starts almost instant. They are so fast that (if I understand correctly), every single request is effectively a cold start since there is so little overhead. It also means you are only billed for actual CPU time your code uses. In Lambda, if you have a function that sends a request out to a machine that takes, say 5 minutes to respond, you are billed for 5 minutes of wall clock time plus the processing time for your code. In a Worker, you are only billed for the handful of milliseconds that you processed the function for, not the 5 minute wait to get the response from the other server.
I don't really know why, but this sort of isolate level sharing appeals to me massively. Especially for my small side projects, it is good to have a server solution that bills based on my actual usage without having the massive cold start disadvantages of something like Lambda. As far as I am aware, this V8 isolate server sharing exists only in two places in the entire world: Cloudflare Workers, and Deno Deploy. And since Deno has not yet shown pushy sales tactics, I am happy that an option outside of Cloudflare exists.
I didn't notice big changes between the last releases of Deno 1.x and Deno 2, though? They've been adding npm compatibility all along. I think they dropped some deprecated API's with 2.0. I've...
I didn't notice big changes between the last releases of Deno 1.x and Deno 2, though? They've been adding npm compatibility all along. I think they dropped some deprecated API's with 2.0.
I've used Deno Deploy a bit (only in the free tier) and it's pretty nice. Cold start isn't bad, but since it's an edge system with nodes in multiple regions, if you have your database in a single place (like US East), there will be more latency between the server and the database for people not in the eastern US. I tested connecting Deno Deploy to Neon for Postgres, and cold start seemed okayish for connecting to a database in US East from the west coast. You'll want to optimize database access to avoid round trips.
Deno Deploy also has a KV store that gives you local caching, and I managed to build a database system with a few tables and indexes using it, but I don't recommend it for anything complicated where a full database would be better. The 64k limit on values is annoyingly low and writing transactions for things like keeping indexes up to date is kind of a drag.
I would like to see some kind of SQLite integration. Deno actually uses SQLite when running KV locally. Cloudflare recently added SQLite to Durable Objects and it sounds like a nice way to do it.
For the database stuff, you might want to check out turso. Their schtick is to use SQLite for production databases. They even built their own fork of SQLite (because SQLite isn’t very open to...
For the database stuff, you might want to check out turso. Their schtick is to use SQLite for production databases. They even built their own fork of SQLite (because SQLite isn’t very open to outside contributions) called libsql. It is going to keep SQLite compatibility, but add a few features to enable the turso service. At its most basic, it just provides a server layer to a SQLite database so you can connect to it from something like deno deploy. But since SQLite is so simple, and a database that isn’t being actively used is just a file, they don’t have any limits on the number of databases. That opens up a ton of cool possibilities, like having an entirely separate database for every single user, and homing each users database in the region they connect to. I haven’t actually used the turso service, so I don’t know how much their marketing claims hold up in practice, but it seems really cool. I have used libsql for situations where SQLite was throwing some errors and it worked quite well.
Yes, sort of, but I'm not sure compatibility is good enough to use as a drop-in replacement. Compatibility does get better with each release. I use it for creating new hobbyist projects and avoid...
Yes, sort of, but I'm not sure compatibility is good enough to use as a drop-in replacement. Compatibility does get better with each release.
I use it for creating new hobbyist projects and avoid npm dependencies, but they do often work. I don't think there's a list anywhere of which npms work and which ones don't.
I'm all for it, but idk how much it really matters? Colloquially, among devs, it's "Javascript" and never "ECMAScript". The use of "JS" isn't much of an issue either as those that need to know...
I'm all for it, but idk how much it really matters? Colloquially, among devs, it's "Javascript" and never "ECMAScript". The use of "JS" isn't much of an issue either as those that need to know what that means do know. Not to mention the rise of Typescript (which still gets shortened to "TS" out of convenience more often than not).
That's the point Oracle will make, and then any competing products that use Javascript in any form, any mention, will be liable for destruction by Oracle. You should never test the waters with...
how much it really matters?
That's the point Oracle will make, and then any competing products that use Javascript in any form, any mention, will be liable for destruction by Oracle. You should never test the waters with them near, they will destroy you if they want.
Oracle needs to show a compelling reason for why they've earned the right to retain the trademark. It's their burden of proof to shoulder. "It doesn't really matter" isn't a justification for...
Oracle needs to show a compelling reason for why they've earned the right to retain the trademark. It's their burden of proof to shoulder. "It doesn't really matter" isn't a justification for anything.
Absolutely, and I'm not making a legal argument here. I'm just saying the state of the JavaScript trademark has very little bearing on the day-to-day lives of the people who write with it. Hence,...
Absolutely, and I'm not making a legal argument here. I'm just saying the state of the JavaScript trademark has very little bearing on the day-to-day lives of the people who write with it. Hence, I support the effort, but don't think it matters very much because it's not going to impact developers any.
I wasn't meaning to be confrontational or dispute what you were saying, so I apologize if that's the way I came across. More directly to your point: I don't think we can really know what...
I wasn't meaning to be confrontational or dispute what you were saying, so I apologize if that's the way I came across.
More directly to your point: I don't think we can really know what difference it might make, if any. The fact that we can't foresee any substantive consequences for revoking the trademark is itself a pretty compelling reason to do it. Shows that it's already de facto generic. The fact that the one petitioning to hold the trademark is the one that has the burden of proof just underpins that logic, which is why I mentioned it.
They don't care about JavaScript, they care about Java. If they release the JavaScript trademark into the public domain, it could potentially be easier to make a case for them releasing the Java...
Oracle doesn’t stand to lose anything.
They don't care about JavaScript, they care about Java. If they release the JavaScript trademark into the public domain, it could potentially be easier to make a case for them releasing the Java trademark as well. That's why they're holding onto it.
Really, calling it JavaScript was a mistake that should have been corrected a long time ago. The community should eliminate any and all confusion by getting rid of the Java and calling it just...
Really, calling it JavaScript was a mistake that should have been corrected a long time ago. The community should eliminate any and all confusion by getting rid of the Java and calling it just JScript!
This is fantastic! I hope they succeed. I love JavaScript as a language, and it would be good for this legal cloud to be gone. I also have to mention that deno, since 2.0, is absolutely fantastic to work with. I didn’t like every decision that they made in Deno 1, and 2 fixed most of my complaints. I don’t see any reason to use anything except deno for any modern JavaScript project.
So is Deno a replacement for node.js?
Deno is made by the same guy who originally made node. His goal is to make a modern JS runtime that fixes all the bad decisions that are in Node. It is also attempting to replace the entire tech stack for node. Npm is replaced with deno install. Prettier is replaced with deno format. Eslint is replaced with deno lint. They removed the bundler in v2, but they are trying to add it back in at some point. It runs typescript natively, so no need for tsc or ts-node. They also made jsr.io, a modern replacement for the npm registry. It is TS first, and I think it can even be used with npm/bun/yarn/etc. When it first came out, it wasn’t actually compatible with node, but with v2 they are advertising 100% node and npm compatibility (code written with deno in mind can be slightly different than code written for npm/node, but deno is backwards compatible with package.json, so you should be able to drop deno in to replace node and npm without issue).
Anywhere I can read about some of these and get a side-by-side? I hadn't heard of Deno before today.
The Deno 2.0 release announcement might be a good place to start. It doesn’t really compare against node, but if you are already familiar with node it should make sense why it’s better.
The deno v2 announcement video has a really good Q and A with the team. Also the production quality is fantastic.
Ryan Dahl gave a talk when deno first launched. That article links the video. I think the article gives a written overview of his talk, but I only glanced at the article and listened to the talk a long time ago. Keep in mind that this is from the original deno launch. The project changed considerably with v2. For example, deno originally didn’t have node compatibility explicitly, and now it tries to have 100% compatibility, including a node_modules folder if required.
Edit: they also have Deno Deploy, which is their hosted serverless infrastructure offering. On the surface, it isn't terribly exciting, but if you look closer at the details, I think it's really compelling. It's the only true competitor I have found to Cloudflare Workers. I think Workers are fantastic, and I have made some projects based on Workers and Pages Functions, but I try to avoid Cloudflare now because of their terrible sales tactics. What makes Workers unique is the level at which your code shares infrastructure with other customers' code.
In a serverless environment like Google Cloud Run, your cloud invocations are docker containers that respond to a request or job and then go back to a waiting state. Google keeps your container running for a short amount of time to respond to future requests and then kills the container. When you get a new request, Google has to load the image and startup an entirely new container. Often this means the first response will be unusually slow (called a "cold start"). AWS Lambda is almost identical to this, but they have some developer experience improvements. I think they also have docker containers they build themselves for specific languages that optimize this cold start time. But no matter the improvements, you still have to have an entire fraction of a server running an entire VM just for your code.
Cloudflare workers run your code in V8 isolates. This is a way to run separate untrusted code on the same V8 thread. Because of javascript's promise based async programming model, if your code is waiting for a network request or some other promise, that thread can easily run someone else's code without affecting anything. Also, since V8 is continuously running, a cold start only requires loading your code into the interpreter, making cold starts almost instant. They are so fast that (if I understand correctly), every single request is effectively a cold start since there is so little overhead. It also means you are only billed for actual CPU time your code uses. In Lambda, if you have a function that sends a request out to a machine that takes, say 5 minutes to respond, you are billed for 5 minutes of wall clock time plus the processing time for your code. In a Worker, you are only billed for the handful of milliseconds that you processed the function for, not the 5 minute wait to get the response from the other server.
I don't really know why, but this sort of isolate level sharing appeals to me massively. Especially for my small side projects, it is good to have a server solution that bills based on my actual usage without having the massive cold start disadvantages of something like Lambda. As far as I am aware, this V8 isolate server sharing exists only in two places in the entire world: Cloudflare Workers, and Deno Deploy. And since Deno has not yet shown pushy sales tactics, I am happy that an option outside of Cloudflare exists.
I didn't notice big changes between the last releases of Deno 1.x and Deno 2, though? They've been adding npm compatibility all along. I think they dropped some deprecated API's with 2.0.
I've used Deno Deploy a bit (only in the free tier) and it's pretty nice. Cold start isn't bad, but since it's an edge system with nodes in multiple regions, if you have your database in a single place (like US East), there will be more latency between the server and the database for people not in the eastern US. I tested connecting Deno Deploy to Neon for Postgres, and cold start seemed okayish for connecting to a database in US East from the west coast. You'll want to optimize database access to avoid round trips.
Deno Deploy also has a KV store that gives you local caching, and I managed to build a database system with a few tables and indexes using it, but I don't recommend it for anything complicated where a full database would be better. The 64k limit on values is annoyingly low and writing transactions for things like keeping indexes up to date is kind of a drag.
I would like to see some kind of SQLite integration. Deno actually uses SQLite when running KV locally. Cloudflare recently added SQLite to Durable Objects and it sounds like a nice way to do it.
For the database stuff, you might want to check out turso. Their schtick is to use SQLite for production databases. They even built their own fork of SQLite (because SQLite isn’t very open to outside contributions) called libsql. It is going to keep SQLite compatibility, but add a few features to enable the turso service. At its most basic, it just provides a server layer to a SQLite database so you can connect to it from something like deno deploy. But since SQLite is so simple, and a database that isn’t being actively used is just a file, they don’t have any limits on the number of databases. That opens up a ton of cool possibilities, like having an entirely separate database for every single user, and homing each users database in the region they connect to. I haven’t actually used the turso service, so I don’t know how much their marketing claims hold up in practice, but it seems really cool. I have used libsql for situations where SQLite was throwing some errors and it worked quite well.
Yes, sort of, but I'm not sure compatibility is good enough to use as a drop-in replacement. Compatibility does get better with each release.
I use it for creating new hobbyist projects and avoid npm dependencies, but they do often work. I don't think there's a list anywhere of which npms work and which ones don't.
I'm all for it, but idk how much it really matters? Colloquially, among devs, it's "Javascript" and never "ECMAScript". The use of "JS" isn't much of an issue either as those that need to know what that means do know. Not to mention the rise of Typescript (which still gets shortened to "TS" out of convenience more often than not).
That's the point Oracle will make, and then any competing products that use Javascript in any form, any mention, will be liable for destruction by Oracle. You should never test the waters with them near, they will destroy you if they want.
Required information for those curious about the nature of Oracle
Well I certainly hope the musings of some dork on the internet (me) don't hold up in court!
Oracle needs to show a compelling reason for why they've earned the right to retain the trademark. It's their burden of proof to shoulder. "It doesn't really matter" isn't a justification for anything.
Absolutely, and I'm not making a legal argument here. I'm just saying the state of the JavaScript trademark has very little bearing on the day-to-day lives of the people who write with it. Hence, I support the effort, but don't think it matters very much because it's not going to impact developers any.
I wasn't meaning to be confrontational or dispute what you were saying, so I apologize if that's the way I came across.
More directly to your point: I don't think we can really know what difference it might make, if any. The fact that we can't foresee any substantive consequences for revoking the trademark is itself a pretty compelling reason to do it. Shows that it's already de facto generic. The fact that the one petitioning to hold the trademark is the one that has the burden of proof just underpins that logic, which is why I mentioned it.
It does in the context of trademark. That is, in fact, the whole point.
Likelihood of confusion https://tmep.uspto.gov/RDMS/TMEP/current#/current/TMEP-1200d1e5036.html
They don't care about JavaScript, they care about Java. If they release the JavaScript trademark into the public domain, it could potentially be easier to make a case for them releasing the Java trademark as well. That's why they're holding onto it.
Really, calling it JavaScript was a mistake that should have been corrected a long time ago. The community should eliminate any and all confusion by getting rid of the Java and calling it just JScript!
...oh.
Script
ftfy