The other cool thing about Drizzle is that it will take multiple queries and handle them as one query to your database rather than multiple. This alone has some real speed benefits.
@@seannewell397 No, Dapper has no way to maintain a schema while both Drizzle and EF Core provides a code first approach. Also, both Drizzle and EF Core allow you to write your queries in either TypeScript or C# (using LINQ). Out of the box Dapper doesn't have this feature. Instead you typically provide the SQL as a string which is why some people prefer Dapper: you have complete control of the SQL used.
Two years ago I started learning software development and struggled to understand what you were talking bout in most of your videos. I'm happy to say now that everything is making sense 😃
Been using Drizzle on my latest project for a few months now, and I think it's absolutely great. Sure there are still a few cases where types can get a bit confusing, but overall it's extremely simple to use, it's basically SQL with type safety. I love it.
@DaLoler1 @@ymahtab Yeah that's what I meant. You wouldn't have much type safety from the TS environment by just sending queries like myDb.query('SELECT * FROM users');, but of course the DBMS itself manages types very well.
@@DaLoler1 because SQL is just raw strings ? I still think it's possible to use a linter but IDK, it seems better when your db feels like just another library with constraints instead of random string bs
the point isn't to avoid writing SQL, it's to introduce types to SQL. If the language is robust enough then you could do some magic like sqlx in Rust, but this is Typescript.
It's not about not writing SQL, it's about ensuring type safety for your queries and the data returned by your queries. Drizzle still has some flaws, like you still can't define views in Typescript files, you still have to do that with raw SQL which isn't so bad, but it's a product gap they've yet to fill (and seems like a mismatch between the dev experience they want to provide). But it has a great developer experience for full stack devs working on Typescript projects. If you know SQL, you don't even really need to "learn" Drizzle. If someone doesn't know SQL, I can see Drizzle as a great gateway into it as it's API very closely resembles the SQL DDL.
@@kiramaticcjust cast your columns in your queries to be exactly the type you expect. Make your columns not null able by default, and rely on the relational model
In my entire career I am yet to see any project of anything above trivial complexity where you can solely rely on ORMs. You HAVE to write raw SQL at some point and boy you better learn how to rawdog it good.
*Hibernate to devs saying one should learn how to rawdog SQL:* am I a joke to you? Seriously though: if you have a database, that requires you to write raw SQL to accomplish something in a performant manner, this means either your database structure or the structure of your entities sucks balls.
Honestly drizzle has been a game changer for our backend. No typical ORM pains since you can still use native SQL inside drizzle. Type safety everywhere. It's awesome.
With fancy colors, intellisense, DBprogramming language type mapping, and compile-time verification. Plus DB scheme generation, migration scripts, etc utils. This is way more than just a “reinvented SQL”. It’s a full toolkit which makes the life of a software engineer much easier.
Started using typeORM tonight and stumbled across your Drizzle video and already I'm thinking of moving from typeORM to Drizzle. I love the native SQL query like syntax
@@theilluminatimember8896 except Entity Framework itself predates TypeORM by at least 13 years, LINQ syntax came out the year prior to that, and the Fluent API for EF came a few years after EF's release.
Everyone's talking about EF, but not about JOOQ for Java. That thing generates types from your actual db tables and allows you to use everything you'd use with sql type-safely. You get out of sync, you get a compile time error. No ORM can ever come close to this.
@@anonAcc575 not my major concern with it atm, I basically want less abstraction between me and SQL, but still some ergonomics. Kysely seems like a great strike at that balance
0:19 ORM doesn't hide SQL's complexity but adds a new level of it in exchange for a reduction of code that is required to map database objects into language-specific ones and vice versa, also you can use your language syntax (depending on ORM) to perform read and write operations from/to the database. But a developer should be well aware of how SQL and ORM work, if one doesn't know first, there will be no way to go beyond simple queries (neither high-performance queries nor complex relationships between tables), if last, the developer will end up "slowly" writing plain SQL. The best way will be to get the benefits of both "worlds", ORM for an average case and SQL for a complex one. ORM is not a replacement for SQL it's just a tool to get most of the stuff done faster, but you still need to have a good understanding of SQL.
The sanest comment so far. People don't know the pain before ORMs where one had to use data adapter and dataset to map query results. And most of them don't have enough traffic or query complexity to feel the pain of ORM issues like n+1 queries or just plain bad generated queries.
It's also beyond me on why someone would use ORM in typescript. The whole purpose of typescript is to cover the burning pile of shit called javascript. At least nowadays javascript is solid(shit), unlike diarrhea from 20 years ago.
@@HellDarkknight The first years of my career were working on applications that directly used JDBC and mapped the result set to objects manually using methods in Java. It's really very easy to do. We didn't have a single bug in the object mapping part of the code, during the entire 4 years, until a senior developer got creative and wrote his own pseudo-ORM using Java's reflection API, and then we had bugs.
@@aheendwhz1hibernate has supported Criteria Queries since 2004, it arrived 20 years late... I understand paid content, and that there wasn't something like this in JS, but... But coincidentally because JS is not typed, why would you want to type the queries? Now it just lacks 20 years of development to offer everything that Hibernate already does, not to mention the integration with Spring, like the auto-generated DAOs and REST controllers.
@@everythingisfine9988 that's not gonna happen anytime soon, we've relied so much on JS that adoption for something else will take a long time. It doesn't help that the people in charge of WASM are stubborn and won't add direct DOM bindings so we can completely do away with JS. Every time you want to update the DOM you're going through JS so you have to build your own wrappers. Not a huge deal, but annoying.
That's the opposite of cool. It means you have to either use wrong grammar (like child => childs) or implement a never-ending list of plural forms, for all languages in the world, where some will still have to use wrong grammar because certain words are not supported or their language is badly supported because there are not so many developers of this language or plural forms are so irregular that you need every single word to be specifically supported in order to generate a plural form. Symfony is trying to do this. After 15 years, they have an English and a French pluralization inflector, and they still receive issues with certain words not being supported. This should teach you that you should never attempt to do natural language pluralisation in code! But does Drizzle do such form of "automatic" pluralisation? I didn't see that one in the video.
@aheendwhz1 I don't think you even watched the video or read the docs, what you wrote is pure nonsense and totally irrelevant. :) And it's `one(horses) ` btw...
Sqlc and go-jet/jet for Go, are in my opinion the best option if you don’t want to deal with raw SQL queries (type safety) and also don’t think ORMs are the best fit (complex schema/large DB with many tables). The best part about these 2 libraries is they work on your existing schema. No need to redefine types they are created using the existing DB. Definitely worth checking out.
@@NawfalHasanuntil you run into runtime exceptions because EF Core couldn't map LINQ to SQL and you didn't get any compiler warnings/errors beforehand. It still requires you to know what you are doing and how SQL actually works. It's still amazing of course
@@EikeSchwass as opposed to typescript and drizzle wouldn't run into? My point is Linq IMO is still the 🐐 query language, regardless of how flaky the implementations like EF are. Linq just flows naturally, using the idioms of the language (mostly). While drizzle requires functions like eq for something as primitive as equality.
@@NawfalHasan Yeah 100% agree. LINQ-2-Entities just gives you a false sense of security (although Roslyn-Analyzers help a lot). To know when, where and how Linq to Sql translation actually occurs is important and it might appear more trivial than it is (simply because LINQ flows so great). You can't just use any IEnumerable-extension-method, although it reads as if you could/should. But I really don't disagree with your point, just that the magic doesn't prevent you from knowing your stuff
@@Malix_Labs I file this under "problems you wouldn't have if you didn't feel the need to use JS/TS everywhere" There are mature backend frameworks with awesome ORMs.
OMG. FINALLY. This is fing masterpiece. I currently use sqlalchemy in python and it uses a similar approach. You have both stupid-like and sql-like code. Finally it's possible to write human-readable code in javascript
Drizzle is definitely my favorite ORM, pretty easy to use once you learn how to declare your schema, and so powerfull by generating one query from the entire statement Still, it may have some issues, like prepared statements having to be explicit, but the most notable I think would be in some parts the documentation.. When I started learning it I found myself spending more time that I should reading it and still not understanding the exact difference between some things (like drizzle-kit push and migration) The prisma-like relations schema seemed a little bit boilerplate and not really well explained either And in the SQL-like approach, the aggregates part (the GROUP BY and HAVING) could have more examples Or at least that was my experience back then, but last time I checked it had already improved I hope it gains more popularity so it keeps polishing those details, since really like the general approach and having things like drizzle studio is so convenient
Just goes to show that TypeORM was right all along. It does everything that was shown here about Drizzle including generating migrations from schema definitions. TypeORM also gives you options on how you want to write queries. If you use entities (schema definition for a table) you can use functions like find(), findOne(), findOneByOrFail(), etc. You can use the query builder to write stuff like select().from(User, 'user').where(xxx).andWhere(xxx).groupBy().orderBy().getMany(). Or if you really want to you can use the query() function which lets you write raw SQL.
Im surprised this wasn't developed earlier. I made this for our proprietary non-relational database software years ago No more runtime "hey your raw string query doesn't work", the methods you call can only be chained in specific ways that the compiler (or at least your linter) knows, and at runtime it spits out that raw string (so no objectification overhead)
It's a prisma without the bad side of prisma. hope it works actually as good as said in the video. Anyway, it deserves to be checked up. can't wait to try it in my next project
Just use raw SQL as it was intended to be used from the start. I've seen so many projects being built with nhibernate, EF Core, etc, etc and all of them gets performance issues and super complex abstractions on top of abstractions as soon as your database gets complex. SQL isn't a hard language to learn, I would argue that alot of ORMs are even harder to learn and just slows down your performance.
I have this really long going project which still uses JQuery and raw MySQL queries. I always get sad when I see those cool new technologies which you present on your channel. Really awesome
One awesome thing about drizzle is the one query guarantee, drizzle never runs more than one query and never transforms the data in js, its pretty neat how they pulled this off, i inspected some queries and they rely on a lot of json functions which is a pretty cool use case for this
I am quite hyped about drizzle and its ease of use. Two days ago I stumbled upon some weird stuff with Prisma ORM for SQL, and TBH It is my first time to use it. But the pitfall I had is that it wasn't exactly an ORM l hoped it to be(used TypeORM till now, but decided to try something new because the development there seems stalled), there is this feeling that you are not actually using SQL and actually learning/using the Prisma API - and if something is rather straightforward, in Prisma it was complex for me. And I know that it was probably a Prisma API knowledge gap, but I don't want to adopt something just because its popular and has XY starts. I want something that is easy to use, with SQL like syntax, with more control when needed, and PERFOMANT. Just now, I completed migration from Prisma to Drizzle, took me about couple of hours to rewrite everything, but it was worth it. Shout to everyone to actually use it in a new project. And big shout out to drizzle team for making a remarkable work! 🎉
Excellent video that convinced me to give neon and drizzle a try for my next project. Currently used to knex to handle the queries but drizzle seems to be a better choice
Does Drizzle have introspection/codegen? I’m a kysely user for the closeness to SQL while having IDE autocomplete and database introspection and codegen was the reason why I picked it. Defining types manually just seemed like too much of a drag even though schema shouldn’t change too much over time.
Check out this video for the full tutorial th-cam.com/video/hIYNOiZXQ7Y/w-d-xo.html
Day 2 without ai video
drizzle deez nuts
Looks pretty good ngl
y
Neon or firebase?
The other cool thing about Drizzle is that it will take multiple queries and handle them as one query to your database rather than multiple. This alone has some real speed benefits.
Who to become a backend developer
@@abhi.r8 Me to become a backend developer
How did you know that?
@@lucassilvas1 how bro are u getting interviews the job market is fucked big time
@@alviahmed7388 because I am jobless now year after being laid off 🤪
This seems like LINQ and entity framework but for typescript, pretty cool imo
That was exactly my 1st thought when I saw the video.
Wtf seriously.
Look at Deepkit ORM
Closer to Dapper right?
@@seannewell397 No, Dapper has no way to maintain a schema while both Drizzle and EF Core provides a code first approach. Also, both Drizzle and EF Core allow you to write your queries in either TypeScript or C# (using LINQ). Out of the box Dapper doesn't have this feature. Instead you typically provide the SQL as a string which is why some people prefer Dapper: you have complete control of the SQL used.
Two years ago I started learning software development and struggled to understand what you were talking bout in most of your videos. I'm happy to say now that everything is making sense 😃
The exact same thing here 😊
You are just at the peak of the bell curve. Soon everything will start being confusing again. 😐
@@arcan762 can’t wait 😂
Been using Drizzle on my latest project for a few months now, and I think it's absolutely great. Sure there are still a few cases where types can get a bit confusing, but overall it's extremely simple to use, it's basically SQL with type safety. I love it.
Wait how does SQL not have type safety?
@@DaLoler1I think they mean it brings the SQL's type safety into the code for you.
@DaLoler1 @@ymahtab Yeah that's what I meant. You wouldn't have much type safety from the TS environment by just sending queries like myDb.query('SELECT * FROM users');, but of course the DBMS itself manages types very well.
@@DaLoler1 because SQL is just raw strings ? I still think it's possible to use a linter but IDK, it seems better when your db feels like just another library with constraints instead of random string bs
Devs will do anything to not have to write SQL. Even create a syntax that closely mirrors SQL.
the point isn't to avoid writing SQL, it's to introduce types to SQL. If the language is robust enough then you could do some magic like sqlx in Rust, but this is Typescript.
It's not about not writing SQL, it's about ensuring type safety for your queries and the data returned by your queries. Drizzle still has some flaws, like you still can't define views in Typescript files, you still have to do that with raw SQL which isn't so bad, but it's a product gap they've yet to fill (and seems like a mismatch between the dev experience they want to provide). But it has a great developer experience for full stack devs working on Typescript projects. If you know SQL, you don't even really need to "learn" Drizzle. If someone doesn't know SQL, I can see Drizzle as a great gateway into it as it's API very closely resembles the SQL DDL.
You arent supposed to write english in source code.
Yeah, that's the point. SQL or CSS aren't safe, you could easily make a mistake and break a lot of things.
So types are needed.
@@kiramaticcjust cast your columns in your queries to be exactly the type you expect. Make your columns not null able by default, and rely on the relational model
Looks cool...
_Goes back to just rawdogging my SQL code._
😂
In my entire career I am yet to see any project of anything above trivial complexity where you can solely rely on ORMs. You HAVE to write raw SQL at some point and boy you better learn how to rawdog it good.
man of culture 👍
LMAO!
*Hibernate to devs saying one should learn how to rawdog SQL:* am I a joke to you?
Seriously though: if you have a database, that requires you to write raw SQL to accomplish something in a performant manner, this means either your database structure or the structure of your entities sucks balls.
Drizzle seems like the ORM we never knew we needed. Can't wait to try it out on my next project!
Crypto bot detected
but she's right
Famous last words
Julia, is the crypto business booming or not?
honestly, looks a lot like EntityFramework
Honestly drizzle has been a game changer for our backend. No typical ORM pains since you can still use native SQL inside drizzle. Type safety everywhere. It's awesome.
When you hate SQL so much that you go full circle to just write raw SQL again but with fancy colors
Well... Yep
This. thank you, it doesnt make any freaking sense. i see this like all the weird crappy javascript frameworks that all think to solve something.
@@atom6_ “Solving problems no one has” seems to be the motto of most tech startups lmao
With fancy colors, intellisense, DBprogramming language type mapping, and compile-time verification. Plus DB scheme generation, migration scripts, etc utils. This is way more than just a “reinvented SQL”. It’s a full toolkit which makes the life of a software engineer much easier.
@@atom6_ it's like y'all want to purposely miss the point. Type safety.
Finally an actual 100 seconds video because there was a freaking 74 seconds ad :) ty fireship
10 seconds only
also sponsor block
There's always TH-cam Premium
Why are you not using an adblocker?
@@somedoobynize joke
Waiting for a Kysely video now, its a nice typesafe query builder and does most of the job when an ORM isnt needed.
thats what I thought, it's very interesting
Started using typeORM tonight and stumbled across your Drizzle video and already I'm thinking of moving from typeORM to Drizzle. I love the native SQL query like syntax
"This has been Entity F.... uh Drizzle in 100 seconds"
Thing is Entity is C#, which no one aside from .net and unity nerds use
More like TypeORM
@@theilluminatimember8896 except Entity Framework itself predates TypeORM by at least 13 years, LINQ syntax came out the year prior to that, and the Fluent API for EF came a few years after EF's release.
@@theilluminatimember8896 not quite...
LINQ released 2007,
EF released 2008
Fluent API for EF released 2013
TypeORM released 2021
@@theilluminatimember8896
2007: LINQ
2008: Entity Framework
2011: Fluent API for EF
2021: TypeORM
Reminds me of the Eloquent ORM for Laravel. Loved using that one since the early days of Laravel.
The absolute first thing I thought of was Laravel as well 😂
I was horrified when he showed how things are done with prizma.
js has lot of catching up to do wrt to laravel
Is Eloquent typed? I thought it just uses unchecked strings for property and even class names, just like Doctrine or any other ORM.
@@aheendwhz1 it has explicit casting
Third video without mentioning AI. You can do it Jeff!
Please stop being like this
AI is our present, past and future
AI writes my EF code for me when I ask nicely.
Drizzle seems like a banger!
Everyone's talking about EF, but not about JOOQ for Java. That thing generates types from your actual db tables and allows you to use everything you'd use with sql type-safely. You get out of sync, you get a compile time error. No ORM can ever come close to this.
man i love how fast youve been releasing new videos lately
@btw_i_use_arch the future is so bright
Would love a video comparing Drizzle and Kysely
+1
Kysely ftw
kysely is great, don't know why everyone fawns over drizzle
I think it fills the typesafety promise better.
@@anonAcc575 not my major concern with it atm, I basically want less abstraction between me and SQL, but still some ergonomics. Kysely seems like a great strike at that balance
0:19 ORM doesn't hide SQL's complexity but adds a new level of it in exchange for a reduction of code that is required to map database objects into language-specific ones and vice versa, also you can use your language syntax (depending on ORM) to perform read and write operations from/to the database. But a developer should be well aware of how SQL and ORM work, if one doesn't know first, there will be no way to go beyond simple queries (neither high-performance queries nor complex relationships between tables), if last, the developer will end up "slowly" writing plain SQL. The best way will be to get the benefits of both "worlds", ORM for an average case and SQL for a complex one.
ORM is not a replacement for SQL it's just a tool to get most of the stuff done faster, but you still need to have a good understanding of SQL.
The sanest comment so far. People don't know the pain before ORMs where one had to use data adapter and dataset to map query results. And most of them don't have enough traffic or query complexity to feel the pain of ORM issues like n+1 queries or just plain bad generated queries.
It's also beyond me on why someone would use ORM in typescript. The whole purpose of typescript is to cover the burning pile of shit called javascript. At least nowadays javascript is solid(shit), unlike diarrhea from 20 years ago.
@@HellDarkknight The first years of my career were working on applications that directly used JDBC and mapped the result set to objects manually using methods in Java. It's really very easy to do. We didn't have a single bug in the object mapping part of the code, during the entire 4 years, until a senior developer got creative and wrote his own pseudo-ORM using Java's reflection API, and then we had bugs.
Revolutionary! If we ignore all other ORMs.
How many ORMs actually support a type system to check for the correct property names and types?
@@aheendwhz1hibernate has supported Criteria Queries since 2004, it arrived 20 years late... I understand paid content, and that there wasn't something like this in JS, but... But coincidentally because JS is not typed, why would you want to type the queries? Now it just lacks 20 years of development to offer everything that Hibernate already does, not to mention the integration with Spring, like the auto-generated DAOs and REST controllers.
@@aheendwhz1 prisma
Kysely is the best and the only ORM needed for any TS project
it is not an ORM but is great
Zero days without the nodejs community reinventing the wheel
Na, more like conquering the backend services. Still waiting on BE languages to gain "significant" market share in the front end.
@@everythingisfine9988 that's not gonna happen anytime soon, we've relied so much on JS that adoption for something else will take a long time.
It doesn't help that the people in charge of WASM are stubborn and won't add direct DOM bindings so we can completely do away with JS. Every time you want to update the DOM you're going through JS so you have to build your own wrappers. Not a huge deal, but annoying.
This was just what I was looking for yesterday, couldn't decide between Prisma and Sequelize before this, thanks!
one(horse)
many(horses)
Me: fuck, that's genius.
fuck, that's cool.
That's the opposite of cool. It means you have to either use wrong grammar (like child => childs) or implement a never-ending list of plural forms, for all languages in the world, where some will still have to use wrong grammar because certain words are not supported or their language is badly supported because there are not so many developers of this language or plural forms are so irregular that you need every single word to be specifically supported in order to generate a plural form.
Symfony is trying to do this. After 15 years, they have an English and a French pluralization inflector, and they still receive issues with certain words not being supported. This should teach you that you should never attempt to do natural language pluralisation in code!
But does Drizzle do such form of "automatic" pluralisation? I didn't see that one in the video.
@@aheendwhz1buzzkill
@aheendwhz1 I don't think you even watched the video or read the docs, what you wrote is pure nonsense and totally irrelevant. :)
And it's `one(horses) ` btw...
Once again, eloquent orm, thanks.
I'm a fan of query builder Kysely. It's fantastic combo together with prisma for schema and migrations or with atlas.
Kysely es better than Drizzle by far. But it seems that the syntax don't like it to a lot of devs.
Found this just in time to start writing my postgreSQL queries. Ty!
Drizzle seems amazing. Going to use it on my next personal project.
be prepared to use that “magic sql” feature. The project is so unfinished and not production ready you end up having to write raw SQL half the time.
Good video as always. Would you please do Mikro-ORM next?
Sqlc and go-jet/jet for Go, are in my opinion the best option if you don’t want to deal with raw SQL queries (type safety) and also don’t think ORMs are the best fit (complex schema/large DB with many tables). The best part about these 2 libraries is they work on your existing schema. No need to redefine types they are created using the existing DB. Definitely worth checking out.
Entity framework core: finally a worthy opponent.
Nowhere as ergonomic as Linq still. Linq is goat query language in terms of typesafe-ness and intuitiveness.
@@NawfalHasanuntil you run into runtime exceptions because EF Core couldn't map LINQ to SQL and you didn't get any compiler warnings/errors beforehand.
It still requires you to know what you are doing and how SQL actually works. It's still amazing of course
@@EikeSchwass as opposed to typescript and drizzle wouldn't run into? My point is Linq IMO is still the 🐐 query language, regardless of how flaky the implementations like EF are. Linq just flows naturally, using the idioms of the language (mostly). While drizzle requires functions like eq for something as primitive as equality.
@@NawfalHasan Yeah 100% agree. LINQ-2-Entities just gives you a false sense of security (although Roslyn-Analyzers help a lot). To know when, where and how Linq to Sql translation actually occurs is important and it might appear more trivial than it is (simply because LINQ flows so great). You can't just use any IEnumerable-extension-method, although it reads as if you could/should.
But I really don't disagree with your point, just that the magic doesn't prevent you from knowing your stuff
@@EikeSchwass agree.
Neon is great. Super easy to get going and it works great with vercel. The ability to do everything serverless is also a godsend.
Huh, EntityFramework
Yeah plus entity framewokr is mature and much better
The difference is that this is for TypeScript
Show us how the fuck can you use EntityFramework in JavaScript
@@Malix_Labs I file this under "problems you wouldn't have if you didn't feel the need to use JS/TS everywhere"
There are mature backend frameworks with awesome ORMs.
Sorry bro, I've used both and Drizzle is far better
I have this in production, it is amazing!!!
OMG. FINALLY. This is fing masterpiece. I currently use sqlalchemy in python and it uses a similar approach. You have both stupid-like and sql-like code. Finally it's possible to write human-readable code in javascript
okay this is one of the few videos I need to rewatch when I can sit to do some work. Nice!
You learn new things every day. Insane
So far drizzle has been amazing to use. I love being able to auto generate my types from an existing database
Fireship is back with good old classics! And now I want Ai content again
Don't worry about it, he is AI
I just started looking into drizzle yesterday. What perfect timing
Seeing non-ai frequent videos gives me hope to go on
Drizzle is definitely my favorite ORM, pretty easy to use once you learn how to declare your schema, and so powerfull by generating one query from the entire statement
Still, it may have some issues, like prepared statements having to be explicit, but the most notable I think would be in some parts the documentation..
When I started learning it I found myself spending more time that I should reading it and still not understanding the exact difference between some things (like drizzle-kit push and migration)
The prisma-like relations schema seemed a little bit boilerplate and not really well explained either
And in the SQL-like approach, the aggregates part (the GROUP BY and HAVING) could have more examples
Or at least that was my experience back then, but last time I checked it had already improved
I hope it gains more popularity so it keeps polishing those details, since really like the general approach and having things like drizzle studio is so convenient
neon is great indeed, I used it with laravel
On the other note... Love Neon!
cool looking ORM , I will try this in my next Nodejs projects
I'd love to see a video about Odoo
Hey, can you please make a video about this new offline-first app trend?
DRIZZLE MENTIONED LETS GO
Idk shit about coding, yet I still watch your videos
0:15 I liked the Cassandra reference right there!
very excited that there's yet another option in the sea of options
Fireship be spoiling us with content this week 😊
I love these videos, even if I cannot understand a single word this man is saying.
Should be noted that the migration and studio are not open source. They both might be a service in the long run...
I looked for the free tier db to mess around, Neon looks like this
Just goes to show that TypeORM was right all along. It does everything that was shown here about Drizzle including generating migrations from schema definitions. TypeORM also gives you options on how you want to write queries. If you use entities (schema definition for a table) you can use functions like find(), findOne(), findOneByOrFail(), etc. You can use the query builder to write stuff like select().from(User, 'user').where(xxx).andWhere(xxx).groupBy().orderBy().getMany(). Or if you really want to you can use the query() function which lets you write raw SQL.
Im surprised this wasn't developed earlier. I made this for our proprietary non-relational database software years ago
No more runtime "hey your raw string query doesn't work", the methods you call can only be chained in specific ways that the compiler (or at least your linter) knows, and at runtime it spits out that raw string (so no objectification overhead)
It's a prisma without the bad side of prisma. hope it works actually as good as said in the video. Anyway, it deserves to be checked up. can't wait to try it in my next project
That looks seriously dope
Cool, they ported LINQ and Entity Framework to TypeScript! 👏🏻👏🏻
Looks more like a query builder
Just use raw SQL as it was intended to be used from the start. I've seen so many projects being built with nhibernate, EF Core, etc, etc and all of them gets performance issues and super complex abstractions on top of abstractions as soon as your database gets complex.
SQL isn't a hard language to learn, I would argue that alot of ORMs are even harder to learn and just slows down your performance.
Ecto (Elixir): "Look What They Need To Mimic A Fraction Of Our Power"
I just tried drizzle, And this is amazing!
Oh God, what great editing, I lol'ed when he showed the candle under the shower.
I have this really long going project which still uses JQuery and raw MySQL queries. I always get sad when I see those cool new technologies which you present on your channel. Really awesome
One awesome thing about drizzle is the one query guarantee, drizzle never runs more than one query and never transforms the data in js, its pretty neat how they pulled this off, i inspected some queries and they rely on a lot of json functions which is a pretty cool use case for this
I'm planning to use Neon for my next project. Seems promising, thanks.
There is some haunting sound in the background at 2:26 which sent shivers down my spine :O
You good Jeff?
I mean this has been done in SQLAlchemy for years, and you get a ORM too! Cool to see it comes to JS/TS too.
finally a 100 sec video in 156 seconds
😆
I swear today I saw this tool in a random docs and said wtf is that and you just dropped this
This guy literally explained what an ORM is in 30 seconds way better than any other shitty 1 hour long video about them.
I am quite hyped about drizzle and its ease of use. Two days ago I stumbled upon some weird stuff with Prisma ORM for SQL, and TBH It is my first time to use it. But the pitfall I had is that it wasn't exactly an ORM l hoped it to be(used TypeORM till now, but decided to try something new because the development there seems stalled), there is this feeling that you are not actually using SQL and actually learning/using the Prisma API - and if something is rather straightforward, in Prisma it was complex for me. And I know that it was probably a Prisma API knowledge gap, but I don't want to adopt something just because its popular and has XY starts. I want something that is easy to use, with SQL like syntax, with more control when needed, and PERFOMANT.
Just now, I completed migration from Prisma to Drizzle, took me about couple of hours to rewrite everything, but it was worth it. Shout to everyone to actually use it in a new project.
And big shout out to drizzle team for making a remarkable work! 🎉
oh my god this is exactly what i needed
The bast part is the "Developers love Drizzle ORM!" section in their website where some people are shitting on it in the comments.
first ever readable database framework
Loving Drizzle, really nice Prisma alt
There should be a C++ version of this library 😉
This has serious potential!
This is literally what I've been doing manually for Perl for years
Chose Drizzle for my latest project - it's brilliant.
R in 100 seconds! R’s dplyr package is the OG Drizzle-style ORM
Reminds me of ReQL, this is fantastic
Don't forget about Kysely as well ;)
Thank for sharing! I'll try this!
EF also has a version that closely matches sql, but had the presence of mind to fix the order of clauses to put the select last
Drizzle is awesome! It hits the perfect balance between orm and raw sql.
Bro, you are now a superhero. A video per day?
Excellent video that convinced me to give neon and drizzle a try for my next project. Currently used to knex to handle the queries but drizzle seems to be a better choice
wow that was easy, i think i'm gonna give it a try
Interesting. But for the moment I am sticking with MikroORM, which I really recommend as an substitute for TypeORM.
I laughed so hard on the life threatening part and I don’t know why
Drizzle website has your video placed at top
Awesome tool, thanks for the recommendation!
100 Seconds of Hono 🔥 next!
Does Drizzle have introspection/codegen? I’m a kysely user for the closeness to SQL while having IDE autocomplete and database introspection and codegen was the reason why I picked it. Defining types manually just seemed like too much of a drag even though schema shouldn’t change too much over time.
the earliest ive been to any video ever
existence of this framework it's like natural selection, but with extra steps