It’s a cloud service - so you can call out to it from anywhere you want. Just don’t ship your credentials in the app itself, and instead authenticate via a server you control.
Is there a chance you could ask Ryan if he had an LLM write/rewrite large parts of this blog post? I don't mind at all if he did or didn't in itself, it's a good and informative post, but I strongly assumed the same while reading the article and if it's truly not LLM writing then it would serve as a super useful indicator about how often I'm wrongly making that assumption.
> Over the past year, we’ve seen a shift in what Deno Deploy customers are building: platforms where users generate code with LLMs and that code runs immediately without review
This isn't a canonical use of a colon (and the dependent clause isn't even grammatical)!
> This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review.
Another colon-offset dependent paired with the classic, "This isn't X. It's Y," that we've all grown to recognize.
> Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.
More of the latter—this sort of thing was quite rare outside of a specific rhetorical goal of getting your reader excited about what's to come. LLMs (mis)use it everywhere.
> Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding.
Good writers vary sentence length, but it's also a rhetorical strategy that LLMs use indiscriminately with no dramatic goal or tension to relieve.
'And' at the beginning of sentences is another LLM-tell.
Yeah, I feel like this is really the smoking gun. Because it's not actually deeper? An LLM running untrusted code is not some additional level of security violation above a plugin running untrusted code. I feel like the most annoying part of "It's not X, it's Y" is that agents often say "It's not X, it's (slightly rephrased X)", lol, but it takes like 30 seconds to work that out.
Can it be that after reading so many LLM texts we will just subconciously follow the style, because that's what we are used to?
No idea how this works for native English speakers, but I know that I lack my own writing style and it is just a pseudo-llm mix of Reddit/irc/technical documentation, as those were the places where I learned written English
Yes, I think you're right—I have a hard time imagining how we avoid such an outcome. If it matters to you, my suggestion is to read as widely as you're able to. That way you can at least recognize which constructions are more/less associated with an LLM.
When I was first working toward this, I found the LA Review of Books and the London Review of Books to be helpful examples of longform, erudite writing. (edit - also recommend the old standards of The New Yorker and The Atlantic; I just wanted to highlight options with free articles).
I also recommend reading George Orwell's essay Politics and the English Language.
Given that a lot of us actively try to avoid this style, and immediately disregard text that uses it as not worth reading (a very useful heuristic given the vast amount of LLM-generated garbage), I don't think that would make us more prone to write in this manner. In fact I've actively caught myself editing text I've written to avoid certain LLMisms.
It's unfortunate that, given the entire corpus of human writing, LLMs have seemingly been fine-tuned to reproduce terrible ad copy from old editions of National Geographic.
(Yes, I split the infinitive there, but I hate that rule.)
As someone that has a habit of maybe overusing em dashes to my detriment, often times, and just something that I try to be mindful of in general. This whole thing of assuming that it's AI generated now is a huge blow. It feels like a personal attack.
"—" has always seemed like an particularly weak/unreliable signal to me, if it makes you feel any better. Triply so in any content one would expect smart quotes or formatted lists, but even in general.
RIP anyone who had a penchant for "not just x, but y" though. It's not even a go-to wording for me and I feel the need to rewrite it any time I type it out of fear it'll sound like LLMs.
It’s about more than the emdash. The LLM writing falls into very specific repeated patterns that become extremely obvious tells. The first few paragraphs of this blog post could be used in a textbook as it exhibits most of them at once.
Considering Fresh as an option for a project I found it baffling (to say the least) that it had shipped an 1.0 with Tailwind as the only option for styling and even more that 2.0 is not even starting to address the topic.
Hiya. No questions but just an fyi: the version of `@fresh/init` mentioned in the article (`2.0.0-alpha.30`) fails to run. Looks like latest at this time (`2.0.0-alpha.33`) runs successfully.
As a hobbyist programmer, I’m wondering how the Open Telemetry support would be useful to me? I’ve read about tools like Grafana on Hacker News, but never installed any of them.
Only recently... and yes, to Deno's great credit. Deno has an amazing team and this isn't commentary about their hard work; just disagreement with one of the early decisions.
Neat. But for a relevant query, try searching for "npm" instead. 0 issues listed. Further, in the `deno_npm` repo for npm resolving by the deno cli, there are two open issues. One is a feature request, and the other is not clearly an important issue.
Deno is probably not "fully" NPM compatible, arguably, because you still need to prefix imports with "npm:" in a lot of cases. I've filed PRs to that effect, is why I know -- a breaking change for many widely-deployed libraries that need to maintain older node compat. That should not be necessary for a runtime that is "fully" NPM compliant.
Aside from that, Node compliance is a much larger ball of wax than simple NPM compliance, and as far as I know Deno is not there and will not be there for some time.
My gripe with Deno is the choice to hard-fork. That is core to the idea; so, we will disagree. No big deal. As a result of Deno's choice, people now have many runtimes to choose from: Bun, LLRT, and the one I have written on top of GraalJs, Elide. Many others, too.
Most of these runtimes shoot for as full NPM / Node compat as they can muster without intolerable contortions in the code. Why? Because a ton of software out there runs on NPM, or on Node APIs. Users think of server-side JavaScript and Node as the same thing -- this is not true, Node is both the "Node APIs" and the V8-based engine underneath it.
But this is exactly what I mean: for Deno to claim that Oracle does not "use" the JavaScript trademark requires a completely ignorant stance about technologies like GraalJs. Last we benched, Elide (on top of GraalJs) outperformed Deno by a wide margin. Oracle has invested years of engineering work into it. Enough that it outperforms Node (by a long shot) and Deno, and typically ties with Bun. So why does Deno get to say what happens with the trademark? It makes no sense to me.
I might even agree that Oracle should not own it or control it the way they do. I don't know. But I do know that Deno's demands are Node-centric, and the JavaScript ecosystem is simply way bigger than that.
I think the history, causes, and goals here are getting a bit wobbly. Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno. I'm obviously not him, so I can't speak much about all of that.
Node compatibility is interesting because it's only useful until it's not. If all these other runtimes eat away enough at node's share, it won't make sense to be compatible with node anymore.
Just to finish the original discussion, as much as I love talking about the current state of js (heh) runtimes: the mention of graaljs supports deno's argument. Oracle, for whatever reason, used "js" rather than "JavaScript".
GraalJs is just a name. It was created by Oracle so they can use the trademark if they want to. I have no idea what you are talking about.
> Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno
Yes, I explained that we disagree. Clearly he also feels he was wrong about Deno’s NPM choices since he reversed course and added NPM support. So Ryan agrees with me, I guess.
> If all these runtimes eat away enough at node’s share
WinterCG and other efforts are formalizing APIs that can be shared across runtimes. Which is great. Many of these APIs are at least informed by, if not outright standardized versions of, Node APIs. They are here to stay.
That's a poor stats to be polite. SQL is no programming language, PL/SQL and its variants are. Without scripting languages you can't embed much logic in it.
I also wonder how they count multi users, I can easily mark 10 of those if not more.
> HTML/CSS were the most commonly used programming languages
I am sorry but that can't be taken seriously, then I know a ton of Excel developers, and wait till I get to Powerpoint ones.
Brendan Eich, the creator of JavaScript and a co-signatory of this letter, wrote in 2006 that “ECMAScript was always an unwanted trade name that sounds like a skin disease.”
Then this is not a matter of trademark or identity. It is only a matter of marketing. If this is just a matter of trademark my comment remains equally valid. Just use a different name.
Oracle gets no real benefit from the trademark, and getting everyone to stop calling it JavaScript is basically impossible. It would be better for everyone for Oracle to just abandon the trademark.
I don't expect Oracle to actively release the trademark, but it would be better if they did.
