Unironically this: isn't writing on paper more fun than typing? Isn't painting with real paint and canvas more satisfying than with a stylus and an iPad? Isn't it more fun to make a home-cooked meal for your family than ordering out? Who stomps into the holiday celebration and tells mom that it'd be a lot more efficient to just get catering?
Isn't there something good about being embodied and understanding a medium of expression rather than attempting to translate ideas directly into results as quickly as possible?
Yes, exactly: I'm not saying everyone loves to paint or cook or whatever, but that a lot of people do, and it's weird and bad for the response to this kind of article, in which someone shares that they are losing something they enjoyed, to be some form of "well, not everyone enjoys that."
To some people this is a gain, to some people this is a loss. Objectively it is changing things, and I can agree on having empathy for those who it changes something for negatively.
I feel like we are in a period of low empathy, understanding and caring for others as an aside from just this piece.
If you get your enjoyment from the process of cooking, by all means cook. But if you enjoy being with people and just eating food, catering is better.
Is your goal to efficiently get your thoughts to a medium as fast as possible, use a stylus or a keyboard. Do you enjoy the process of writing your thoughts down, use a fountain pen.
Or the easiest comparison: coffee. Do you want your fix of caffeine as fast as possible? Grab some gas station slop on the go for .99€. But if you're more about relaxing and slowly enjoying the process of selecting the optimal beans for this particular day, grinding them to perfection and brewing them just right with a pour-over technique or a fancy Italian espresso machine you refurbished yourself - then do that.
Same with code. I want to solve a problem I have or a client has. I get enjoyment from solving the problem. Having to tell the computer how to do that with a programming language is just a boring intermediate step on the way.
Ahhhhh. Thanks man. And totally nerding out here because YES. ANIMATIONS. Animations is why I fell in love with wanting to learn D3 in 2019. You can do things as you transition between data steps, that honestly, has been such a pain in the behind to try with anything else. I'm not a web developer. I'm a data guy.
Speaking of animations, I used D3 to build my first web video game, a little match-3 game: https://fwip.github.io/colormatch/
The whole game board is a single SVG.
It clearly has some bugs (like the score sometimes being NaN - no idea how I messed that up), but I haven't touched the code in over a decade, so it's a little time capsule.
I did consulting for the first 8 months of development, and then the company roughly broke even for operational costs since day one. I built most things myself which led to lower costs. My main cost was just rent and health insurance, which in America, self-employed, is both expensive and useless. I had savings from working for a decade in tech and minimized other costs. So, lucky position to be in, but also your average startup's monthly burn is enormous compared to what you can do by being scrappy.
That's a fair assumption. There were some customers who benefited from real-time editing, but it was a big tech bet and led to a design that was harder to scale for larger datasets.
You don’t need to apply the license until after the public release, before then it would just be sharing code with your customers under whatever agreement you want
Placemark was built around that idea - all the data is easily exportable & importable in many open formats. It should be straightforward to move to the open source version or other tools.
[op]: Render is a web host, on which we host other applications. They offer a managed Postgres version, which is in my experience pretty similar to Heroku, RDS, or other managed databases.
Maybe the sentence makes that confusing - we're using other stuff on Render, which are basically "web servers" in the Heroku-ish sense, and we're also using their managed database, which is just a database. And it's nice that Render, like some other managed hosting providers, lets you boot up and connect those services.
I guess it's more than a database in some sense because it networks to our web servers and can be booted up in a preview environment, but it is mostly just a database. There are cheaper options that would be more work to wire up in such a convenient way, but the pricing difference between a database on AWS and one on Render is not the highest priority right now.
Thanks, that does clear it up. I was missing the context about Render's full offering. Makes sense re the current priority; I can see many situations or phases of a company where using Render could make a lot of sense even if there are cheaper way to get a PG database.
We switched to Clerk.dev. Thankfully we had only supported magic link auth, so there wasn't much information to migrate over. Clerk has been pretty good - they have a great Remix integration and solid admin experience.
Sure! I think Kysely is great too, but went with Drizzle for a few different reasons:
Kysely is a little more established than Drizzle, which I think is one of the major reason why it has broader adoption. My bet is that Drizzle is moving really fast, gaining adoption, and might catch up at some point. It's also - in terms of performance - super fast, and nicely layers on top of fast database clients.
Some of the differences that I liked about Drizzle were the extra database drivers being core and developed as part of the main project. It supports prepared statements, which is awesome. The Drizzle API also covers an impressive percentage of what you can do in raw SQL, and when there's something missing, like a special column type, it's been pretty straightforward to add.
I prefer the way that it lets us write parts of queries, and compose them - like you import expressions like "and" and "eq" and you can write and(eq(users.id, 'x'), eq(users.name, 'Tom')) and you can actually stringify that to the SQL it generates. Or you can do a custom bit of SQL and use the names of table columns in that, like `COUNT(${users.name})`. I can't say scientifically that this is superior, and it's almost a little weird, but I've really found it a nice way to compose and debug queries.
That said, Kysely is also a great project and it'd be possible to build great products with it, too. I just found the momentum, API, and philosophy of Drizzle to be pretty compelling.
> It's also - in terms of performance - super fast
Kysely is also super fast. Your bottleneck will always be database requests. If you're chasing every milli, why node.js?
> the extra database drivers being core and developed as part of the main project.
Kysely's dialects are dead simple to implement on your own. As evident by all the 3rd party dialects being open-sourced and all the comments from people using Kysely in production with stuff like cockroachdb, mariadb, clickhouse and such.
Its unhealthy to maintain niche database knowledge in the core. We just don't have the time (FYI we do this for fun, not trying to catch all the sponsors and get VC funded) to play around with all of these technologies, and stay up-to-date with changes.
Both Sami and I have submitted pull requests in 3rd party dialect repositories in the past. I maintain a few dialects on my own.
> It supports prepared statements, which is awesome.
In connection pooling scenarios Kysely was mainly built for, prepared statements are arguably "not that great". In FaaS, a burst of requests might make your database work extra hard, as each new lambda instance comes with brand new connection/s.
> I prefer the way that it lets us write parts of queries, and compose them - like you import expressions like "and" and "eq" and you can write and(eq(users.id, 'x'), eq(users.name, 'Tom')) and you can actually stringify that to the SQL it generates. Or you can do a custom bit of SQL and use the names of table columns in that, like `COUNT(${users.name})`. I can't say scientifically that this is superior, and it's almost a little weird, but I've really found it a nice way to compose and debug queries.
This has been part of Kysely for a while now, and is only getting stronger with new `ExpressionBuilder` capabilities. The fun part is, you don't have to import anything, and are not coupled to your migration code.
Personally I like both projects, as I hope I made clear in the OP - I sense that there's some history and strife here that I'm not clued into as an outsider.
My personal problem with Kysely is that the migrations are not aligned with what I needed personally.
I would have wanted to see Kysely have the ability to generate migrations for example. I also personally prefer the approach that Drizzle takes when it comes to more adoption (in my case, CockroachDB).
Just a personal preference - the project is awesome.
Drizzle-kit, the migration part of drizzle is not open source, though they said they will open source it in future, but not at this point. Kysley is 100% open source, feature rich and more stable, again back to active development.
atlasgo io looks promising to handle migrations and is open source as well. I am currently using prisma.
Isn't there something good about being embodied and understanding a medium of expression rather than attempting to translate ideas directly into results as quickly as possible?