HN user

coreyward

20 karma
Posts0
Comments11
View on HN
No posts found.

Is 5 a reference to how you naked the prices so Neon doesn’t work for light-workload, moderate storage databases anymore? $69+ a month for a Segment data warehouse holding 10gb is obnoxious. It was under $10 before the switch. What’s next? $690/mo?

I doubt I’ll ever use Neon again after they had our production database go down several times over just a couple of months Q4 last year. We got tired of the downtime during an incident and we were able to spin up a Supabase PG instance and switch over to it faster than Neon could resolve the incident. It wound up taking them days to resolve it fully. They then increased the prices significantly about a month later. Given that it’s only been four months since these issues, I don’t think that they are serious people in the slightest and don’t trust them with a production database.

Use whatever tool you prefer, of course, but there are a few underlying assumptions here that I believe are erroneous.

Assumption #1: Design documents are contained in a file, and that file should be portable.

Tools like Figma are closer in nature to SaaS products than they are to native, file-based, raster editing softwares like Photoshop. You don't expect to be able to export your Slack workspace into a file and import it into another tool. You expect to have a means of migrating that data, potentially by exporting that data into a common format (e.g. JSON, CSV), transforming it into a format compatible with the target, and then either importing it using a provided tool or an API.

Assumption #2: Design tools all work similarly enough that document structures are largely portable.

While UI modalities remain similar enough on the surface, the underlying capabilities that produce the visual are exceedingly different. Look at type, for example—even Sketch and Figma, which are similar conceptually and of the same era, render type so differently that even robust import/migrate tools fail to capture the position of text within a few pixels for even basic, single-line, single-style text. Notions of seamlessly switching between tools disregards the real-world complexity of fonts, color profiles, raster manipulations, version history, comments, plugin-generated metadata, symbols/components, and more.

Assumption #3: There's no way to export a Figma document.

You can get the entire document structure from Figma via the API. This is the same data the viewer uses to render the document. You do not need to understand the internals of the .fig files.

Figma's case is more challenging in some ways, too, though. In multiplayer games, like the one described on your website, you rarely have multiple actors independently manipulating the same object, there's a moderate tolerance for imperfect resolution of conflicts, and the server can reject messages that are more than a few seconds out of sync with the server state.

Figma needs to have very consistent, predictable resolution in order for users to trust it with business-critical documents, and it needs to allow users to operate offline for arbitrarily long periods without throwing their work away when they reconnect. This has to happen across multiple versions of the software, and across documents (e.g. when dependency libraries are republished).

Users are currency in the business of the web, and until putting a 5+ digit number of signups in your deck is ineffective, we'll optimize for the collection of email addresses over engagement.