kwhinnery

Hey all! Kevin from Stainless here to answer any questions you have. tl;dr overview of what we built:

- SDK, REST, and narrative docs in one

- Lots of nice docs features and UI components out-of-the-box

- Built on Astro, so you can hack anything and deploy anywhere

Looks awesome, will keep this in mind - every so often you need to create complex documents in code, and it's always a pain. Doing it with a familiar modern programming interface would be nice.

In terms of "when you would use it" - it doesn't necessarily solve a different problem than npm. I think it arguably solves the same problem more effectively (though it is certainly early days and npm still does a lot of things JSR doesn't). I also don't know that we're segmenting the ecosystem, as JSR packages interoperate with npm packages, and you can use one from the other. JSR will end up being additive to npm.

For module authors, we're hoping JSR will be helpful in the following ways:

1.) You can develop and publish TypeScript source, and let JSR handle transpilation and generating .d.ts files for runtimes that don't natively support TypeScript. Especially nice if you are using Deno or Bun (that do natively support TypeScript), and don't have tsc in your workflow otherwise.

2.) JSR generates API docs for you on your package page based on your source code and comments.

3.) JSR has a great DX around publishing packages from GitHub Actions using OIDC (no juggling tokens)

4.) JSR automatically provides provenance for published versions of packages

For module consumers, it helps too:

1.) Compatible with both Deno and existing npm-based projects

2.) Package info and docs provided centralized on the jsr.io site

3.) Quality scores that encourage authors to make their packages fast and well documented

4.) Access to TypeScript source for packages (not just transpiled output)

Absolutely more to be done, but we're hoping that JSR will provide enough extra value to both module authors and consumers that both will prefer to use it when possible.

HTTPS imports will continue to work and be supported in Deno. However, as we observed their usage in the wild, a couple problems became clear:

1.) Duplicated dependencies - projects would often download multiple versions of the same dependency, because there was no deduplication happening based on semantic versions.

2.) Disappearing dependencies - under some circumstances, an HTTPS import URL would be unavailable, causing code dependent on these modules to break.

A central package repository could solve for both of these problems. We considered (and very nearly chose) to just use npm, but it introduced functional and UX problems we wanted to solve for users. So we set about building JSR, and did so in a way that wasn't tightly coupled to Deno (JSR didn't need to be - it is useful in the context of any JavaScript runtime).

Thankfully JSR won't be capable of a left-pad situation where packages can be unpublished - published packages are immutable[1].

As for the potential for disagreements over whether or not a scope should be transferred, that is a big reason why we want to figure out community involvement in governance sooner rather than later. We are gathering potential volunteers who want to discuss becoming a community moderator - if anyone would be potentially interested, they can sign up to join that conversation[2].

[1] https://jsr.io/docs/immutability [2] https://jsr.io/go/moderator

The new scope owner would be able to update "@cocacola/foo" and publish new versions (previous versions would be unaffected).

This is probably a marketing bug on our part. While we did want to design for TypeScript from the outset, you can definitely happily write and publish plain JavaScript code on JSR. We probably need to do a better job explaining and featuring this.

I think this is mostly right - "superset" in that JSR modules can depend on npm modules, and projects using npm can use the npm registry and JSR together. The bottom line we'd want to communicate is that JSR is additive to npm, and the two can be used at the same time.

That does get to be a mouthful! But if you wanted, you can of course do:

yarn global add jsr

so that subsequent installs could just be:

jsr add @oak/oak

We do intend to take a more editorial approach to scopes, and assign scopes to users in a way we think is more intuitive for end users of JSR. We have reserved some obvious scope names already, but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name).

So in the case that a user published "@cocacola/foo", previously published versions of "@cocacola/foo" would remain available indefinitely (unless they were found to be malicious), but we would likely be willing to assign ownership of the "@cocacola" scope to a representative from that brand/company if they asked for it and we could verify their identity. The original author of "@cocacola/foo" would need to publish the module going forward under a different scope.

Not yet, but esm.sh mentions they have experimental support now to check out: https://twitter.com/jexia_/status/1762516242626416750

As JSR develops, you can expect to see more features like those of dnt start to show up in the npm compatibility layer. We've also been exploring how to create a good DX around simultaneously publishing JSR modules to npm, so publishers can control their namespace there as well. We definitely know it's a usage pattern folks are interested in.

In the immediate term, dnt is still a very strong choice for people that want to develop modules in TypeScript using Deno, and then publish them to npm. In the fullness of time, I expect that JSR will provide a pretty complete solution to this problem as well.

Kevin from the Deno team here - happy to answer any questions you have today!

I know it's hard to know this since not everyone has access to JSR yet - but it's incorrect to say that adopting JSR (as a module author or consumer) will result in breaking changes. JSR is additive to npm, and can be used alongside npm in existing projects.

Node.js / npm module consumers will be able to use packages published to JSR with minimal differences from packages published to npm. Here's what that will amount to:

- The install command will be different - "npx <jsr command> i @foo/bar" versus "npm i @foo/bar") - some of the configuration will end up looking different when you inspect it. JSR's npm integration makes use of npm aliases and requires a minor configuration change to .npmrc (that will be done for you by the command to install)

But at the end of the day, JSR is integrating with npm using its existing extension points, not replacing or circumventing it. As a practical matter, your Node.js code that imports dependencies from JSR will look the same as code that imports dependencies from npm. It's all coming from the node_modules folder at runtime.

Whether or not module authors choose to use JSR is more about DX than platform support (JSR works well in Deno and any kind of project that uses a node_modules folder). If as a module author, you would find it useful to:

- Publish actual TypeScript source files to the registry rather than build artifacts - Have API docs auto-generated for your package from source code - Use a registry with an explicit goal of being usable across JS runtime environments (rather than being tied to Node specifically)

Then JSR will likely be worth checking out. We'll be opening up JSR to everyone to try soon, so hopefully you can take a look and decide for yourself then :)

Hi there - Kevin from the Deno team here. Thanks for starting this conversation - the recent reduction in regions is part of an ongoing effort to drive down the cost of the platform for customers. We are still learning and iterating as we figure out how to operate the service efficiently. If the new region configuration is causing major problems for you, or might prevent you from considering the service, definitely let us know by sending a message to support at Deno dot com.

Also, we can do better at proactively communicating these changes and releasing doc updates at the same time as rolling out the changes. We will document the current region list ASAP, and revisit how we communicate these changes in the future, so infrastructure configuration changes won’t be surprising.

EDIT: The docs should now have the full list of regions - https://docs.deno.com/deploy/manual/regions

I think the ecosystem is inching in this direction. There are already some interesting PoCs out there using Tauri (Rust based) and the deno_core Rust crate.

The usage of the word "ideal" in the 2021 post was probably not ideal :)

The accessibility and diverse ecosystem of JavaScript, owing to its status as the lingua franca of software development, would probably be the basis for it being "ideal". I think it would be hard to make an objective claim that one programming language is strictly better than another as a programming language for mathematical ideas.

User-level access control (like ACLs for authenticated users) or something else? Feel free to share longer form thoughts here and I can make sure we keep this concern in mind.

ngl this is a little cursed, but awesome

Just jumping in here to applaud the usage of "luddite numpties" in a sentence.

I was surprised by the quality of the results from Claude, I hadn't used it until recently. I asked it for strategic advice about playing a game of Magic: The Gathering and it gave what felt like pretty nuanced advice (talked about "resolving" spells, which is parlance only really used by avid players).

Sorry to hear this has been challenging - were you trying to do something like this, where you select a row in the table, and then make another API request with data from that row?

https://retoolhacks.retool.com/embedded/public/17eebce9-96f3...

If this is close to what you're looking for, you can import this sample app from this JSON export:

https://gist.githubusercontent.com/kwhinnery/4fed2a80788f429...

Absolutely agree, and something we were discussing today as it happens on the docs crew. We have some ideas we'll try in the next few months to bring more docs directly into the product, and beef up coverage and examples in the component docs.

Hey there! We are actually working on a video course for Retool that covers more of the breadth of the platform. Definitely more to come. One more substantial example we released recently is this bookstore application, which uses about every part of the platform [1]. It's the app demoed at this virtual event, Retool Developer Day [2].

1: https://github.com/tryretool/bookstore_sample_app

2: https://www.youtube.com/watch?v=cmLPdHqC0uQ

It's true that a lot of adjacent tools in this space are built for non-developers. But if you try Retool, I think you'll notice that it's definitely not "no code" - any interesting application will require a significant amount of JavaScript to handle key interaction events and API/database integrations. The experience is closer to iterations of the Xcode Interface Builder where you'd visually design the UI/layout, then specify event handlers in Objective-C/Swift. It's much less code overall because you aren't doing boilerplate UI structure, styling, and low-level interaction event handling (focus and keyboard events, e.g.), but all the interesting stuff about your app still needs to happen in JavaScript.

Retool is still working out parts of the SDLC around modularity and the equivalent of a git flow for visual app development. Lots of energy going into this, would stay tuned for updates this year.

As you're grokking the mobile platform (or Retool generally) I think it's helpful to keep a couple things in mind.

- At least for now, Retool is designed and optimized for CRUD apps and operations software. On the mobile side, that will mean field workforce applications and mobile data entry stuff. If you need to provide a consumer-level user experience, building native (or React Native / Flutter at least) is probably your best bet.

- Consider solving problems with software on a spectrum from (approximately):

Spreadsheets > Airtable/Zapier > Retool > 100% custom UI (React & friends)

There is an appropriate time and place to deploy all these tactics. The sweet spot for Retool is for those use cases that can benefit from being codified in software (the flexibility of a more spreadsheet-y approach is detrimental/insufficient), but the business process is more important than granular control of the UI presentation. Instead of going full-on React, you can assemble a software-driven flow in Retool with about the effort it takes to assemble a non-trivial Keynote presentation (provided you know JavaScript - Retool is much harder if you are not a developer).

As always, there are trade-offs to consider when selecting the right tool for the job!

(disclaimer - I work for Retool)

This take is correct IMO - it's only worth building a tool if it saves you more time than it takes to develop. This is why Retool exists - if building/changing an admin tool takes about as much time as assembling a Keynote presentation, then the economics of using custom software to solve small problems start to work out in your favor.

Curious to hear if folks have found other definitions for this class of software that are inclusive/descriptive

Is the vision here that eventually I just have ngrok sit in front of my web app server(s) to handle authentication, rather than doing it at the app layer? And then ngrok in theory forwards on headers or whatever info I need for the authenticated users, like a middleware sitting on top?

Two fun facts delivering strong ROI for my visit to HN today, much appreciated!

+1 - I don’t think this would work on the wet, angry snow we get in Minnesota in the winter.