snowoutside

It's very interesting they are using camelCase for their Postgres column names instead of snake_case. I like it.

Is that something folks are doing? Can it be done without "doubleQuoting" all of the response column names or without using an ORM?

Just switched to Bitwarden. Took me ~15 minutes to get the browser extension + app installed and to complete the migration using the export/import features.

This is really sad :( I hope there is more communication soon about the timeline.

Interesting font. The presentation of this page looks pretty bad on a window that is ~1000px wide. Not sure why it was designed in a way that forced a single ratio.

Thanks for your response Nikolas!

Prisma's approach is well thought out, and I appreciate the new angle on an old and challenging problem. For Typescript users, especially new users, Prisma can be a big win. Abstracting SQL has huge benefits here (especially type safety/static analysis), and I look forward to seeing where this project goes.

That being said, my favorite database is PostgreSQL because it has so many features (and I'm just comfortable with it). At some point, a tool like Prisma (or Knex, TypeORM, etc) just cannot support all PostgreSQL features because it needs to support other flavors too. While some users may find this trade off acceptable, I always find myself hacking around the tool to use the raw features. Therefore, my ideal environment would be a full-featured PostgreSQL query builder.

TL;DR I see the benefits of Prisma, but they're not for me at this point

I empathize with the frustration that this library is trying to solve. It's pretty nifty too! Ultimately, however, I don't believe this is the correct approach.

The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that are already accustomed to working with SQL will need to relearn PrismaSQL.

I think the best approach to this problem is a single-SQL-flavor query builder that attempts to match SQL as closely as possibly while adding in the niceties of being able to pass in JavaScript objects instead of raw SQL strings. Lets be honest: raw SQL-in-JS is no fun.

This would lead to PostgreSQL, MYSQL, SQLite, etc-specific query builders. Knex is close, but it ultimately doesn't work for most because it's missing some language-specific features (e.g. ON CONFLICT DO UPDATE). While this doesn't exactly meet the type safety benefits of Prisma, the benefits in ease of use and feature-parity of a language-specific query builder far outweigh the difficulties of learning a new query language like Prisma.

I think 10:1 is a bit much. If services are well-scoped, 3 engineers/service can be an effective ratio.

I recently started using Sapper for a personal site and have been enjoying it immensely. I find that the abstractions that Sapper/Svelte make in order to avoid full page loads, preload data, etc allow me to write the site in a component-oriented way while not shipping 5MB of JS to the browser. And, Sapper scales as the app gets bigger in a way that a raw static site just can't.

Rich seems to be advocating for a JS middle-ground here, which I think is a great direction to go in for this kind of workflow.

This is sweet! Interestingly it seems to only accept QWERTY input even when the keyboard has an alternate mapping set. This makes sense though given the positions of the keys chosen

This is not specific to Chrome.

`document.designMode` is a web standard and is supported by Firefox, Safari, IE, etc.

https://developer.mozilla.org/en-US/docs/Web/API/Document/de...

With brew as the de-facto package manager for macOS this is a great move. Having Python and Ruby bundled with macOS is confusing when trying to install "regular" versions of the software through brew or other methods. Because the default installation can't updated without updating the OS, the system versions are not useful for most developers.