samwillis

People have said the same about browser engines, that it's impossible to start and new one and catch up due to the unfathomable number of man hours invested. But it's happing, Ladybird browser is making incredible progress. With modern tools, the learnings from older engines and the lack of entering debt it's possible for a small team to build things on par or better than 30yo software.

I have no doubt that a small dedicated team could build a new parametric kernel and CAD package, particularly one that's open source.

For fillets to work well they have to connect three important features of a parametric CAD package:

1. Surface tangency matching - perfectly matching the tangent of the connecting surface on either side of the corner.

2. Edge tangency following - you select an edge, and the fillet should be able to follow along all connected tangent edges.

3. Edge reference tracking - when you modify the model further up the feature tree the kernel needs to keep track of that edge, even if the surfaces that make it drastically change or are split.

All three are hard problems on their own, once you connect them all it becomes a great indicator of the capabilities and stability of a parametric kernel.

I don't think think this is a problem at all, the industry has standardised on STEP for assets, as long as CADmium and Truck have STEP support (which they will) then they have access to all assets. True, there are dynamically configurable assets for SolidWorks, but any community around a cad package will quickly recreate those.

I'm very excited about what Matt is building, the world desperately needs a good open source parametric CAD package. One where the UI/UX is designed to be as "easy" to use a SolidWorks.

The biggest reason this hasn't happened so far is the lack of a truly capable parametric kernel, Truck, the kernel that Matt is using looks like an incredible project and exactly whats needed. The only other kennel till now that been close to being whats needed is OpenCascade, but its lacks important features, is buggy and at times quite unstable.

Once Truck (and CADmium) lands stable fillets (surprisingly one of the hardest features to make stable) it will prove itself as the perfect successor to OpenCascade and and the perfect platform to build the future of open source parametric CAD upon.

With PLv8 you can run much of your server side logic I. The database, even React server components: https://react-postgres-components.vercel.app/

The best things that's happening in the Postgres ecosystem right now is the separation of compute and storage. Breaking that link opens up Postgres as a generic query processing engine that can sit in font of multiple different table and storage types. It allows joining between all these different types of data. It really will enable you to use Postgres as generic database for everything.

My theory is that every new database tech starts and a new domain specific db, then over time gets merged into the generic engines to serve the 99%.

Solving this is high on my list with PGlite (https://github.com/electric-sql/pglite). I have a bunch of iteas/thoughts that I hope to get to at some point (IVM, streaming queries, result diffs).

When PGlite (or SQLite) is used with Electric (https://electric-sql.com/), we already provide good reactive primitives. But we hope to improve this so that where possible the full queries don't have to be re-run.

OP is correct, the official WASM SQLite build is a sync only build and doesn't support async VFSs (which a IndexedDB VFS needs to be as it's an async api, unless you load the whole file into memory).

The best option for IndexedDB backed WASM SQLite is wa-sqlite, it offered both a sync and async build and a bunch of different VFSs, including an IndexedDB one. Note however that the async builds add significant overhead and reduce performance.

The most performant VFS is the "OPFS access handle pool" VFS that Roy developed for wa-SQLite and the official build also adopted as an option. That would be my recommendation for now.

Interestingly Stripe started life as /dev/payments and I seem to remember the first iteration was an agent on your server that literally processed card payments when you wrote the details to /dev/payments

Exactly, second time round it's going to be a civilisation built on recycling. It's crazy to think that by going slightly backwards the whole way forward would be so different.

Early civilisation was hunter-gatherers, scavenging for food and resources. Imagine a new civilisation where we scavenge the remnants of where we're are now. The progress forward would be very quick, but also so very different.

I work on PGlite [0], integration testing is absolutely something we want it to be useful for. For an early data point the Drizzle integrations tests run in about 1/4 the time with PGlite in-memory than a full Postgres.

The OP mentions lack of extensions being a blocker for them using it now, they are coming soon. Additionally it's currently limited by being single connection, and again I hope we can remove this limitation.

I also have a few other ideas around how to make supper fast testing possible.

http://github.com/electric-sql/pglite

The paradigm shift that's going to come with distributed SQLite isn't to the edge, it's going to be to users devices. I believe the DX of building Local-first apps is going to hit the criticality point in the next year or so and its popularity is going to explode.

With dynamic partial replication you can synchronise a subset of your database to a SQLite db on your users device, eliminating the network from the ui interaction loop. Then with the emerging eventually constant syncing systems, many using CRDTs, it's possible to have conflict free eventual consistency. Just read and write to a local database and it will sync with your central server or other clients in the background, both in realtime or after working offline.

I work on one such system at ElectricSQL, but there are many people building variants of this such as Evolu, SQLsync, CR-SQLite, and PowerSync.

That's all not to say SQLite on the edge isn't really damn cool!

This looks really cool, awesome work!

Correct on PGlite only being single user at the moment, and that certainly is a problem for using it for integration tests in some environments. But I'm hopeful we can bring a multi-connection mode to it, I have a few ideas how, but it will be a while before we do.

There are a few other limitations with PGlite at the moment (related to it being single user mode), such as lacking support for pg_notify (have plans to fix this too). Whereas with this it should "just work" as it's much closer to a real Postgres.

I think there is a big future for these in-memory Postgres projects for testing, it's looks like test run times can be brought down to less than a 1/4 with them.

(I work on PGlite)

The story of "Project Azorian" and the Hughes Glomar Explorer (the ship this crane was first used to construct) is a Wikipedia hole perfectly sized for a Saturday and some coffee. Well worth reading if you haven't before:

https://en.m.wikipedia.org/wiki/Project_Azorian

https://en.m.wikipedia.org/wiki/Glomar_Explorer

This is important to look back on in the context of what's happing now with AI tools. This story is obviously about the leak of the data publicly, but what it shows is the profiling that is available to corporations.

Search has exposed so much data about ourselves to the services we use with very little regulation on what they are permitted to do with it inside their own walls.

My fear with AI is that we are moving toward sending even more data to party services. Tools such a co-pilot (which I enjoy using) are a gold mine for behavioural analysis. The profiling that will be possible with these tools is extraordinary and we don't yet fully understand the implication.

It's because of this that I'm a massive proponent of "Local AI". We need to be pushing for the industry to adopt a local inference architecture asap. It needs to become the standard pattern as early as possible to reduce the risk of the AI revolution being a repeat of the invasive internet search and advertising industry.

I'm really looking forward to this month Local First Web Meetup, Yonz has done a tremendous job organising them. It feels like being part of something new and growing, and to be honest I believe it is.

This is the 1 year anniversary addition, and what a year of talk it's been. Lots of exciting stuff is happing in the world of local-first software this year, and this talk from Martin is the perfect way to kick it off!

If your new to all this, the term "Local-first software" originated from this Ink and Switch paper by Martin Kleppmann https://www.inkandswitch.com/local-first/

I'm so excited about the malleable software / local-first / local-AI crossover, I feel like we are at the dawn of a new era of software. If we play our cards right, we can bring back control of our data from the large corporations, have ownership, and more control of how we work.

I'm particularly interested in how general purpose CRDT toolkits like Automerge and Yjs could become the backing filetype for local-first software with interoperable sync/collaboration backends. The user can then have direct access to the underlaying data via standard tooling. Files can be linked, embedded within each other, forked and merged.

We could have a new hypermedia platform built on this, where all documents are possible to be shared, forked, edited in realtime...

Basically, love what you are all doing at Ink and Switch, excited to see what you publish next.

I think it's a shame the reactivity/signals system from Vue 3 wasn't broken out as a separate project under a different name. They had so much success with building Vite as a separate project, and the reactivity system they built for Vue 3 is so good it warrants the same attention.

It can, and is, used outside of Vue, see Alpine.js, but it's adoption would be so much greater if it was packaged under its own name.

There is this project that even combines it with react: https://github.com/antfu/reactivue.

I wish we had slightly looser compiling between templating and reactivity systems...

Yep, there are multiple ways to interpret it, but that's the problem, particularly with written text. When spoken the word "just" and the tone of the rest of the sentence convey significant meaning that is lost when reading it.

"Simply" and "it's easy" also fall into this trap too. I now try to avoid them when writing technical descriptions. You think something is easy and simple doesn't mean someone else will. When they read that, then struggle, it can put people off continuing to try. That could be a lost sale for you, or it could mean someone deciding that a career choice isn't for them.

"Just" in that context is redundant, you can say "Why don't you use rsync" and the sentence is immediately more positive. The "just" in that sentence adds a level of uncertainty to how people can interpreted it, with one way being a level of condescension.

Oops... I rewrote the start of that sentence, but not the end...

Apple don't release new products until their angle on it is ready to corner the market. They are rarely first, often late, but almost always unique in quality and finish.

When they do launch the car, it's not just going to be a swanky thing to compete with BMW with a bunch of flashy touch UIs and half baked self driving.

It's going to be something that is a step change, something so far ahead of the competition they will be years ahead.

If they have deciding to delay till '28 that suggests it's both not ready, but maybe the market isn't either. If self driving is the head line feature, they will want it to actually be so far ahead of the competition it will appear like magic.

If there is truth to the article (I suspect the delay is real, un-convinced on the reasons suggested) then I don't think the will release one at all.

Hmm, that's wrong. Will look into it, thanks!

There are many projects developing sync tech for local-first, I work on a fully open source one - ElectricSQL - and we are fortunate to have a couple of the CRDT co-inventors on the team. We maintain a list of any local-first sync project we know of here: https://electric-sql.com/docs/reference/alternatives

Sadly, I'm not part of Ink and Switch and did not write that post...

They are an incredible bunch, as are so many people in the local-first / CRDT space, many I have had the opportunity to meet and collaborate with.

There are a lot of exciting sync technologies being develop for this use case, I work on one of them at ElectricSQL (mentioned at the end by the OP), but we maintain a list of alternative here: https://electric-sql.com/docs/reference/alternatives

These ideas are some of the founding principles of "local-first software": https://www.inkandswitch.com/local-first/

As I like to put it - Local-first is the real serverless. Your user's device is the real edge.

I think the future of the web needs to be that the server is optional, we need our data (albeit personal or our companies) to be on our own devices.

We are all carrying around these massively powerful devices in our pockets, let use that capability rather than offload everything to the cloud.

One of the things I find most exciting about local-first (and I'm very fortunate enough to be working on it full time), is the sync tech thats being developed for it. 2024 is I think going to be the year local-first goes mainstream.

I would love to know a little more about your tech stack and architecture?

You say "Everything is saved locally by default", with full office support. Essentially you have built a "local-first" app, or about 10 of them!

I would definitely play on that for marketing, the local-first place is getting quite a bit of buzz. (I'm biased, but I think 2024 if the year local-first is going to go mainstream)

What tech are you using for conflict resolution for offline edits, I'm guessing you have generalised this in some way? Are you using CRDTs? And any particular local-first database tech?

Have you considered adding any real-time multiplayer features? If you've solved the offline edit problems, you are 95% of the way to real-time.

The work that both Roy and yourself have put into SQLite in the browser is awesome, there are so many exciting things coming that are going to be built on top of it. Thank you!