I Would Never Use an ORM, by Matteo Collina
HTML-код
- Опубликовано: 14 ноя 2022
- What's an ORM? An Object-Relational Mapping tool (ORM) is a library for mapping a SQL table to a Class. In most cases, ORMs force the users to structure their code to have Model objects that include both data access and business logic.
Once upon a time, I did several projects using ORMs, as I followed the common belief that they would simplify the development and maintenance of projects. I was wrong. ORMs are often a hurdle to overcome for the most complex part of a project.
As the next stop of my journey, I recommended people use the native languages of their databases, e.g., SQL. This works great for the most part, but it creates quite a struggle: there is a lot of boilerplate code to write that can be quite tedious. I was wrong, again.
Today I'm presenting you something new.
Speaker: Matteo Collina,
Co-Founder & CTO at Platformatic
#JavaScriptDay2022
---
🔗 Browse our resources 🔗
Check out WebStorm, a JavaScript IDE by JetBrains, and get a 30-day free trial:
www.jetbrains.com/webstorm/
⭐️ Keep in touch ⭐️
JetBrains on Twitter:
/ jetbrains
WebStorm on Twitter:
/ webstormide 
Наука
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.
Umm, nice strawman argument I guess? Did you even watch the video?
@@8forty I did finish watching the video after my comment. I did like some of his arguments, and could relate to them.
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.
@@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?
@@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.
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.
I think nowadays it is an easy way to call for attention in this pseudo controversial approach.
Why’d you click the video lol
you lost
The reason you clicked and why they do that
thats quite a short sighted dogmatic statement ;)
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.
agree..very few people actually understand MVC only exists in presentation layer
I kept trying to understand what he's talking about, I kept loosing his point every 30 seconds.
Won't use an ORM but writes backend code in JS. Close video. ;)
*THIS*
Bravo, exactly my thoughts. Amateur
Cannot argue with the inconsistency portrayed ahah
He think that backend process is only CRUD operations through all entitites
😂😂😂
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.
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!
yea we can build backend in js using node js with express lib and pg lib (postgre)
@@aryabp That's what he questions, talking about JS is just easier than naming the runtime (node deno bun etc) and groups them all
@@macctosh can you give an example why so many linking tables? Thx
@@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!
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.
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.
Yeah I really hate ORM. Especially hibernate.
But i don't see any alternative way for my job.
@@gonkong5638 well, I guess it would be queries lol
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.
If your ORM code looks like spaghetti, it is because your database looks like spaghetti.
You would never use an ORM... in JavaScript? Why are you using JavaScript for backend anyway?
May be because he found the Fastify framework? Idk
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
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.
There's no such thing as fixed structure in software. Goodluck.
@@ToTheMoonParty "Say random incorrect thing. Goodluck."
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)
Bruh, your'e not as smart as you think you are.
@@aphluent irony!
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.
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.
@@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 would never use javascript for backend.
How about NextJS? I prefer react (frontend) and spring boot (backend) but NextJs features and extreme flexibility are very tempting!
@@macctosh no *hits head with newspaper
@@macctosh NextJS "backend" = bare express + limitations of serverless if you deploy to Vercel, it's nothing comparable to a framework like Spring
is there anyone know what chrome extension he is using for randomizing color palette (on his new chrome tab)?
Laravel's ORM is pretty sick though
Thank youuu
Eloquent is too good
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
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.
DDD is an anti-pattern as well.
@@youtubeenjoyer1743?! How so can you elaborate?
@@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.
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
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.
@@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.
This was a good watch, thank you !
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.
Orm is helpful especially in domain driven design. Also criticising orm due to optimization while using nodejs in backend is slightly ironic.
Nodejs ist pretty fast
@@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.
Seems like we are minority in here.
Agree... ORM is catastrophic to many software projects...
@@rayvid7979 I disagree. They a useful for the boring crud stuff but they fall short when queried data becomes complex.
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.
Love this stuff Matteo ❤
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.
Been using EdgeDB to avoid orms and it is such a joy to work with.
Thanks for the info. However, no java client for the moment
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.
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.
@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.
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.
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
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.
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
I grew out of ORM and other indirections years ago. I like simplicity.
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 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
You forced a little bit with the "real engineers" and abstractions. Talk with Linus Torvalds about abstractions... Tip, he is an engineer.
me too, the problem is JS not ORM
@@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.
@@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 ;)
@@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.
how this is diff from Yahoo Elide?
I will treate ORM as infrastructure layer in DDD, which makes great separation of concerns.
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.
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.
Your argument is assuming django is any good. Sure, js on server sucks, but python is not too far behind..
Now I'm on the microservice part .. the silver bullet... If don't even have a product, why did you want to optimize it?
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.
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?
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.
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
2k models not bad enough. 3k microservices - shut up and take my money.
Status Check:
Is he still staying strong on his choice of not to use an orm anymore in his life?
"it hibernates" ... not bad
I want to learn concepts on building an ORM. What are these concepts?
Sorry, dude! CTO/Architect/Developer for over 30 years. You are wrong.
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.
Sql should part of a language structure or an extension
Nice!
It seems exaggerated to me, ORM is not that bad, maybe Javascript is the problem :)
Try Object Role Modeling. Many things can be derived from a well thought out model of the facts at hand.
Love it
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.
"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?"
Jpa hibernate saves my whole life 😂😂😂
I love this guy's accent.
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?
That you don't listen to RUclipsrs 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.
Platformatic = ORM + Code generator.... I don't see the difference.
You're using JS on the backend and swearing at ORM. You must have gone crazy.
So we should write SQL for everything?
No, you should write SQL for migrations, then use his codegen project to convert them to models, then pretend there are no models.
did I just watched an ad ?
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?!?!???
As Ted Neward said, ORM is the Vietnam of computer science. :)
He's confusing general ORM with one instance of it he didn't like...
He said " Objet oriented mapping ", seriously ?
Hibernate cried after watching this videom
Orm makes the easy tasks easier and the hard tasks harder.
Putting it out there, but graphql is horrible and mutations are more horrible again.
But ORMs are the only way a "senior framework developer" can write sql. :(
I'm jpa hibernate lover 😍
I second that! I think he needs to try JPA and he will rethink his position
using npm while talking about introducing complexity using ORM (I agree 100% btw.) seems weird.
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.
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.
🎯 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
Never say Never.
100% agreed
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...
The arguments are so so bias and inconvenient.
lol. this is just a poor mans orm over http.
Has this guy ever worked on a real project? 😂
prisma tho
Finally a sensible comment
Can you mark this video as an #ad for platformatic? There is no useful information beyond that. Very clickbaity.
🤦 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. < i smell gaslighting on the latter. we can't rely on code reviews alone for catching every case there is nor should we be able to cover all test cases. *defense programming creeps in here*
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.
I would never use a javascript, how about that ?
Good luck with that
But you are using it everyday
@@0shakti0 hhhhhh
WebAssembly comes soon, Haskell compiler integrated support to it today, And more and more languages are coming.
@@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.
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++.
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.
For the people complaining about him using JS for the backend, this is a JS talk.
Well he isn't there by chance I guess
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 ;-)
I mean...
I love angular and i strongly prefer it to react.... :X
@@witchedwiz NextJs is way better, angular has no fragments and is frontend ONLY last time I checked.
This is one of the worst videos Jetbrains has released for sure
Who even asked ur unrelated opinion?
who invited you again ? 😅😅
@@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
@@kirillgimranov4943 just throw jargon's cause you have no idea about any thing, throwing your imposture at us lol you stfu
@@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
@@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...
I wasted 25 minutes of my life
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?