tlarkworthy

Yes with "debugger" in JS and 'breakpoint()' in Python. It's great!

For defensive programming I have a common assert routine which does all of the above

I throw errors (it's appropriate to stop code execution). But I also log it, so I can see it historically, but now I also do a 3rd thing!

I invoke a programmable breakpoint, so that if I happen to be debugging that code, I get the debugger setup where I want it!

Note this is only appropriate for things that should "never" happen.

I guess more important is that firebase transmits the current state of the database every reconnection

SVG is part of HTML and good for most of the needs except for the audio wave stuff (which Delphi couldn't do either)

queues either end. Clients are given a session ID, server (and client) replays missing messages on reconnect. It's the only way to achieve causal consistency, which is what you need for a sane programming model

https://observablehq.com/@tomlarkworthy/redis-backend-1

you need a queue to do that properly, do your users have to manage that queue?

So you will lose messages.

"Phoenix uses an at-most-once strategy when sending messages to clients. If the client is offline and misses the message, Phoenix won't resend it. Phoenix doesn't persist messages on the server. If the server restarts, unsent messages will be gone. If our application needs stronger guarantees around message delivery, we'll need to write that code ourselves. Common approaches involve persisting messages on the server and having clients request missing messages. For an example, see Chris McCord's Phoenix training: client code and server code."

https://hexdocs.pm/phoenix/channels.html

It will be impossible to build a reliable mobile experience on top of such shaky foundations.

What happens over an unreliable network connection such as mobile?

One issue is that viewing VR on 2d is incomparably worse than experiencing on a VR set. The feeling of presence makes up for the bad graphics. You feel much more connected to content in VR than you do with a AAA game on a projector, despite it's low poly look.

Yeah, you are right. I made https://webcode.run also for this reason (also hot code reload and debugging but for JavaScript computational notebooks)

some backend stuff as well https://observablehq.com/@tomlarkworthy/redis-backend-1

My wife and I write an annual letter to one another. They are truly magical and they are great to read back, often bringing us to tears and capturing the struggles of raising children, moving continents etc. They unleash memories when read. We have ten years of them and they are truly amazing and I recommend it as a slightly less involved shared (two way) ritual .

I live in Berlin and u must have not been out here coz many places, especially clubs, allow smoking indoors.

This was why I created https://webcode.run the elimination of all tooling and a fast development loop even for backend

With observable notebooks you can install Sentry and run regular health checks. I recommend this as a step in productionization and made a notebook with embedded video on the topic https://observablehq.com/@tomlarkworthy/productionization?co...

The horrible thing is that it is slow, hard to debug and develop on. I personally think it is a bad tradeoff and will make developers hate their day.

I do similar but use centrafugal forces to spin dry them almost dry with arm swings. Then I use toilet tissue dabbed to get the final few drops off (not wiped!). Toilet tissue can be scratchy so you might want an alternative but for me it's not doing much work and it's always at hand.

I recently streamed firebase into duckDB for realtime exploratory analytics in the browser (on Observablehq)

https://observablehq.com/@tomlarkworthy/firebase-to-duckdb

I used to work for Firebase, this is a common problem. For my own developer focussed startup I have prevented functions from calling each other to an unbounded depth, exactly so this footgun is removed.

The technical details is outbound requests is given a role encoded in the user-agent, and then I can easily filter out incoming requests by user-agents [1].

[1] https://observablehq.com/@endpointservices/webcode-docs#opti... (see loop prevention flags)

It's easy to poke a hole in a methodology, but this was a pragmatic short curcuit of collecting websites as they are in the wild. You could ask 10 experts to code up equivelent websites and measure performance and still someone would complain that it's a synthetic benchmark. The nice thing about this methodology is that noone was expecting the dataset to be used for this purpose. It is an interesting set of measurements in my opinion.

Edit: the biggest issue is that the article is vunerable from severe confirmation bias from the authors admitted sunken costs

I misadvertantly lower cased my functions names when working on .net, but it made it super easy to find my code in the stack traces. (.net idiom is capitalism the first case of a function name). Usually the cause of stack traces was my code so it was an unexpected productivity booster.

I use plausible analytics to measure traffic on my observable notebooks. I did try with GA but it didn't work with Observable's iframe sandboxing. Because plausible is open source, I could fiddle with it a little and could get it to report the top level page user facing URLs instead of the iframe's. Very happy I can get traffic stats from a site I don't own and very happy I don't need user consent because it's GFPR compliant. It tracks just what I am interested... My traffic, and with a little config it excludes my own page views. Great product, perfect for my use case I wish them well.

https://observablehq.com/@endpointservices/plausible-analyti...

Of course it's a problem, that cache is not shared across domains, so it will be the initial experience of your users. Perhaps they can do some kind of lazy loading magic to hide it eventually

Firestore has better SLO than Confluent's own managed Kafka offering (5 nines [1] vs 4 nines [2]).

If you use it as a system component and not a do everything backend it is the most production ready clientside technologies on the planet.

[1] https://docs.confluent.io/cloud/current/clusters/cluster-typ...

[2] https://cloud.google.com/firestore/sla

Actually I think Convex team are right, synchronous functions or database views would be huge improvement to Firebase.

Firebase Functions are asynchronous, and can be reordered relative to DB operations. They would be much more powerful if synchronous and on the wrtie path (so you could put auth logic in them instead of being forced to use the bespoke security language).

Firebase functions are at-least-once though, so they are pretty good but could be better.

I spoke at HYTRADBOI too! https://www.hytradboi.com/2022/creating-a-wire-compatible-fi...

> Consistency-wise Convex supports full serializability.

As discussed elsewhere both Firebase DBs too and also provide clients with a causally consistent snapshots too, so you are not actually adding anything over the Firebase offering. Firebase has optimistic updates too and can use clientside persistent storage (I think convex has just an in-memory cache at the moment).

> e.g., having to fetch a list of posts first before knowing which post ids to fetch comments for.

Yes this does perform badly. Though this type of join is also an IO hog on a relational DB too, just it's not so visible.

I was an early developer at Firebase. I think we made Firebase so easy to use and never spoke on about the technicals that the whole software ecosystem now underestimates the complexity involved. I see various Firebase competitors asserting various "mistakes it makes" without really understanding what it delivers, which is understandable because we never marketed it like that because we spoke only about how it can help you build easier.

The idea that n queries instead of a join is slow is not as true as you would think. Firestore supports streaming and pipelines at its core, and can reuse cache across operations. At the end of the day, the data goes over a narrow network channel. If you can saturate the channel, and don't leave any gaps, what's the performance difference if the data comes from a single query or many that are back-to-back. The data is transferred to the client either way. Both Firebase databases are pipelined, so this "many round trip" argument is not a decent argument if the client can issue the queries without waiting for responses (such as the code in this article).

The other is consistency levels and correctness. I constantly see devs call Firebase an eventually consistent database which is wrong, its causally consistent [1], and this makes a huge difference when trying to do OLTP. The offline capabilities are built on the consistency primitives, and it's the only way it can work. So while this convex article is banging on about "End-to-End Correctness Philosophy", they miss the most important quality of correctness, and if they are not careful, will miss the required engineering, and then be unable to deliver an offline cache over real-time streams. I see this playing out with Supabase, I warned them personally before they got into YCombinator that what they were building was not causally consistent. Since then, they have had to rearchitect their real-time features after shipping them. (I have not reviewed their latest design yet so I have no idea whether they have it right yet).

Many things sucked about Firebase. The bespoke security rules and the lack of views. So Convex is on the money shipping functions on the backend. I think Supabase is shipping competitors' mistakes with row-level security language. Personally, I think Firebase's mistakes can be fixed with the addition of an open-source Firebase server [1], as the clients are already open source and the mistakes are all to do with just the server. The real tech was always in the clients anyway (offline cache, connection management, operation queues).

It will be interesting to see if building expressly for React is a good idea. Firebase shipped many adapters, like https://github.com/FirebaseExtended/reactfire, using the "thin-waist" principle of not over-fitting. But Javascript technology moved from callbacks to async while Firebase was in the field, so the current API is not now idiomatic. But convex is setting itself for even more ecosystem fragility, what if React changes API or falls out of favor? This is a big risk! I hope they can roll with whatever happens!

[1] https://observablehq.com/@tomlarkworthy/redis-backend-1

Web is not trustless

DNS is part of the web and it is a federated/heirarchical 3rd party trust model you need to route your named traffic to the right server, often managed by states. It's super important to understand, this is why authoritarian governments can still hide what citizens can experience on the internet

yes your right, I can get external copy and paste working, I just have to switch key bindings mid-flight. Still, my main point is that LUA and Love conspire to make development of this kind of software difficult. IMHO. It's a suboptimal tool choice for the job. Its making the journey longer. The choice of using JSON over SVG is basically because you have no SVG facilities at hand. Please continue your good work on a better substrate, I mean this as constructively as possible.

It's very interesting that the article has resonated so well. I am fairly sure it means 99% of people have not tried it. People will not try it because the install process is painful, which is another issue with LUA/LOVE.

The use of LOVE is the biggest limiter IMHO, simple stuff is missing because a game engine does not really cater to text editing in any meaningful way. The copy and paste keybindings are wrong on Mac for instance. Selection behaviour is a bit weird and non-standard. I am not even sure you can paste from an external text source etc. Everything clearly has had to be custom made.