zaksingh

Miniswap | Founding Engineer | Full-time | ONSITE (hybrid) San Francisco | No visa sponsorships

Miniswap is a marketplace for complex hobbies, starting with Warhammer. We're backed by Y Combinator and have just closed our seed funding round. In the past six weeks since we launched, users have listed $150,000 of tabletop wargaming miniatures for sale on Miniswap and over $15,000 have been sold.

We're looking for a founding full-stack engineer who is passionate about their hobbies -- whether it be Warhammer, Magic: The Gathering, mechanical keyboards, fountain pens, you name it.

We have an opinionated tech stack: deep use of PostgreSQL (composite types, functions, etc), Rust for our monolith, and HTMX with modern vanilla JS/CSS. Our mentality is to extract the utmost value we can get out of these technologies before introducing additional infrastructure and frameworks. No ORMs, npm, React, etc. If this prospect excites you, please reach out :)

Previous professional Rust experience is not a strict requirement for the role.

Compensation: $100-180k + 0.5%-2% equity

Contact: [email protected]

Congrats on the launch! I think this has a lot of potential in eliminating context-switching. DevTools has always felt unintuitive/unfamiliar coming from an IDE, so just bringing the IDE UX and vim keybindings over is already a big improvement. It also makes LLM prompting feel better contextualized.

As an aside, thinking back to learning React seven or eight years ago by watching a bunch of tutorial videos where they'd switch between IDE and browser views or awkward split screens, this seems like a way better format for explainers/walkthroughs of frontend code.

On the efficiency angle, I think a big difficulty here that isn’t often discussed is that many optimization strategies relevant to incremental compilation slow down batch compilation, and vice versa.

For example, arena allocation strategies (i.e internment of identifiers and strings, as well as for allocating AST nodes, etc) is a very effective optimization in batch compilers, as the arenas can live until the end of execution and therefore don’t need “hands on” memory management.

However, this doesn’t work in an incremental environment, as you would quickly fill up the arenas with intermediary data and never be deleting anything from them. This is one reason rust-analyzer reimplements such a vast amount of the rust compiler, which makes heavy use of arenas throughout.

As essentially every programming language developer writes their batch compiler first without worrying about incremental compilation, they can wind up stuck in a situation where there’s simply no way to reuse their existing compiler code for an IDE efficiently. This effect tends to scale with how clever/well-optimized the batch compiler implementation is.

I think the future definitely lies in compilers written to be “incremental first,” but this requires a major shift in mindset, as well as accepting significantly worse performance for batch compilation. It also further complicates the already very complicated task of writing compilers, especially for first-time language designers.

I'm inclined to agree, especially as there are free alternatives for all major web browsers (although I can see that isn't the full feature set, I imagine its 90% of the use case for most people). $25 feels like the max I'd consider for this type of thing.

A big challenge with the React ecosystem is that it's the first technology many new developers work with. They don't have a frame of reference for what alternative approaches exist, and therefore 'best practices' are taken on faith and followed blindly until their nuances can be learned through experience.

That's not a bad thing (and it's better than the alternative of not caring for design patterns whatsoever). It's part of the learning process, and since there are so many beginner developers who are using React, their perspective is much 'louder' than in other dev ecosystems.

You can see this in the absurd amount of introductory-level React content posted to Medium, DevTo, Twitter, etc. This has bred a very strong 'follow-the-leader' culture where, when the one person is the room who _does_ know what they're talking about makes a statement, others will repeat it verbatim without understanding its nuances due to a lack of experience/context.

Redux suffered heavily from this. New React devs in 2017 were faced with mountains of tutorials which all used Redux. Many of these tutorials were written by other newbies. Your mental model of React dev was then shaped around Redux. Therefore you would put everything you could into the Redux store, which is a bad idea -- you usually don't need form state in there, for example.

Then some React thought-leaders saw this problem and inadvertently created a counter-movement by raising how Redux was overkill for some use cases, which was misconstrued as 'you shouldn't use redux _at all_'. The pendulum has been swinging back and forth ever since.

Yes, not every application needs separation of concerns. But some definitely do. It's not black and white, and that unfortunately means there's no definable 'best practice' that can be tweeted or blogged about and followed blindly -- it just has to be learned from experience.

Asking for email after sign-in with Apple is against their TOS. At some point when you release an update they'll notice and require you to change this. (It happened to me ~6mo after we launched!)

So from what I can tell this is conceptually similar to the LiveView model, except that the problem is approached from the perspective of the SPA/client stack instead of the SSR stack. It’s a refreshing idea that I’ve never seen executed like this before.

However I think it’s missing the point of de-coupling. Security would be very hard to reason about, as would handling of intermittent network connections when the real structure of the client and server are abstracted away from you.

Ultimately I think GraphQL with live queries is the best model for this type of reactive work. You get a decoupled client/server, reactivity, support for mobile clients as you have an API, as well as full type-safety on the client.

Nonetheless I applaud the creativity on display here and I hope I’m proven wrong. Maybe this will be the next paradigm shift? Who knows

I've rarely seen alert() used in the past few years outside of as a means of harassing users on malware sites (have you ever accidentally clicked on a malicious ad on a mobile phone and struggled to escape the site due to alert() spam blocking interaction? It's terrifying as an end-user). This seems like a more than reasonable decision given an adequate phase-out period.

This book was one of the best parts of my CS degree. It's the only textbook which I read cover-to-cover because the writing and narrative were so cohesive. Highly recommend.

The biggest challenge I see with federated systems is the discovery process for finding a node you want to be associated with. This is a hard choice - will this server still be running in 6 months? How is it funded? Is it being actively maintained?

These questions are too much for laypeople, and I can't imagine a scenario in which your friendly local system admin is your service provider for a critical service in your life like Facebook. Could you imagine email working that way?

I see federated systems naturally ending in centralization in the form of a couple big megacorps that the average person trusts to not shut down tomorrow. Convenience and ease of use will win out. It happened with email, it arguably happened with xmpp back in the day. Change my view?