The problem with frameworks - Uncle Bob

[@LHCB6]

No problem, we just make a new framework changing the stuff we don't like. /s Just like everyone else. Now there are so many frameworks that we need to make a new framework for the frameworks.

[@ivilleinc5949]

Astro entered the chat...

[@StynerDevHub]

😂

[@furycorp]

@@ivilleinc5949 I hit reply to comment Astro lol and saw yours!

[@shafqatjanjua4879]

Oh no... Not necessary -- having a framework for frameworks....

[@mepipe7705]

Yo dawg, i heard you like frameworks...

[@gediminasmorkys3589]

In order to use a framework you have to make a huge commitment to them. Well, if I write something from scratch, the company is making a huge commitment to me :D

[@VincentJenks]

One level removed from the problem vs two, or even several depending on all of the framework's dependencies. A smaller internal problem to fix vs one or many external problems that likely can't be fixed.

[@gediminasmorkys3589]

@@VincentJenks but how do you solve me, without essentially writing all functionality from scratch? (and if I wrote anything more than a TODO app, I also probably introduced some kind of opinion/framework 🙂).

[@VincentJenks]

@@gediminasmorkys3589 By managing the dev team properly, to develop your custom approach to closely match the business's needs, and the team that maintains the code. This is what a lot of young developers overlook - you're there to provide value to the business first. You're being paid to solve a specific business problem, and large frameworks can't necessarily fit that specific need as well, due to the generalization they impose. You end up with a few of your problems solved, and several new ones to overcome that you hadn't anticipated. The answer is a very light touch with external dependencies & libraries, vs full-on large-scale, bloated frameworks. I've built and been on teams involved with dozens of large projects over the years, and big frameworks always end up in the way just as often as they solve a problem - just like Bob describes. In the end it's about balance, moderation, and keeping the engineering to a bare-bones minimum to solve the problem before you.

[@mywreckednoah]

Job security is good

[@hb-man]

Uncle Bob's point is the entanglement of you using a framework vs. you intelligently picking components and tie them together yourself. Frameworks boot productivity in the initial phase, where your other option still keeps you busy tying stuff together, but a successful project lasts, and the initial boost becomes meaningless quite fast, and it's all about long term maintainability.

[@rafaelanschau3196]

What he says about frameworks is true for any architecture. You commit to the architecture, it doesn't commit to you. Your code get coupled to the architecture. The framework benefits you in the sense that it gives you ready-to-use architecture. There is always going to be an extra effort you pay in order to have structure, so then your code doesn't become a mess as it grows. Whether the architecture was explictely made by an architect during project or reused from an existing framework is a minor issue compared to not having an architecture which is almost always the main issue. The cost benefit of a framework is obvious. You gain a durable structure as the system grows, you pay with extra effort to program within its constraints.

[@rafaelanschau3196]

@@stanvassilev Right, try to change to architecture of a million LOC system that has been around for 20 years. Good luck "controling" that. The only reason in which architectural design makes sense is if you are operating in a domain so new or so unique that no suitable frameworks exist. Of course, you can also be a control/customization freak or have a fetish for doing architectural design, or maye you are new to the field and want to practice, which is perfectly fine. Seasoned architects know the dominant architectures for specific domains and have no problem re-using them as they see fit. Indulging in architectural design can be fun, but only done by senior architects as a last resort.

[@addanametocontinue]

Yep. Even without a framework, every company ends up creating their own code architecture, anyway. The comparison really is your homegrown framework vs somebody else's. In most cases, somebody else's tried-and-true framework is going to work a lot better, especially if it's popular. Sure, you can create your own very custom framework, but it's not like it won't be free of the same issues as your application grows.

[@ysayius]

You say constraints like it’s a bad thing. Constraints are very important and often beneficial in that they keep collaborators on rails

[@rafaelanschau3196]

@@ysayius Well, constraints cause us to spend extra effort to understand the constraints and to program within the constraints. They are necessary, but not exactly pleasing.

[@aheendwhz1]

Use machine code, else you commit to a language. Wait, with the machine code you commit to a type of machine. Damnit!

[@cloudboogie]

I think lots of people don't get it due to duality of tech industry and difference in work experiences. Some of us are working in multi-year, large scale projects. Others pour their work into startups, that will cease to exist in a year or two. Those two types of developers have different goals, which influences how they choose technologies and how they approach software architecture.

[@ChristopherSalisburySalz]

I agree. Greenfield development is when people are so sure of themselves and their choices. Supporting the same application over the course of even 5-7 years is a whole different experience.

[@toddbu-WK7L]

In 35+ years as a software developer, I have discovered that there are two camps. Camp #1 wants to do everything quickly, relying on shortcuts like frameworks to get the job done. While the first 80% is easy, the last 20% is difficult. So they compromise on their software to work around problems. What they end up with is junk and often needs to be replaced because it is not up to the task. Camp #2 recognizes that good engineering takes time, and that junior engineers only become senior engineers with practice. They achieve most of their goals with a good upfront design, and compromises are few and far between. When it comes to cost, Camp #2 is cheaper in the long run because you have skilled people doing quality work with far fewer iterations.

[@australianman8566]

Some can ship code and iterate fast, the other just keeps reinventing the wheel again and again very poorly. The latter type you mentioned are the worse to work with or hire

[@toddbu-WK7L]

@@australianman8566 iterating fast is a justification that I hear all the time for Agile, yet should that necessarily be a priority? My experience has been that businesses that want to iterate fast are those that know least well what business they are in. They are constantly chasing "the next big thing", all the while burning resources and wasting cash. My last company was constantly chasing revenue so that they could IPO and make a bunch of money and pass a huge amount of tech debt to the poor sucker who overpaid for the company. If speed is your only thing then sure, use any old random framework. If you'd rather have something sustainable that won't need to be replaced in 18 months then choose your tools wisely. Frameworks can be a part of that choice when the framework is well designed and is not necessarily the latest fad. Sadly, it's often the people with the least experience who are making these choices because they see one shiny feature that will help them and ignore the pitfalls of the rest of design.

[@sherlockshlome473]

Reinventing the wheel for avoiding frameworks??? You don't know the difference between a framework and a library, do you?

[@armanmasangkay6513]

Most of the time, projects are short lived and quick idea iteration is vital in business.

[@mdesnica]

@@armanmasangkay6513 If the idea is good and accepted by customers, then ditch the prototype, and select another lighter framework, or even programming language.

[@peterstevens2887]

It is not bad to use frameworks. But do not select on base of how easy it is to do something simple, but on how easily it supports your most complex thing, so that it does not get in your way. And how easily you can swap it out. Very reasonable.

[@StupidusMaximusTheFirst]

I agree with you, it depends on your preferences. Some people might not care for anything else other than easy and simple, others might do what you suggest. I'd go for a minimal web components framework, without too much extra convenience, so I can easily use vanilla JS with it if I have to, so no React, Next, and all that. Frameworks have a place in webdev, just as they do in other fields of computing.

[@davidmartensson273]

For small projects sure, but for a large project, swapping out is almost never really an option, and if you go for it, its going to be a process over time. Having built a product that evolved for 17 years before I left, going through different languages, frameworks and more as old ones got deprecated I first want to say, you do not build anything big (unless your building a framework) on bare metal, frameworks do add a huge value, but yes, do choose those frameworks carefully. New and shiny will most of the time mean, high risk of stagnation, hard to find developers, and actually, limited support in features. A more mature, boring one, that have been around for a couple of years at least with some steady progress are very likely to stay alive, maybe not be the best for the moment, but since changing is very hard and or expensive, buying into one that is established means less risk of getting stranded and forced to change. If your building something smaller that will be fast to build and you do not envision expanding and supporting over multiple years, sure try the bleeding edge for fun, education and at best, fast results. But be prepared that it might falter and die just as quickly.

[@Tekay37]

The bad part about frameworks is that they are hard to remove from your code when they get deprecated. We're having this problem with AngularJS right now. One of our projects still depends on it, because it just is a lot of work to even switch from AngularJS to Angular. We'll have to rewrite both most of our frontend code and significant parts of our backend API in order to switch to a different framework, which will not get any budget (in terms of dev time). If we want to switch a dependency, we have to do it gradually (e.g. one module at a time whenever we work on it). Good luck managing 2 frameworks in one project and have them communicate properly. It's a lesson I had to learn the hard way 3 times. (1st: join a project with an already deprecated framework, 2nd: choosing the wrong framework for a new project because it promised fast results in the beginning, 3rd: choosing a framework that made us fight against its limitations ~1 year into development, causing quirky workarounds. Libraries are almost always the better choice. In web development this would be either jQuery or HTMX with AlpineJS, because they allow you to organize the code the way your project needs it.

[@davidmartensson273]

@@Tekay37 Sure but if your building any sizable site, building without a framework will make finding the right people harder and also can slow you down. Sure you do have more control, but will you be fast enough? Also, frameworks can help out with things you might not have inhouse competence or resources for. It also depends a lot on what type of site/application you are building I guess.

[@Tekay37]

​@@davidmartensson273 I disagree that using no framework would slow you doen. It's very likely the opposite that the framework will slow you down once you want to do more than just basic stuff because the framework doesn't work well with the new feature you want to implement. Also, please name a single thing where the framework can help out with things apart from the very basic stuff. I haven't seen any feature yet that isn't solved by a library as well (and libraries usually do a better job)

[@deceiver157]

Arrogant people crying out loud about an old man being old should re-read "Clean Architecture" since this argument about frameworks seems to fly over your heads completely when condensed into a 2-3 minutes video.

[@veic]

Nothing you do (years) down the line can fix the decisions you made in the first 5 minutes: language and framework choice. I would even expand his argument to include programming languages as well.

[@deceiver157]

​​@@veicthere are no absolutes and hard rules to be followed dogmatically. Context matters, everytime. But there are plenty where maintaining a certain degree of decoupling speed productivity up. It's a matter of designing focused on making change less costly, because free of cost is practically impossible. This applies to much more than frameworks, it applies to unit testing as well. And yes, you could potentially extend it to programming languages or even paradigms as well, but that's clearly going too far.

[@veic]

@@deceiver157 I'm a Sith and I deal in absolutes

[@cpn28]

Couldn’t agree more

[@brotherpeter00]

So what makes an architecture "clean"? What demonstrable affect does it have on performance of the system? In my experience architectures that take on this arbitrary form, are many times slower and require much more power. The "clean" movement is part of the reason that software runs so slow today despite such great advances in hardware.

[@aytviewer2421]

FINALLY --I'm a 50+ year old programmer who has been saying this for the past decade. I can start really fast and make a cool demo or prototype, but then Sh!t gets real and you end up either working around it or dumping it altogether.

[@yezinia]

Kill the Prototype and start New as soon as it get's real. That is what other industries do as well. Problem starts when you mix explorative development with productive development. Blaming a framework for Bad Implementation just reveals skill issues. Frameworks are not build to intentionally harm you and your product but make your life easier and in many cases safer. A lot of framework features are really mature, well tested and their usage already has best practices. And guess what you can use frameworks in a maintainable, extendable and testable way

[@alexisdamnit9012]

If that’s the case, then it looks it’s a developer problem. If you make a decision to use a tool, you should be aware of its capabilities as well as limitations and communicate that to everyone

[@789juggernaut]

This is the truth. Frameworks also prevent junior developers from learning the fundamentals and nuances of core web technologies because everything is hidden behind the framework. Having said that, it's not practical any more to write large applications without frameworks because it takes too long, but before you choose a framework, make sure you understand how to combine framework code with non-framework code so you can leverage its power but step outside of it any time you need to.

[@addanametocontinue]

People don't make frameworks for the purpose of screwing over a junior dev's education path. If a junior dev wants to use React.js without learning vanilla JS, that's their own decision.

[@dadi_vlogs3254]

​@@addanametocontinueTrue, but for his favor he should make Vanila Js on the front of burner to soak it up well.

[@DMC888]

Everything is hidden behind something. I remember learning Basic and reading about professionals coding in Assembly saying we’re not real programmers.

[@789juggernaut]

@@DMC888 Very true. For me, it's more about whether the "hidden" elements should be something you should learn to be better at your job. If I was a dev manager, I would prefer someone who not only knew React or Angular but had deeper knowledge of underlying web technologies.

[@DMC888]

@@789juggernaut I couldn’t imagine being a React dev without knowing basic HTML, CSS and JavaScript. They’d also need to have some basic networking knowledge. Using Next & React I worried I’d forget all this stuff, but I learnt most of it in the early 90’s, so it’s seems to have stuck.

[@stea27]

That's true. But if you start with no frameworks, then your development costs will skyrocket and probably won't get clients because they will find another company who does it cheaper with frameworks. And nowadays the "time to market" requirements from companies is usually as fast as possible and if they manage to succeed the following months/years, then they are agreeing to fund further code quality changes and other things. So again, unless you are in a very specific use case, starting projects without frameworks do not make sense development wise or cost wise.

[@suhailfares4679]

It is more about the fact that your app MIGHT grow and then u'll see limitations in the future because of frameworks..

[@SansGuidon]

We committed to a framework to generate web pages easily through TypeScript and VueJS, a build pipeline, an opinionated set of CSS rules. Has been great to build all those web apps through CI using also Docker, in the end the HTML that is generated never really moves but the whole build/deploy stuff only took a few weeks of work and months of maintenance. But at least we have saved ourselves the need to write HTML from scratch which would have cost likely at least 1 or 2 days and made the company rely too much on people who know CSS and HTML. It's way better to rely on people who know TypeScript + CI YAML + Ruby on Rails + various CSS frameworks and rules decided by some companies for us and rely on pre-made built tools that we need to upgrade along with the hundred of node_modules that come with them. It's an heresy to learn HTML and CSS when it's so simple and easy to convince any business that building an app is complex and requires frameworks specialists. It's a vicious circle.

[@hugoestrada2089]

Facebook was started without a framework. PHP allowed one to create web apps very quickly

[@comforth3898]

​@@suhailfares4679 how about limitations because of your chosen architecture

[@oxygenromania]

Costs skyrocket or you get tied down once the app grows and needs nee features. Frameworks = shit

[@shedokan]

"You must commit to them, they do not commit to you" This is true for any piece of software, not just frameworks. Also, it is not true that it's more difficult to write code in the future - it depends on what you're building

[@programmer1356]

However, using a library or an API over some interfacing libraries or standards that are not controlled by the Framework Provider does not leave you with the same degree of liability.

[@rayyanabdulwajid7681]

It's obviously more difficult to rewrite framework code in the future, because their paradigm changes rapidly especially in the front end development ecosystem

[@gediminasmorkys3589]

Well, I am also committed to a certain ratio of nitrogen, oxygen and some CO2 for breathing. I should have built my own mix, but now I am stuck with what I started on, all those years ago.

[@indignocat]

Case in point: the Android framework. Try writing an Android app without it nowadays.

[@stephenkolostyak4087]

"The problem with frameworks - Uncle Bob" In my experience the problem with frameworks is that too many people who can't do the work use them to hide that fact.

[@corepunch]

- How to replace a word in a string? - Use boost

[@yaminhijazi8581]

Frameworks make us look smarter in the interviews and in the meetings. We (as developers) are almost never estimated by our analytical abilities , we are judged by the frameworks we claim to know.

[@wknight8111]

The problem domain that a Framework is trying to solve is "how to build applications like this", while the problem domain that your app is trying to solve is "how to solve this business problem". As framework developers incorporate more use-cases and gain deeper understanding of *their domain*, they will eventually make breaking changes, bump the major version number, deprecate the old versions, remove support from old versions, and *force you to change the way you implement solutions in your domain*. I've seen some extremely painful and expensive framework upgrades, Spring and Angular as two recent examples, where there is no *business need* to update the framework except for managing the liability of a framework outside it's support lifetime. Some libraries and frameworks make transitions a bit easier, but it's never going to be painless because framework code is so foundational.

[@zorksox]

I couldn't agree more. As a game developer, premade/store-bought assets are often large enough to be called frameworks and have their own APIs. They give me a head start in the first week, but after that I am deticated to using code that I didn't write and often has too many features that just complicate things. Spending the first week building my own solution has always benefitted my projects. Not only do I completely understand the code, I gain valuable experience building it myself.

[@F肯尼]

I feel you in this. I make a ton of mini web games and one thing people get shoacked about is that I don't go out there and run for Unity or Godot etc for a simple 2d platformer or retro style project. The more I code this way the more I feel happy that I don't have to waste anytime with build steps etc. Also if I just need to port over a game its that much easier because I wrote all the code so I have a better control at fixing things

[@dearlordylord]

I’m trying to not also use programming languages because that benefits the authors. They want every statement written in their language and make me couple everything to their syntax

[@rayyanabdulwajid7681]

Nobody is rewriting programming language every 2 years like frameworks.

[@thefreemarketdev]

same with hardware

[@hectorfranciscohernandez2597]

In fact I'm writting my own language . Not kidding .

[@joefuentes2977]

I'm developing my own electrons. Tired of God getting in the way with all this petty "physics"

[@estebanuo]

😂

[@mazhigigikamiludin1383]

I am not sure what he is trying to say, but the major goal of utilising a framework is to establish a standardised code/file structure that allows multiple developers to contribute and develop it for future expansion. Imagine attempting to decipher the classes and file structure created by a previous developer when everybody has their own habit. Using a framework eliminates the need for project managers to manually create and brief new team members of the standardisation, which can be time-consuming and lead to mistakes.

[@keithl3789]

He's just saying consider the tradeoffs rather than just following hype or something.

[@gammalgris2497]

There are several aspects to consider. 1) A framework implements the ideas and requiremebts of the author. How do your requirements match with these? 2) There are various ways of integration. A bad way would make testing more expensive. A bad way will cause you great pain if you are forced to migrate some day. A bad way might force you to stay on a legacy version of the framework. Etc. 3) A framework also means standardization. It may not be what you really need for every one of your use cases. It will not help you everywhere. You still need to decide where it will be useful and where you have to deviate from it.

[@AllHandsOnEveryThing]

I guess this is the only reasonable take i have read so far. It also means you're crippled🤣🤣🤣

[@andresvallelisboa5511]

Many frameworks make you use a dirty architecture, and make use much code that you do not need. If you want to use a framework it is ok, but you should never make your entities amd your business logic depend on them. You can use it as a dependency. Whenn you put all your entities and business logic in the hands of the framework the framework can change, can stopped to be maintained. You do not have control nor choice on what happens to that code.

[@KyleSmithNH]

Not using a framework does not mean not having a consistent, documented architecture. The best projects I've worked on have had home grown, well cared for and organic frameworks that suit the need of the project: no more, no less.

[@dschledermann]

I generally shy away from larger frameworks, but in order to get stuff done you generally have to use a few trimmed packages. I code mainly in PHP and Rust and I maintain a couple of legacy Perl applications. In PHP we've got burned by Laravel, with a project that ended up in a completely unmaintainable state. It eventually proved unfeasible to upgrade the project to a newer version of Laravel. I now have the habit of choosing a few required packages for a given project and integrating them. This method works good for PHP and Rust. I'm not really a JavaScript or TypeScript developer, so I don't really have an experience how feasible that approach is there.

[@SaHaRaSquad]

It's fine as long as everyone in control has the restraint to not install a package for absolutely everything, whether that's Rust or JS or whatever. But unfortunately most developers in a team tend to underestimate the true cost of dependencies.

[@Michal_Lipek]

I also use PHP most of the time and I really don't know why people choose Laravel over Symfony. It is so much easier to make a good architecture with Symfony.

[@andresvallelisboa5511]

Laravel with its horrible architecture can be a pain in the ass. I would recommend you slim php, it is minimalistic, you can choose your own architecture, the libraries you need and it is lightweight.

[@andresvallelisboa5511]

Symfony is much better, it gives you more control over the architecture. But it brings a lot of dependencies and packages you may not need. I prefer slim php. It gives you full control of the architecture and you can choose your packages

[@aheendwhz1]

Use Symfony, use Doctrine. Those were the first that came into my mind when he said "they force you to couple your code to the framework", because they try to do the opposite. Of course you'll end up writing some framework-specific code and confiuration, but they try to keep that to the minimum, so that your code can be reused even if you drop the framework.

[@glennraya]

I’ve been using a framework for almost a decade now, and it’s been a game-changer for me. I’m not sure about the part where the creator of the framework says it benefits them more than the users, but I totally get the point. It all depends on the quality of the framework and how committed the creators are to maintaining it. If they’re dedicated to making it easier to use over the years, then it’s definitely worth it for us users.

[@StephanHoyer]

Curious which framework you use. Could you tell?

[@glennraya]

@ I'm a web developer. I use Laravel/React etc.

[@tumpperi3891]

Something like React should be quite safe choice since meta is so invested in it themselves.

[@chudchadanstud]

​@@StephanHoyer Why do you need to know lol? It literally doesn't matter

[@michaelbrauner]

That's the reason why I love Symfony so much. It consists of components that you can combine as you like.

[@Danyruddy7]

Yeah! Symfony has a lot to offer.

[@Michal_Lipek]

And it's universal. You want a loosely coupled application with the framework. Easy to do. Need fast prototyping? Just install Maker, Easy Admin and a few other easy-to-install tools and you can build a simple app really fast.

[@pjf7044]

I’ve never been a framework guy. I like to have control down to the 0 and 1s and know exactly what’s going on. As an engineer I’m not sure how or why you’d want to let the framework and all it’s abstractions take over and essentially control your code. I like writing my own code and solutions with vanilla, it’s fun for me.

[@aheendwhz1]

Which language do you use?

[@free_thinker4958]

Python ​@@aheendwhz1

[@MizManFryingP]

At least in the case of front end development, I find that projects built using vanilla javascript to be a lot less maintainable than projects built using some sort of framework. Managing state in vanilla javascript is a nightmare on a large scale application..

[@azureaki]

Absolutely. I don't know, honestly, who's this message for. In my case, the only cases in which I've found projects where the frameworks they've been using have become a problem are projects that are like 10 years old at least. You'll enconter those problems many years down the line whether you're using frameworks or not.

[@matusklement5029]

@@azureaki It is not, and never was about not using frameworks. It is instead about using framework in such a way, that makes it as easy as possible to switch/upgrade to another framework, in case of need. Translated into JS world, imagine you are using React, and you'd realize that you want to use Solid, or Vue suddenly. The more your code would be decoupled from React, parts for example like HTTP calls to server, even state management, and obviously everything domain related, such as form validations, etc - the easier it would be to migrate. In ideal case, all you'd need to rewrite would be the rendering logic. That's the difference between using and abusing the framework.

[@kaedriz]

@@matusklement5029 But it is not possible in Frontend world? React JSX vs Vue SFC are just too different. If frameworks collaborated on a single thing for reactivity (ex. signals), then state could be somewhat doable, as of now, they just do state too differently. If you are writing abstractions over framework any other time, why do you even use framework in the first place, if it is slowing you down.

[@luanrodrigues4901]

@@kaedriz I faced this problem when building a frontend app (as a backend dev). I tried to hide my business logic behind a service layer , with all validations and API communications. There was no frameworks involved , and it was really easy to implement the validation (I was even able to use any form validation library without couple my code). The framework was only there to manage the page state (update variables state) and render the styles, while all the logic to process the user action was hidden by the service layer :) So yes, It is possible and I think the frontend community does not have any interest on come up with a layered architecture, the mentality right now is to couple every single lib into the framework in such way that most of those cool libs have an adapter layer to each framework so you can use it directly from your components (I don’t like that)

[@kaedriz]

@@luanrodrigues4901 Let me get this right. So you put business/form validation/data fetching logic in separate layer, as in external functions, which you just call from your React/Vue/Svelte... code?

[@GnomeEU]

100% agree with him. A library or framework should be a tool to help me get my work done quicker. Not impose all kinds of rules upon me.

[@netssrmrz]

Spot on Bob. They lure noobs in with promises of simplified development and by the time they hit the limitations, of the framework, it's too late to back out. It's fascinating to see how obstinate people can be even as their framework sinks into obscurity and irrelevance.

[@notactuallyarealperson2267]

Sounds like a bad framework with leaky abstractions.

[@CristianKirk]

The first 10 seconds says it all: "Frameworks... part of the fashion that happens in our industry are various frameworks".

[@adambickford8720]

You always end up in a 'framework', it's just a matter of if you create your own or use someone else's. In practice its often easier to solve 'spring' or 'rails' problems than java/ruby ones.

[@codecaine]

I rarely use frameworks. Especially now that I do not have to program in a company. There is so much more freedom, and I can accomplish what I trying to do in timelier.

[@xealit]

"framework" already means some comprehensive/integrated way how to do something. Of course, that means deep coupling. Uncle Bob is good at elaborating these things.

[@darrennew8211]

A library is something you call from your code. A framework is something that calls your code. If you don't write main() and decide when to invoke it, it's a framework.

[@Kadiiiriow]

I think his argument, although not incorrect, doesn't really touch the actual problem of coupling. A framework by definition is a boundary, much like a programming language is. Both the framework and the programming language will bring coupling and limitations to your processes. These limitations/boundaries are of course more narrow for frameworks than for programming languages. Now my point is that, this kind of boundary or coupling you will ALWAYS have, it's not something you can escape from. Much like for example, the boundary of in-housing a framework or completely building app from the ground up will all bring a certain boundary and limitations applied to you by the toolset you've chosen to use for your solution. It's not really capturing the essence of the problem, that is how to create good architecture to de-couple the actual technical implementation of your application from your technical implementation of your business rules/processes.

[@mooripo]

I learned web code while I was my final high school year and i loved it, I simply used simple and plain html5/css3/html/mysql in 2012 Nothing fancy, I created everything I wanted, it was a hobby.... Some years later, like 3 years, I came back to dev again and I was so surprised, very, of how frameworks were popping everywhere ... I found it difficult to find new resources to update my knowledge on plain languages... I thought I grew old 😂 thanks for the video

[@happypolishboy]

"We do what we do not because it's easy, but because we thought it was." Took me a couple projects writing my own code (because frameworks felt too complex) to realise that the problems I was solving are way more complex than it seemed at first. Frameworks do so many things in what at first glance seems like a needlessly complex way, because they've already anticipated that complexity.

[@mistergions]

People are missing the point of this video. He's not saying not to use a framework. He's saying to pick up the best framework for your needs. You'll end up using a framework most of the time. Why do you need to reinvent the wheel if some tools have been made and it's secure and maintained? If you choose a framework and customise it extensively, make sure you are not just locked into the framework structure but can also create features in your own way.

[@gediminasmorkys3589]

@@mistergions it is almost like he doesn't make the points you just made. At least in this short video.

[@MrBlackWolfX]

Uncle is right about coupling the application code with the framework contracts, yet I still choose to work with a framework that is deemed reliable and well supported.

[@mohammadhatoum]

Oh now I am relieved, finally, someone agrees with me about the impact of frameworks.

[@Lopoi]

Is that a problem with frameworks? Or just the reality that when starting a project you should find the one that suits your needs, or is open enough to accept change? At the end of the day every programing task will have its limitations, unless you build stuff from the ground up, you are always commiting to someone elses system. That why we have standards, documentation, tools, patterns, to make developing easier.

[@aheendwhz1]

All those framework haters could as well hate against programming languages and compilers/interpreters in general. The truth is: There are many bad frameworks out there, because it's much easier to create something you can call "framework" than something you can call "programming language". Like with every dependency, you need to check wether the commitment is worth it. That means, if the dependency will be maintained for the lifetime of your application, and if it is flexible enough for your needs. Unlike programming languages, good frameworks and libraries are built in such a way that they can relatively easily be swapped.

[@simonkrige8888]

8 months into the project Uncle Bob finally got the login button to work

[@infantfrontender6131]

And he is still on the long road to writing tests and docs for this button

[@cdoubleplusgood]

@@infantfrontender6131 If it was Uncle Bob he would have written the tests before. 3 different tests for every proposed line of code.

[@armanmasangkay6513]

Bro

[@4g5VrFC2]

I think that skill and seniority might have lot to do with this subject. Also, the simplicity or complexity of what's being built. If it's simple, it won't really matter if a framework was used or not. However, if it's complicated, or needs to stick around for a long time and have multiple developers or generations of developers work on it, a "framework" becomes more "necessary", in the sense that some sort of architecture is needed to help those people communicate abstractions. If whoever started the project was able to do it without a framework, they should either do a job so good and intuitive that the next poor dev will be able to work with it and build on it, or use a framework because that would play the role of the architecture used to create the project. Either way theres always some "way and logic of thinking and creating that's followed " to create any work .. a framework, and sometimes it is beneficial to sacrifice some flexibility for the sake of some rules just because they've been already studied and understood by others.. I dunno if I make enough sense to be understood, but then again there's no one single framework for formulating ideas xd

[@steve16384]

Entity Framework is a prime example. Great for getting new projects up and running, but as soon as you want to do something different, you're in for a whole heap of pain and work.

[@karasira2696]

There is this old saying in the software industry, that ‘If you’re not using a framework, you’re building one.’

[@kostaarnorsky]

And sometimes you better to build your own framework. But rarely and even more rarely right from the start.

[@marlub]

There are pros and cons of using specific frameworks and to chose one of them or not, it always should be a decision based on the environment you work in or the product you want to create. There is no one simple answer that frameworks are bad or not. They can help a lot but I agree deeper you are the harder it is to fit someone's else standards - framework's producer in this case. As always, the answer is: it depands ;)

[@hoangkimthienlong]

Ok I think the statement has some points, so what will we do with this statement? Do I have something to do with it ?

[@SilverPaladin]

Without frameworks I would not nearly be as productive. I get as much done by myself as a team used to accomplish when we did every project from scratch!

[@ifeoraokechukwu1346]

What uncle bob is saying is true but it's also true of libraries or even code you write that others have to use too.

[@DevMeloy]

In FE code, all my external libraries are proxied in a single location. This allows me to replace, extend or remove from a central location. Frameworks will always have pain points, even one that is homegrown.

[@haibaidzokwomandre1468]

As an aspiring hacker, coding most think from scratch helps me understand a lot

[@guxershmeg]

The main problem with framework is they are based on SOLID and have interfaces with abstract classes and virtual functions. Not on C-interface functions as classic libraries. That are very easy to use. And do not cause any trouble never.

[@redhotbits]

swiftui is notbased od solid, thank god

[@sarath.sandwich]

In the fast moving world, whatever architecture has to adapt with change. I believe in the end it's a business that needs to change. Whatever helps the team ship products faster to the market, adapt to change should be considered

[@reactstack257]

Frameworks save our time. Nothing hurt if you have a solid background in the programming language that the framework has been built on Happy Banana :)

[@ChristopherSalisburySalz]

Whether you roll your own or use something that already exists, it always gets complicated years into the project.

[@erwile]

Good frameworks are flexible enough to not getting into your way. But if you have no framework or if it's too 'flexible' or 'light' you have to write your own framework to automate or uniformise your code... You always have a dependency somewhere, if it''s on a good framework, you have a depedency well documented and upgraded through time with people sharing common problmes. If you have no framework your dependency is each dev, which can be good, but not for long term. Having no dependencies can be effective for some niche/high tech, project, but most of apps have core functionalities/problem in common, and very often you're just trying to redo something that someone else has already solved in another way.

[@mikhailglukhov6680]

I hugely agree! I hate frameworks like React which have a steep learning curve and create a headache when what you need to do does not conform to the “religion” of the framework. That is why we still use jQuery for frond-end development and feel absolutely happy.

[@michaelholopainen2822]

Yes, everything uncle bob says is true. Frameworks are tradeoff, not magic. Bob has tendency to focus heavily on the negative. Frameworks have many positive aspects too. Like writing everything form scratch is also huge commitment. Hiring new people to develop that propietary and legacy code is a risk and slows down business too. In business you rarely have the lead time to write all the code from sratch. You project need to get your project into production and start earning as fast as possible or it it runs a risk of being cancelled in the next corporate reorganization and priotity shuffle.

[@saeedgnu]

That's why I always prefer to use a selection of small libraries. One thing I don't understand is that even in 2024, there are no tools that let you create a minimal version of a library or framework that only has what you are using, and so you can start maintaining this minimal thing that you uss all of it.

[@azureaki]

You mean like a template (like the ones in GitHub)?

[@lucasbran293]

Yep, instead of using frameworks that have been around for years, developed and maintained by people way smarter than me, I'd rather develop such functionalities myself, which will eventually end up as a crappy framework that only I will understand how to use.

[@rsgilbert6152]

Well spoken. Always remember that you have to commit to them. They don't have to commit to you

[@comicalInsan]

doesn't sound like a real argument. Try implementing all the battle tested functionality that frameworks provide with over confident and under performing developers.

[@spamviking8591]

My favorite framework has always been Phalcon because of how loosely you can couple it. Want to use only the ORM? Sure. Just need the Dependency Injection? No problem. Use what you need, ignore what you don't.

[@I_am_Raziel]

The "ignore what you don't need" part is the best. Pure PHP.

[@bradsmith7208]

So what do we do just write everything from scratch? So easy to tear things down.

[@tamaskosa4456]

It depends on the framework. I can't imagine an Angular developer going back to vanilla JS and saying Angular was "in the way" The message is to evaluate before using a framework instead of blindly jumping into it. It takes experience.

[@MohdSaud-p7h]

Thats why I use react- its a library

[@ES-cf4ph]

Choose your poison: Use a preexisting framework but try to bend it to your needs (it will suck) OR create a custom framework tailored to your needs (and it will also suck especially to develop it)

[@arianitteamaxess674]

doesn't the same apply to everything in the software development world? unless you build your own hardware from scratch, the OS, the IDE, the programming language, etc.? you always commit to the things that I mentioned.

[@RogerioSilva-v1q]

In my opinion, the great problems we face today are about to "do it simplier at maximum". We have'nt deep thoughs anymore. Every people while in work stage look for self awareness and lazy decisions. When a fixer person apears the hole team run to claim for themselves the solution crying out: "I knew that it was the problem", a phenomena that we use to call here im Brazil as "Mãe Dináh" effect or in clear words late premonition. If they' d known why did'nt took a step in front? The answer is: "Because we did'nt found the framework to it". Did you get the memo? Frameworks, as data base filler will not make you progress as an architect in technology but instead it will make you an addict for shelf ready solutions.

[@kafeylau]

That is the same case for languages, libraries. Just a matter of degree to what you feel comfortable.

[@mlohr1]

You can use a hexagon architecture to separate your domain code from your infrastructure (incl. framework).

[@ishraqsyed8999]

My two cents. There can be some solutions which do not require you to use frameworks because they are simple enough and like the respected gentleman in the video says 'framework can get in the way' in such cases but eg you have to build UI for an enterprise level application. I don't think doing something of that scale without using a framework would be easy. It will be possible but it will be a lot more code which will need a lot more maintenance. I think frameworks make our life easy 90% of the time and get in the way around 5-10% where you have to find a way around it but that is a trade off I am willing to take.

[@programmingwithomega6300]

Public frameworks seem to aim also at putting the team at ease: like not one developer is going to dictate the codebase, what we are using is used by everyone. And then the project gets bigger, one gets an idea to simplify, the simplifier leaves without documenting. **Chaos**

[@Jared4130]

This becomes really evident when your large enterprise application is written in a soon to be deprecated/unsupported framework as it needs to be converted to something newer. Example: AngularJS (original) to React. This is a huge overhaul and time consuming task.

[@purduetom90]

I’d argue good frameworks have an interest in benefiting those that adopt it. If it’s not good, the word gets out and adoption from others stops.

[@hugoestrada2089]

I really liked what he said. It is so true

[@erwile]

what's the source to have the full video ?

[@JamesSmith-cm7sg]

I can see what he's saying when it comes to sometimes fighting with the framework, but what's the alternative? There's no way you're going to custom build, not until your product is successful enough, anyway.

[@Thierry4Teen]

Framework is just a tools, if you are in a huge tech company you may write your own framework, but if you're not you can take benefit of it

[@JosephMwema]

Thank you for saying it. Vanilla JavaScript all the way.

[@TerrenceLP]

Building a house with other people's ideas and then having to live with it 😂

[@-Jakob-]

No problems with frameworks if they are well thought and flexible enough to cover your needs. And I've been working with a lot of them. But there will always be quite some developers (ofc especially unexperienced ones) who use them in the wrong way, cut corners, doing weird workarounds, mainly because they don't understand the inner works or the foundation on top of which the framework has been built. NextJS/React is a good example, let's just use it, what could go wrong? And yeah, it's like a free dinner, of what sort of benefits are you talking about? ;))

[@chudchadanstud]

It's the opposite. There's a reason Frameworks exists. Trying to scale raw code is difficult and messy. When your client asks you to make another thing that has that one part that's similar to that other thing you spent weeks developing, what do you do? Rewrite the code or package the old stuff? If you pick the latter congratulations, you're on your way to building a framework.

[@bs8028]

Go with the one that’s fits you most and put rest into script tag that you would do without it?

[@RioChandra]

I remember long ago when using PHP, jquery and laravel. We got question, is jquery a library or framework? is laravel is a library or framework? what the different of library and framework?, so we got the answer library is a tool in your environment, in other hand framework is a tool to build environment.

[@d3v-x64]

How would this "boundary" between framework and production code look like in practice? How would i decouple my code?

[@jan.tichavsky]

I don't use frameworks because they are difficult to learn, way too complex and have tons of dependencies. I rather write myself only what I need.

[@kowaihana]

This is why I don't like frameworks but I am forced to

[@I_am_Raziel]

To like them?

[@FrankHarwald]

This man's words in god's ears!

[@alexisdamnit9012]

I joined a company who had no guardrails or methodology of how to build a certain product. A framework wouldn’t have saved them but it would have made untangling the mess a lot easier. These problems are not framework originating but developer originating. If you don’t know how to build something, then find someone with the insights and understanding how to. Might not always be possible to find the perfect guidance but something or someone exists out there with more knowledge on a specific topic than you.

[@chris-y05]

This is an extreme view of frameworks. If you're coding, you're already using frameworks, otherwise why would you use AWS/GCP/Azure? Why do we use package managers? It may make sense to some senior engineers who've run into issues with framework constraints, but not all the time. Some frameworks are unnecessarily opinionated, but I'd say most of the popular ones aren't all evil. Take this speakers' advice with a grain a salt.

[@brotherpeter00]

"clean" code is slow code. The entire purpose of the clean code movement was to help people that have no understanding of computer architecture or memory be able to write programs so that ultimately companies could hire less qualified people.

[@teilderlosung7287]

Are you advocating for or against the use of frameworks?

[@RueKit-s9d]

Correct! I agree. These people saying about "don't repeat yourself" the dry shet bul shet lol hahaha is bad and should not be used. Their stupid wrong. Program can be done in many different ways.

[@zeko77tz]

An excellent point.

[@namaefumei]

Having this problem every day with react and next. It took 2 years until I could output a good website with these when I could do this vanilla in a month. I had to use them btw. Cause everyone does and our company wants us to too.

[@Dangler774]

2 years??? Maybe you just need to learn react and next better lol

[@namaefumei]

@@Dangler774 yeah this always the answer. Skill issue right? If I did everything perfectly I wouldn't have this problem right. I know

[@FredrikRambris]

So you replaced React with a framework of your own? If that works well, then that is the perfect solution. If your needs are exactly what the react developers had, then it is a perfect fit. Sometimes it is not.

[@SaberKarmous]

It depends. It always does. If you have to create something that should be released quickly and its use is just temporary pick the framework that is the most productive for your team. So yeah, use your brain.

[@bonaqua3076]

It would be nice if you mention when this speech was given because to me it looks like its recorded ages ago. Plus, putting screenshots of React v18 in between the presumably old video about frameworks is not helpful if not misleading. Times have changed. Yes, he's right when he says there is a cost to consider when deciding to work with frameworks, but the benefit has grown larger nowadays with better frameworks and faster release cycles. That's not to say the fundamentals can be overlooked. I just feel that the video can be more helpful with better context.

[@PaulAllsopp-rh5gb]

The problem with frameworks is simple. If you don't first learn the language the framework is built on, you're just a framework developer, not a language developer. Just because someone uses a lathe all day at work, does not make them a carpenter. I answer questions from developers almost daily, and the issue is ALWAYS about a framework. Learn the damn language and fix your own issues. You will be amazed at what you learn from it. This is the difference between an engineer and a developer.

[@corepunch]

With frameworks we get laggy FireOS, Disney+ and Netflix on FireTV can’t see what to complain about

[@manojv2893]

As a FE developer I can testify that frameworks in the frontend simplifies my work with a huge margin. This is just wrong.

[@vherus]

It does, for sure. Until you build something in material UI 3 and nextjs 12, then you want to upgrade to nextjs 14 and have to refactor all of your tightly coupled MUI components because next 14 relies on a react version that MUI 3 doesn’t support. Now you have to decide whether to refactor your MUI stuff to MUI 5 so you can upgrade your framework’s version, or swap it all out for tailwind to try and decouple a bit while you’re at it. Frameworks are brilliant, but Bob is right when he says they get in the way as the project ages

[@javastream5015]

All programming languages above Assembler can be seen as frameworks too. Even C restricts you. But if you want to implement large scale applications with manual memory management or something else which can be done automatically: go ahead! Your costs will explode!

[@witchedwiz]

Yes and no... I mean if you do web oriented development and you use java, you WILL use spring almost crrtainly.. And it will suite your needs mostly.. my only bone with spring boot is ghat, ultimately, a lot of young people use it but don't know it and what i does under the hood, but in terms of effectiveness dev time for juniors is high and for 2 years swe, it's through the rough.. Now if we are instead looking at performance, memory consumption, or naked me lry footprint that's a different matter... Tldr Frameworks can be bad, but in some space they are a necessity and the norm.. Modt times a customer comes up with an internal framework from scratch it's utter garbage that becomes unisable come 3-4 years after releae.. now if you're talking about google or facebook making their own framework, it's a different matter, but for other customers? Say jpmorgan? Say some oil company? Do you seriously think they can dwliver without framework or afford to build and maintain properly their own? Madness

[@ZettaiKatsu2013]

Why even use a framework ? Just code😂

[@Александр-ф9в4ю]

When this guy show us some open source middle-size project. Would like to rate his real code

[@thatosello1021]

So what's the alternative? Writing everything from scratch?

[@imqqmi]

Sure, also, you're committed to PHP, to C++, C#, Go, Cobol, to Java etc. It's not easy to switch. But when stuff gets harder to implement is also where you get the value as a dev to the company you work for (I mean Cobol devs earn a sizeable income am-i-rite?). It's called job security, until AI rears its ugly head of course. Still that also is a huge commitment as a company to an AI model and the licensing structure and the companies behind them. It's trained on open source junior code mostly, consisting of todo lists with bugs and all. All the real, closed source professional production ready code is not available to AI to train on after all. The real problem with frameworks is the hidden cost of maintenance, upgrades, falling in and out of fashion like a summers breeze and there are so so many of them, especially in the Javascript wold.

[@riccardomeggiolarojs]

A lot of "programmers" don't know how a Network works. But Hey, they say that it's not important and boring.

[@ichbinhier355]

just use the tool accordingly to the problem you want to solve, be it with framework or not, for example why bothering using fancy frameworks for a simple landing page, but building a large scale app without framework will cost you a lot of time, I'm not saying it's imposible but time is the most important we have, money goes and comes but time never comes again.