Unfortunately for many of the HTMX/Turbo people, they did right to identify the problem but they have the wrong solution.
The way to alleviate those issues is not to bloat the frontend with things that shouldn't be in it nor is it to fragment the code base with never ending "sprinkle" of JS.
The best solution is something like Gleam's Lustre, where you use the right tool for the job, while keeping a coherent code base:
Generally, the core components are open source. There are a few things like private DMs and mutes that do not get saved to your PDS, but are accessible with an authenticated client. The open source PDS implementation is still beta auiu. There is a limit of 10 accounts per server while it gets tested in the wild, last I saw
One thing to consider is that you do not have to reimplement the entire spec if you are only interested in building a feed or recommendation system. ATproto makes the core components plug-n-play, so users can use the Bluesky app while picking 3rd party providers for moderation and algo feeds
There is also an independent group with their own governance working to define a number of common lexicons for shared usage across applications
Is it possible to implement a functional subset of just serving one’s own DID identities using serverless functions? Then that would enable every average Joe to make their own with Cloudflare Pages Workers
You shouldn't need that much for a single DID. If you want to serve an org DID, like a bunch of users under the same ___domain, you need to do something like this.
where are you supposed to put the DID document on your ___domain? All documentation describes putting the .well-known/atproto-did file but not the actual DID document.
However, you don't need a document per day. It can be dynamically generated by a handler or server less function on that route. This is important as employees at an org change, this information could be obtained from a database
So for an organization, one might have a single handler responding to `*.atproto.company.com/.well-known/atproto-did` with the subdomain becoming the primary input variable
no, like I said I already know that .well-known/atproto-did returns the DID value, but there doesn't seem to be any documentation for where the inquirer will next expect to fetch the actual DID document to complete the circular verification.
I use Nix and agree with most of what you said, except the main value proposition of docker-on-dev-machine is not convenience, but approximation of production
Hi there! I am extremely glad to read someone else write about this necessity!
I own and operate a "list-taking" app[0] in which every list/kanban-item can itself be a list/kanban.
I currently use it for things I'm the creator of -- tasks, story outlines, etc, but looking to introduce 3rd party content for task management (I want to see GitHub tasks from work next to my own tasks) and, as you say, knowledge management of things like recipes or music.
Items could be part of one or multiple hierarchies. A list of "cake" recipes could be under both "baking" and "party essentials", and music playlists could include other playlists.
As you can tell, this can become convoluted in my mind, and so if that's something that's interesting to you (or anyone reading this), please reach out and let's discuss! hn at nestful.app
I may have come across your app before in passing, but hadn't checked it out. I playtested aspects of a "productivity system" (grain of salt) with paper earlier this year.
"Spontaneous productivity" mirrors some of my own thinking on the subject, especially the JIT and bubbling aspects and how they work together. I haven't seen how it works in the case of Nestful, but I'm keen to try it out. It may adjust the design principles guiding development.
I research live-action anime[0] and this looks really cool, especially if there's fine-grained control over each sensor and especially if you can change the lenses (in a supported or unsupported manner).
Anime has the advantage of being drawn frame-by-frame, thus able to "change" lenses, cameras, etc mid action-packed shots. Using this may allow for shooting two different setups at once, achieving a similar effect.
I'll add Loro[0] to the author's list. While I utilise Yjs heavily for another project, Loro is fairly featureful and so I picked it to build a screenplay editor[1], which requires things like Peritext or tree structures. It's fairly young, though.
I'll also commend the author's attempt at DIY! Even if your case does not require a custom solution, it's healthy to understand how your tools work.
We're probably one of the first to make a real tech bet on Loro. We inched our way into it, and plus or minus some edge cases, it is going very well so far.
Even on the edge cases, most of it just relates to what primitives are exposed in the API, and we've found the library's author to be highly engaged in creating solutions.
We've found it to be an incredibly well designed library.
After discovering and adopting[0] Lustre, I can't think of using anything other than The Elm Architecture. It is so much more ergonomic it's not even comparable to today's mainstream state management techniques.
I'm also building a screenplay editor prototype[1] in the Rust equivalent, Iced, and while not as ergonomic as Lustre and Gleam, it is TEA. Iced is still in flux but I have trust, considering System76 uses it to build Cosmic.
Gleam looks great. Reading the FAQ, especially why the don't implement type classes, I am a bit worried though that it leans to much into trying to be simple.
Minimalism can work in dynamic languages because they impose basically no restrictions on your types and you can have crazy complex ones for free but in a purely static languages a lack of more advanced type system features can make writing library code very annoying and make the language feel very boilerplaty. The advanced type system features that languages like Haskell or OCaml provide are not purely for academic wankery, some of them are extremely useful. Even Golang had to add generics.
I hope they don't fall in the same trap as Elm did where it got so obsessed with simplicity that super knee-caped the language. I mean the Gleam devs seem already be way more pragmatic. At least it seems to have a decent FFI which provides an important escape hatch.
One thing I always dislike about Elm and most of its offshoots is the lack of good composability of widgets. In most other architectures, most widgets are registered with their parent component in one single ___location, and are otherwise fully self-contained.
In Elm-likes you usually need to explicitly need to connect all child components in the model _and_ view _and_ update in a way that ultimately connects all leaf components to the root component. I know that there many Elm proponents that see that as a positive (as that makes execution more transparent). However in practice that usually ends up with either overly shared Message types where logic isn't contained to the widget it belongs to, or a boatload of boilerplate just to do .map operations between a child-Message-type and it's wrapping parent-Message-type.
I think this boilerplate can be solved by some degree with good framework support (and some try), but most Elm-likes don't and it makes scaling projects in them a pain.
Yes, that is the major problem I have with TEA. The best thing about Flutter's design is that it employs a "reverse iceberg" where many of Flutter's own widgets are composed with other widgets, leaving few architectural details "under the ocean".
That experience is lacking in TEA, although better in immutable languages like Gleam where it is easier to keep functions pure. Even in Iced, I'm going to side with those Elm proponents here and prefer Elm's function composition approach any day over guarding React or Flutter state from becoming spaghetti.
I wouldn't say it's outright wrong, I just much prefer the ergonomics of an orderly, TEA-like state management. Many of the projects I make lend themselves well to that approach.
The evolution is Gleam + Lustre (its main FE framework).
You get all of Gleam's advantages compared to TS (simple, truly type safe, errors as values, exhaustive match, etc), and Lustre is great because you get an Elm that can be run on both the client and server, using whatever fits that specific part of your website best (unlike HTMX or LiveView which are server-only).
OP didn’t say Gleam is dangerous in general. They said it’s dangerous anywhere around physical or financial values. Your app isn’t critically dealing with either, so it’s not really a retort to their point.
> keeping my client information's integrity is as important to me as keeping the financials
Nobody is questioning your intentions. People writing apps in memory-unsafe languages don’t give fewer shits. They’re just more prone to certain classes of errors.
> how the `1/0=0` problem can be entirely avoided
1/0 problems are generally expected to be entirely avoided. This is about where the system behaves unexpectedly, whether due to human error or the computer being weird.
Correct, these are all trade-offs we make when building a product. Choosing between the "1/0 crashes your program" problem and the "1/0 returns 0" problem is one such tradeoff.
All I was doing was clarifying the impression OP gave.
Now that we all know the details we can make whatever tradeoff we prefer.
Let's be clear. Gleam is still a bit of an esolang. If you had a company and onboarded a junior onto it would you expect them to know that 1/0 == 0? As a senior doing code review for said junior, would you be confident that you would correctly think through every corner case when you encounter the / operator?
Its the year of the Lord 2024, why is a new language putting in such a huge footgun out of the box in its stdlib.
> Gleam offers division functions that return an error type, and you can use those if you need that check.
Yes, but is that what any given developer will reach for first? Especially considering that an error-returning division is not composable?
The language puts people into a place where the instinctive design can cause very dangerous outcome, hard to see in a code review, unless someone on the team is a language lawyer. You probably don't want one of those on your team.
I think there's a reasonable argument for gleam to have an operator that does division resulting in zero but at the very least that should NOT be "/"
The way to alleviate those issues is not to bloat the frontend with things that shouldn't be in it nor is it to fragment the code base with never ending "sprinkle" of JS.
The best solution is something like Gleam's Lustre, where you use the right tool for the job, while keeping a coherent code base:
https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...