Never use an ORM unless it's *my* ORM

You lost me at "never". No reason to start what should've been an open-minded discussion with a dogmatic statement. I prefer a pragmatic approach to building large systems and leave out "never" from the discussion.

@PaulGaida69

Жыл бұрын

I think nowadays it is an easy way to call for attention in this pseudo controversial approach.

@DevinRhode2

Жыл бұрын

Why’d you click the video lol

@mishasawangwan6652

Жыл бұрын

you lost

@heroe1486

Жыл бұрын

The reason you clicked and why they do that

@robertfletcher8964

4 ай бұрын

thats quite a short sighted dogmatic statement ;)

For projects where the biggest concern is not squeezing every ounce of performance out of every thing you do. ORM for me offers more pros than cons. And you can still write raw parameterised queries for more complex queries.

@8forty

Жыл бұрын

Umm, nice strawman argument I guess? Did you even watch the video?

@johnwales77

Жыл бұрын

@@8forty I did finish watching the video after my comment. I did like some of his arguments, and could relate to them.

@dyto2287

Жыл бұрын

It's still a useless abstraction. SQL is the language meant to be used for interacting with data. No need to pick libraries and it stays the same in all backend programming languages you use. No need to learn a different library if you start coding in different language. If you use ORM means you don't know SQL and never will learn it because ORM will hide it from you.

@zzzyyyxxx

Жыл бұрын

@@dyto2287 I don't want to learn SQL though, I want to get shit done. If I can use an ORM why wouldn't I?

@SEOTADEO

Жыл бұрын

@@dyto2287 That's bullshit. You can write arbitrary unchecked SQL that can lead to all sorts of bugs. With ORMs in statically typed languages that are synced with the database schema you can at least guarantee that all calls to the db are valid and your program won't even compile if you do something stupid. Can you do that with pure SQL? No.

I kept trying to understand what he's talking about, I kept loosing his point every 30 seconds.

2min in, why orm is bad: - you are not able to handle 2000 models - there is no place to put the business logic but controller or model - orm code results in spaghetti code - always complete unrealistic and false assumptions

@youtubeenjoyer1743

3 ай бұрын

Show me a single example of a non-trivial application where the third point is not true. Protip: you can't. The first and second points are completely arbitrary.

@FooCo2009

3 ай бұрын

@@youtubeenjoyer1743 its not on me to disproof the assumption. you need to show why the statement is valid not only based on your own code quality.

The argument against MVC is very fuzzy, people keep misunderstanding MVC all the time, the latter is a delivery mechanism, the "M" in MVC is not a domain model, nor a persistence model, is a presentational/transport layer model, so it has nothing to do with the database. Also what does it mean to have only 3 places to write the code, and the 2000 models argument? In a clean architecture, that promotes separation of concerns, the MVC pattern would be something applied at the infrastructure layer, the business logic would go in the domain which, obviously, is unaware of delivery and persistence mechanisms. The argument around a huge explosion of models is also a bit unrealistic, let's assume we have a traditional CRUD set of operations per resource we would have: C using 2 models (request and response payloads), R using 1 model (response payload), U using 2 models (request and response payloads) and D using no model, so saying we will soon have 2000 models will translate into managing around 200 resources, something that IMHO does not fit well in a single application, is now a huge monolith with 200 reasons to keep changing.

@chauchau0825

Жыл бұрын

agree..very few people actually understand MVC only exists in presentation layer

2000 models is 2000 tables in a database. Let's do it without ORM and define 2000*x functions for managin those tables where x is all necessary operations like add row, read, update etc. If you have 2000 models in your project it is not an ORM's problem. It's a problem of a dev who can not build a good architecture for his project. Also... building backend in js? I would question this part of a video rather then any ORM related issues. This video is some kind of an out-of-season april fools joke I guess.

@macctosh

Жыл бұрын

I can see 2000 models. especially if most of them are linking tables. for example in My project I have 10 tables and almost 90 linking tables. I chose spring boot for this and very happy with the results!

@aryabp

Жыл бұрын

yea we can build backend in js using node js with express lib and pg lib (postgre)

@heroe1486

Жыл бұрын

@@aryabp That's what he questions, talking about JS is just easier than naming the runtime (node deno bun etc) and groups them all

@sampri22

2 ай бұрын

@@macctosh can you give an example why so many linking tables? Thx

@macctosh

2 ай бұрын

@@sampri22 The project I am working on isn't typical because the project requirement states that each entity need to have a direct many to many relation to each other in both directions threfore 10*10 subtract self references and you have got 90 linking tables. We would never have attempted this project without an ORM. It would be impossible to maintain! The real world is nuts!

Won't use an ORM but writes backend code in JS. Close video. ;)

@esra_erimez

Жыл бұрын

*THIS*

@neunistivlija

Жыл бұрын

Bravo, exactly my thoughts. Amateur

@witchedwiz

Жыл бұрын

Cannot argue with the inconsistency portrayed ahah

@jesusantoniomartinezhernan2791

Жыл бұрын

He think that backend process is only CRUD operations through all entitites

@jacobshore

Жыл бұрын

😂😂😂

I would never use javascript for backend.

@macctosh

Жыл бұрын

How about NextJS? I prefer react (frontend) and spring boot (backend) but NextJs features and extreme flexibility are very tempting!

@handsanitizer2457

Жыл бұрын

@@macctosh no *hits head with newspaper

@heroe1486

Жыл бұрын

@@macctosh NextJS "backend" = bare express + limitations of serverless if you deploy to Vercel, it's nothing comparable to a framework like Spring

You would never use an ORM... in JavaScript? Why are you using JavaScript for backend anyway?

@masadamsahid

Жыл бұрын

May be because he found the Fastify framework? Idk

This guy is definitely a genius, the way in which he proves that ORM is bad is horrible. Like I haven't seen so many bad arguments in the same place. Not only is he USING an ORM he wrote a code generation framework in which based on the table structure it generates CRUD for each db, which is a bit bad to expose everything and not having the possibility to alter the code inside. The JS community still has decades to catch up to mature ecosystems like C# , Java, Python, PHP. Side note: we also avoid ORMs when we need to make sure performance is the most important factor, which rarely is but that's another discussion.

@fabionunes2793

Жыл бұрын

Good point. I used a lot if orm for commercial solutions that are not intended to be super fast, but they have pretty complex business rules. So, orm is a great deal, because basically you are going to only implement what really matters.

@gonkong5638

Жыл бұрын

Yeah I really hate ORM. Especially hibernate. But i don't see any alternative way for my job.

@thisisnotok2100

Жыл бұрын

@@gonkong5638 well, I guess it would be queries lol

@Lexaire

3 ай бұрын

Some companies have over 2000 models! That's crazy! We need a solution! Here's my codegen framework that still ends up with 2000 models.......... Also you don't need codegen if you use your models to create your migrations. He's just shifted the work from models to raw SQL migrations whereas ORM users write the models instead of the raw SQL migrations. He hasn't gained anything.

Laravel's ORM is pretty sick though

@yungifez

Жыл бұрын

Thank youuu Eloquent is too good

If your ORM code looks like spaghetti, it is because your database looks like spaghetti.

Not all ORMs are anti pattern :) Modern Data mapper ORMs are live well together with DDD and CQRS/ES and help you model your domain as plain objects by decoupling the mapping and persistence logic to infra/framework config level

@maksymkhartanovych2754

Жыл бұрын

and for read models (projections) you’re able to use any suitable for you storage and tools to represent your data to the client. You don’t need any ORMs at all for this.

@youtubeenjoyer1743

11 ай бұрын

DDD is an anti-pattern as well.

@sachaDS0

3 ай бұрын

@@youtubeenjoyer1743?! How so can you elaborate?

@youtubeenjoyer1743

3 ай бұрын

​@@sachaDS0 It's premature abstraction and overengineering for nothing. Write your script and go do something else. You don't need 7 additional layers of abstraction to parse an http request, select a few rows from the database, run a few if statements, and return an http response.

For me at least, the main advantage of using ORM is that the data you work with has a fixed structure. This is very useful especially on huge projects where there is no chance of remembering all of the data structures. It is probably not a problem in statically typed languages, but for example in PHP, ORM helps you not waste time searching for what properties arrays contain. Another useful thing is abstraction on top of your database. Yes, you can use views, but they are not a perfect solution for everything, especially if they call procedures. Databases are a hell to debug.

@ToTheMoonParty

Жыл бұрын

There's no such thing as fixed structure in software. Goodluck.

@Frozander

Жыл бұрын

@@ToTheMoonParty "Say random incorrect thing. Goodluck."

I was actually agree with him on the problem, but then he shows his solution and lost me. I mean did he heard about postgREST, which create a REST API on top of your tables, or Supabase an open source alternative to Firebase that leverage postgREST, GraphQL, and many other tools to go even further?

ORM came out of a long time of searching for solutions to the Object to Database problem. There were many solutions proposed. Some include things like "Pointer swizzling", "Texas: An efficient, portable persistent store", "InterSystems Caché" just to name a few. Over time, ORM won out. I think a salient point that is left out of conversations criticizing ORM is that is not necessarily a one to one mapping of classes to tables. ORM can represent all relational model entities such as views and stored procedures. ORM gives a convenient entry to the relational model.

@8forty

Жыл бұрын

You're right, ORM "won out" and was generally better for many than those other solutions, but that was a LONG time ago and I'd argue that ORM is not aging well, it's definitely time to be exploring new ideas.

@esra_erimez

Жыл бұрын

@@8forty Agreed, we should always keep a look out for better solutions. Interestingly, the authors of PHP and Go tend to shun frameworks all together.

I'm not a fan of JS, but I have a long history of using ORMs in production C++, Java, python. Your criticisms of typical ORM frameworks are spot-on in my experience, everyone should spend serious time thinking about your 80/20 diagram: it's crazy that so many devs focus on the 20%-effort/repetitive tasks and commit to the eternal grind of suffering through the disadvantages of whatever framework they've chosen for the 80%-effort/complex parts -- those parts are EXACTLY where I wish I had a framework to help, and your ideas are very interesting. (Also LOL at the hibernate joke, and some of other comments here, watching your core ideas zoom miles over their heads)

@aphluent

Жыл бұрын

Bruh, your'e not as smart as you think you are.

@8forty

Жыл бұрын

@@aphluent irony!

Orm is helpful especially in domain driven design. Also criticising orm due to optimization while using nodejs in backend is slightly ironic.

@MrHamsterbacke756

Жыл бұрын

Nodejs ist pretty fast

@heroe1486

Жыл бұрын

@@MrHamsterbacke756 node is kinda fast, not the amateurish ecosystem where each library import "is-odd" from npm. There's no point on having a relatively fast language if you can't do anything without third party dependencies and if those are generally not that good/fast.

I'm absolutely not a fan of ORMs. Setting aside that I once wasted a lot of time on the futile task of generalizing storing objects in relational databases, I'd still recommend heavily against using them. You're talking to a relational database (in the common case) and you need to understand how it works, so you need to be able to reason about SQL anyway. Once you can that, you can reason about most SQL. ORMs have the same issues as using too much syntactic sugar. It hides complexity you need to understand anyway and thus makes it a lot harder to reason about it when the underlying reality peaks through (and it will). On top of that it also takes away your ability to reason about the SQL for code new to you, since the way the ORM api works and hides the SQL is different from language to language and ORM library to ORM library. So when I, say, am thrown into a PHP code base using "Parable", it doesn't help me much understand it that I'm perfectly fluent in MySQL or some other ORM. Don't use ORMs. ... learn SQL instead.

@adhi_atma

Жыл бұрын

Seems like we are minority in here.

@rayvid7979

10 ай бұрын

Agree... ORM is catastrophic to many software projects...

@Peter-bg1ku

5 ай бұрын

@@rayvid7979 I disagree. They a useful for the boring crud stuff but they fall short when queried data becomes complex.

is there anyone know what chrome extension he is using for randomizing color palette (on his new chrome tab)?

I feel like every time people complain about ORMs, they complain about active record ORMs and others where the model classes are bloated spaghetti tightly coupled to the DB. And even if not, there's usually complaints about n+1 queries, as if every competent ORM didn't have multiple ways to stop that. Or deliberate ignorance to the fact that you can still make complex queries by writing SQL when it makes sense to. The only SQL I saw in this presentation was some DDL to create migrations. All the actual queries were handled by some magic transformation thingy, more magical than any ORM I've ever seen. How would you actually run your own complex SQL query? How do you handle a more complex update case where you need to query data, then patch part of it from user input and part of it from some other source? How do you do all of that transactional? Locking, optimistic and pessimistic? In my experience, logging becomes ugly when you're never sure which fields of your entity were actually pulled from the database. It's also bad when you query some related data that you happened to have already queried earlier and changed, but haven't commit _yet_; An ORM, it will know that the entities were already hydrated and return references to your existing, updated entities (unless you explicitly want it not to); some self-written SQL repository will give you what's in the DB right now, so now you get to deal with inconsistent data. Dirty reads aren't a feature, but a bug.

i ussualy add one ore more layers between my model and controller like an repository that i initialize in my controllers. In my repository classes i interact with my models and write my business logic, that after i altered i serve to my controller for a resonse. but here you should also talk about the type of ORM, is it activerecord vs datamapper since the way you type of ORM dictates the way you write your data access layer

Been using EdgeDB to avoid orms and it is such a joy to work with.

@aldogutierrez8240

Жыл бұрын

Thanks for the info. However, no java client for the moment

yes, me too. Important to know them for enhancing existing apps that already use it. But my own projects - no ORM: lighter and faster. Who understands SQL and DAO pattern may build clean solutions. That is my POV.

Did not expect such a video on JetbrainsTV. Have high expectations. Got a bad idea implemented in probably the worst possible manner. This was a promotional content, at best. TBH, I am short on words to express the concerns and disappointments that I have from this video.

Another point I'd like to make is that JavaScript originally started life as a scripting language to facilitate the manipulation of a browser. And, now we're writing server backends in it.

@xIcarus227

Жыл бұрын

@Master & Commander couldn't have said it better myself. I work full stack and frontend is genuinely my least favourite part exactly because of JS. At least the ecosystem has nice libraries and frameworks to help alleviate some of those woes.

To me it looks like he just wrote a clickbait title ,to introduce his own framework while only talking about orm cons to make it look legit

Focus on domain problem, when i use SQL i start to concern about all those SQL stuff, it too low level for me, the code seem ugly, why i need to concern about return value is a collection of rows, it can't be lint since it live inside TS/JS file, also you can write reusable class with ORM, data mapper, seperate between domain class and database entity class.

The guy starts the video showing an active record model as it is the only pattern. If you don't want your model to know so much, just use a Data Mapper. Basically you model is a representation of a tuple, a type. Can be in js, ts, java... Whatever. Collections are going to hold the... Collection of tuples. It's trivial. It's scalable, once you need to think about how you are going to avoid in all terms hitting the database whenever it's unnecessary. For a data mapper, you can have a class to manage entities and connect them to the database manager and.. the types (which are basically, the entities, or the models). And you can use a query to fetch data and turn into these objects and return to whatever thing is asking for it. IDK why people over complicate this simple thing.

This was a good watch, thank you !

I develop python codes around a large, fixed db schema. SQLAlchemy has made development and maintenance much easier. However, there are definitely performance issues for even a moderately sized database; it takes a long time to create all of the objects in memory. I don't think the solution is to ditch the ORM idea - it is a boon for development - but rather to figure out how to (greatly) improve performance.

I don’t necessarily agree with this. There are some use cases where ORMs work perfectly. Although some useful points were made agains ORMs this is mostly a Platformatic sales pitch imo

I"m really glad this video is titled "I would never...". For me, I would always use an ORM in every project. Asides the fact that writing raw SQL might be a bit of a hassle, having to maintain a language that is completely different from the rest of your codebase might be counter productive. It's why hybrid frameworks like React Native and Flutter were built. Sometimes, software development is not just about how fast the individual technologies you are using are, it's about how well you can architect your system to get the best performance out of all the individual technologies.

The is the first video from JetBrainsTV and IntelliJ IDEA by JetBrains channels that I ever downvoted. Please don't invite this person anymore. 90% of all top comments are more or less about how "bad" he is.

2k models not bad enough. 3k microservices - shut up and take my money.

Sorry, dude! CTO/Architect/Developer for over 30 years. You are wrong.

I grew out of ORM and other indirections years ago. I like simplicity.

I would never use JS for back-end development , before discussing about using ORM or not. ORM is about abstraction , something only understood by genuine engineers. If you had working on a product having to suppport multiple database , you would have been happy to have an ORM between your code and multiple version of multiple vendor databases . Its also a way to control code quality ; spring repository enforce good practice that SQL in the wild can't . Yes ORM has limitation , but pros know when to use / not to use it The CRUD use case is the best for ORMS

@fabionunes2793

Жыл бұрын

You forced a little bit with the "real engineers" and abstractions. Talk with Linus Torvalds about abstractions... Tip, he is an engineer.

@ComputationalArt

Жыл бұрын

me too, the problem is JS not ORM

@fabionunes2793

Жыл бұрын

@@ComputationalArt why JS is a problem? Node, browsers, they are just runtimes providing a way to interpret some scripts written in a simple grammar. JS is not a problem, the problem is you that can't understand the JS grammar. The same is with Java or other language, they aren't the problem, people needs to understand the grammar, the purpose of the language.

@ComputationalArt

Жыл бұрын

​@@fabionunes2793 I used NodeJS for 5 years(It's good), very easy is for small project, I suggest to try Go or Rust, It's another world man ;)

@fabionunes2793

Жыл бұрын

@@ComputationalArt hey, I know golang and rust. To be honest with I, they are way much better than JS in all sort ways, starting from the linearity in the grammar system, I mean, no babel, no conflicting module system, type safe... But, I have a huuuuuge experience with node, so, I can get better paying jobs in node for now. And I'm on a moment where I want tp achieve some personal/money involved goals hahaha.

Now I'm on the microservice part .. the silver bullet... If don't even have a product, why did you want to optimize it?

Find this is not true when using DB First, if you scaffold the database you avoid most of the typing. I guess is his personal opinion.

"Models represents a row in a database", Wrong, that would be a ROM. ORM takes an object model and uses a relational database for persistence. When using an ORM your thought process should be evolve to "Database? Isn't that where I store my objects?"

So, basically you wrote an unmature version of Django in JS. Congratulations on this. I always wondered when JS would catch up on these 15-year-old ideas. Interesting to see, but neither new nor revolutionary I'm afraid.

@BistaNadig

7 ай бұрын

Your argument is assuming django is any good. Sure, js on server sucks, but python is not too far behind..

I will treate ORM as infrastructure layer in DDD, which makes great separation of concerns.

Love this stuff Matteo ❤

"it hibernates" ... not bad

I want to learn concepts on building an ORM. What are these concepts?

I read a lot of “the problem is JS in backend and not ORM”. Could you guys elaborate more about it? It’s scaling problem, not clustering properly or what I’m missing here?

@midoevil7

Жыл бұрын

AFAIK , JS can be a nightmare generally for devs who are used to mature and typed languages. It is hard to scale JS code base per service, poor refactoring tools, poor code tracing tools, typed languages removes entire class of errors related to wrong types at runtime. And I believe the ecosystem generally shifts too quickly and not reliable enough, compare to things like java and C# at least, where you can have a code base that is 8 yrs old and its framework/tools are still supported.

@heroe1486

Жыл бұрын

Both aren't that related (except that since node hasn't a mature ecosystem most ORMs are average at best, they had to wait a slow Prisma to have a "standard"), it's just that you can't really brag about "details" when your whole backend is based JS

It seems exaggerated to me, ORM is not that bad, maybe Javascript is the problem :)

how this is diff from Yahoo Elide?

He's confusing general ORM with one instance of it he didn't like...

All the DDL code you keep editing can be generated by a simple String property in an ORM. You seem to enjoy typing more than solving problems.

You're using JS on the backend and swearing at ORM. You must have gone crazy.

Try Object Role Modeling. Many things can be derived from a well thought out model of the facts at hand.

I could only make it half way through this video, i don’t know how in good faith this guy can claim a model is also a repository and business logic? Also claims ORM is spaghetti code then uses npm?!?!???

Nice!

Pere con le noci. Un ORM solo si occupa della persistenza e gli oggetti non sono row del DB di fatto il "Mapping" si occupa esattamente di trasformare file e colonne in grafi. Puoi usare ORM ed aavere una struttura basata in features e/o microservices con widespread persistences... e lo dico perché sono 15 anni che le cose che faccio funzionano cosí. Comunque opinioni sono opinioni, l'importante é non crederci troppo a quello che si dice.

did I just watched an ad ?

Sql should part of a language structure or an extension

I love this guy's accent.

Models are database tables. So soon you will have 2000 models: well, duh! If you have 2000 tables, you have 2000 models. My guy has no point at all.

As Ted Neward said, ORM is the Vietnam of computer science. :)

Jpa hibernate saves my whole life 😂😂😂

He said " Objet oriented mapping ", seriously ?

This type of content regarding being against "x" technology confuses those of us who are learning a lot, you no longer know if the paradigm you are studying is correct, if it is correct or not to use certain resources. So what the hell do you recommend to those of us who are just starting out?

@heroe1486

Жыл бұрын

That you don't listen to KZreadrs and such too much, those are willing to make you consume content, and how they fo that ? By having polarizing opinions and changing opinions every 2 months so they can feed you something new. Stick to serious people, read official docs, quality blog articles etc. And basically everything popular is more or less "correct", it's just a question of use cases as always, search for those. Also start with the basics and then tackle abstractions, like learning JS before React or here at least basic SQL before ORMs.

So we should write SQL for everything?

@Lexaire

3 ай бұрын

No, you should write SQL for migrations, then use his codegen project to convert them to models, then pretend there are no models.

Love it

Platformatic = ORM + Code generator.... I don't see the difference.

Orm makes the easy tasks easier and the hard tasks harder.

using npm while talking about introducing complexity using ORM (I agree 100% btw.) seems weird.

Hibernate cried after watching this videom

Status Check: Is he still staying strong on his choice of not to use an orm anymore in his life?

But ORMs are the only way a "senior framework developer" can write sql. :(

Putting it out there, but graphql is horrible and mutations are more horrible again.

I'm jpa hibernate lover 😍

@macctosh

Жыл бұрын

I second that! I think he needs to try JPA and he will rethink his position

The arguments are so so bias and inconvenient.

Never say Never.

That Pareto principle graphic sucks, man. So the 20% are *part* of the 80% on either side? LOL. Never mind the sizes aren't quite correct. But this was just made using excalidraw, clearly. So oh well. Still, at least let's keep the crazy principle that the whole is 100% ok? If you mean to label the difference / remainder of the 100% circle, then don't center the 80% labels, but them off-center and make them the same size as the 20% ones. Also then, the top arrow needs to start within the circle , and the lower one needs to end within the circle instead of from/to the edge, which represents 100%, or "the whole". This graphic really says: "All outcomes result from 20% of causes, while 20% of outcomes result from all causes". To make things worse, "Causes" was replaced with "Features" and "Outcome" with "Effort". That doesn't quite figure, does it? Effort does not "result from" Features, to use the language of the first graphic. It's the other way arround. Features are the result of Effort. And the Pareto Principle says that 20% of the features take 80% of the effort to produce, or in other words "getting things started is hard". If you look at modern software, then 80% (easily) of the actually executed machine code, and some 99% of the build tools to produce it (the 1% being project-specific tooling like custom code generation and custom configuration), are libraries and frameworks, with ORM being a typical part of that mix. 20% of the code is what we then call "application code". it's quite easy to see that *way* more time went into the development of those frameworks in total (often person-decades of work), than into the application code. If an application took two years to produce, it'll use libraries that took 8 years to produce. What those libraries do are "features" of the product, in Pareto's principle.

Has this guy ever worked on a real project? 😂

over exaggerate and underestimate, what else can i expect from a life dedicated serious nodejs developer, i accept that i'm an average programmer, but i wouldn't buy that tons of brilliant minds before me did it wrong to be corrected in 24 minutes through another js framework ending with "-fiy" creator...

lol. this is just a poor mans orm over http.

I would never use a javascript, how about that ?

@0shakti0

Жыл бұрын

Good luck with that

@romandronow7648

Жыл бұрын

But you are using it everyday

@leularia

Жыл бұрын

@@0shakti0 hhhhhh

@astroid-ws4py

Жыл бұрын

WebAssembly comes soon, Haskell compiler integrated support to it today, And more and more languages are coming.

@Frozander

Жыл бұрын

@@astroid-ws4py It is already here, what exactly do you mean by it coming soon? which new feature to WA is coming soon. From my experience, apart from some browser based photo editors or 3d apps etc. nothing really uses it.

Can you mark this video as an #ad for platformatic? There is no useful information beyond that. Very clickbaity.

I don’t see why so many people say that js is slow in backend. Most of the time the slowness results from the one who writes codes, not the language itself. In fact, considering io bound nature of most web applications and the v8 engine, js can have performance roughly equal with or even better than compiled languages like C++.

@heroe1486

Жыл бұрын

Because when you import low quality librairies it doesn't matter, and since node isn't go where you can develop almost anything without third party dependencies voilà, the language speed doesn't matter that much.

🎯 Key Takeaways for quick navigation: 00:05 🗣️ Matteo Collina introduces the topic of Open Data Oriented Mapping (ODM) and expresses his enthusiasm for it. 01:09 📦 Object-Relational Mapping (ORM) models often lead to fat objects with multiple responsibilities, causing code complexity and unscalable architecture. 03:00 🍝 ORM usage can result in spaghetti code, making it challenging to manage complex codebases, especially when dealing with numerous models. 05:53 🧩 Matteo discusses the Pareto Principle and suggests that choosing a technology should optimize for handling the 20% of features that take 80% of the time. 10:40 🚀 Matteo introduces Platformatica, a web framework that offers flexibility, extensibility, and the ability to reduce repetitive tasks while still allowing for customization. Made with HARPA AI

prisma tho

@EduardoLarios95

Жыл бұрын

Finally a sensible comment

🤦 comments aren't shipping any software any time soon. ux demands are at all time high right now. you can't spend too much time on mundane tasks. orms offer better dx for doing the those tasks and ensuring everything is well buckled so that if things will break, they break before deployment and not test before things break. example story. if you're a guest, only show 3 post previews of someone's profile. in this example, if you hand-coded your authz rules in sql, not only are you leaking your business logic in your data server, changes will not break even they should be. IME best to avoid hard-set rules and you want to put them in a single place so changes are safer to do.

100% agreed

For the people complaining about him using JS for the backend, this is a JS talk.

@heroe1486

Жыл бұрын

Well he isn't there by chance I guess

This is one of the worst videos Jetbrains has released for sure

Just putting it out there, Pareto principle is not a fact at all, its very circumstantial and not very reliable when put throught rigor. And optimizations based on this will suffer the same fate. Its' time we stop using shitty examples and spreading misinformation based on hearsay.

Without react, nobody would use JS to build a complete websites. And why Facbook JS use should be clear. The users is totally transparent. Every mousemove and so on is detected and can be used for very bad things! Not nice, not good. JS was long time known as a bad ass, react and all the reactive frameworks did simply "green" washing JS ;-)

@witchedwiz

Жыл бұрын

I mean... I love angular and i strongly prefer it to react.... :X

@macctosh

Жыл бұрын

@@witchedwiz NextJs is way better, angular has no fragments and is frontend ONLY last time I checked.

I wasted 25 minutes of my life

Who even asked ur unrelated opinion?

@leularia

Жыл бұрын

who invited you again ? 😅😅

@kirillgimranov4943

Жыл бұрын

@@leularia I have no idea, but it's a fact that I don't have a clue who u r and who invited u here too At this point I don't wanna the answer as well as answers on questions unrelated to my topic question If u got nothing to say else - stfu and leave it to the ones who can, even tho I bet there's no one that can give relevante answer

@leularia

Жыл бұрын

@@kirillgimranov4943 just throw jargon's cause you have no idea about any thing, throwing your imposture at us lol you stfu

@kirillgimranov4943

Жыл бұрын

@@leularia r u outta ur mind? Firstable, ORMs are highly useful, but in some cases. In others they ofc aren't. This channel auditory that is interns need to use it cause they gotta create casual cases Secondable, this channel of dumb products can't get an attention with anything else instead of bating with such clickbait sht, pathetic

@leularia

Жыл бұрын

@@kirillgimranov4943 man i actually don't know the channel and am not supporter of his concept, am just here for the fun and you can't handle humor...

Actually I would prefer using ORMs over the microservice architecture (and orchestration) madness that comes with it.

This is technological propaganda in its finest form, these people seriously don't know what they're talking about. Why would you not use an ORM, which, typically, handles malicious attacks like SQL injections under the hood? Why would you manually handle stuff like that instead of using an ORM? Why would you write raw SQL queries when using an ORM is more secure? JetBrainsTV, if you're reading this, it's best to take this video down. You're spreading dangerous misinformation. What a shame.

English isn't your first language right?